From nobody Wed Jun 1 02:44:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6432712D0BE for ; Wed, 1 Jun 2016 02:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 aVX3W0da5XAU for ; Wed, 1 Jun 2016 02:44:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5227512B076 for ; Wed, 1 Jun 2016 02:44:52 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:fdb9:f62:f867:27cd] (unknown [IPv6:2001:718:1a02:1:fdb9:f62:f867:27cd]) by mail.nic.cz (Postfix) with ESMTPSA id 7D979607E8; Wed, 1 Jun 2016 11:44:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1464774290; bh=F+8ksu1pMf/p/NChV3YUeB4oSmFfQK7egYUfgh9esys=; h=From:Date:To; b=Ahr2lfEcU4+zmvD2Bf8cwjH5YtfwxoGslj7Ac5ceILiM8dlDtP6x+qFDpU/El3CHW tPKLs8FtqNu73gKU8RaG+F0uiZiNATV9qcvSdFfU1xAfNyViAXt9OoLYitgYrAxPy+ tFmq//2dUlcx8frJmksYo3OF2Zb9BrA9l7hpjKsw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160601063918.GB23984@elstar.local> Date: Wed, 1 Jun 2016 11:45:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160531.230241.1831955717429467771.mbj@tail-f.com> <20160601063918.GB23984@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] "A YANG Data Model for Routing Management" Modifications X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 09:44:56 -0000 > On 01 Jun 2016, at 08:39, Juergen Schoenwaelder = wrote: >=20 > On Tue, May 31, 2016 at 11:02:41PM +0200, Martin Bjorklund wrote: >> "Acee Lindem (acee)" wrote: >>> Hi Lada,=20 >>> If we can=E2=80=99t get YANG to do what we need, can we just support = a choice with >>> a special value of =E2=80=9Cunspecified=E2=80=9D for the interface = and address? >>=20 >> Yes, you can make these keys be unions of interface-ref and an enum >> 'unspecified', and an ip-address and enum 'unspecified'. >>=20 >>> Additionally, we=E2=80=99d need a constraint that enforces the fact = that both >>> interface and address cannot be =E2=80=9Cunspecified=E2=80=9D. >>=20 >> must 'key1 !=3D "unspecified" or key2 !=3D "unspecified"'; >>=20 >=20 > Does this not mean you can't have an interface named 'unspecified' > anymore? Perhaps we should have disallowed zero-length string values > for /interfaces/interface/name and then we would have a handy value > to be used in situations like this? Yes, I think the empty string is better than any magic value. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 2 05:12:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF6812D6C7 for ; Thu, 2 Jun 2016 05:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 f_xGlHaCKMNx for ; Thu, 2 Jun 2016 05:12:19 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6113E12D6C4 for ; Thu, 2 Jun 2016 05:12:18 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-0c-575022a024b5 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.73.27088.0A220575; Thu, 2 Jun 2016 14:12:16 +0200 (CEST) Received: from [159.107.197.251] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.294.0; Thu, 2 Jun 2016 14:12:08 +0200 References: <20160602.140529.528232965599124655.mbj@tail-f.com> To: "netmod@ietf.org" From: Balazs Lengyel X-Forwarded-Message-Id: <20160602.140529.528232965599124655.mbj@tail-f.com> Message-ID: <779b05e6-5a44-062e-26fa-3729201d15fc@ericsson.com> Date: Thu, 2 Jun 2016 14:12:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160602.140529.528232965599124655.mbj@tail-f.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM2K7hO4CpYBwg0cvxC3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxou2BewFHYIVt5atYGtgvMrTxcjJISFgIrG/8xIrhC0mceHe erYuRi4OIYEjjBIbVj5nhHDWMEpcn32ApYuRg0NYQEvi8U9ZkAYhAXuJPcefs4PYIgLqEjN3 gjRzcrAJGElM7T/PAjHUW+Jz32wwmxeovnP6QzaQMSwCKhJfN7iChEUFYiS2d01mhygRlDg5 8wlYOaeAg8Sv84/BbGYBfYnrd+6zQtjyEtvfzmGGOEFD4uGFv6wTGAVnIWmfhaRlFpKWBYzM qxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECA/Pglt8GOxhfPnc8xCjAwajEw/sgyj9ciDWx rLgy9xCjBAezkghvu1xAuBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWp RTBZJg5OqQbGhRvszp33b627fdJvvrtCzHyxW/tLD15at7hwRgb78VW/L83k2rozIb/xlEfJ 5Ul5OSrTJv71tDkn3WJzMCv//0c9peeLXv3r2v7teWXjy0mr/VTn29x3Zz+ierz3xedyuzyT z1dO/Gi/fPK71Oplk/jV/1wTWJu2e6FYXUhXt1h8XFAzw66/xUosxRmJhlrMRcWJABidaEpI AgAA Archived-At: Subject: [netmod] Why can't I deviate a description X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 12:12:21 -0000 Hello,
A proposal for the future of YANG.
Balazs

-------- Forwarded Message --------
Subject: Re: Why can't I deviate a description
Date: Thu, 2 Jun 2016 14:05:29 +0200
From: Martin Bjorklund <mbj@tail-f.com>
To: balazs.lengyel@ericsson.com 

Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
> Hello Martin,
> 
> YANG deviations allows me to change a lot of properties of a data-node. However I can not
> change its description. To me that is strange. Sometimes I need to describe
> what and why I changed, but I am not allowed to. Why?

Good question!  It would probably make sense to allow this.  Something
to look forward to in YANG 1.2 ;-)


/martin


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Thu Jun 2 12:23:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B0512D7E3 for ; Thu, 2 Jun 2016 12:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 S7YvbRYIquRb for ; Thu, 2 Jun 2016 12:23:08 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207: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 785D812B00A for ; Thu, 2 Jun 2016 12:23:07 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by comcast with SMTP id 8YCHbCYt6BE6O8YCxbeUwM; Thu, 02 Jun 2016 19:23:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464895387; bh=TiCRpLo64V//jtMDXXrjNM1c9A14xcvGhaLpAFEIdSk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=jfjBQYeNoi8b7xECmisHGlOqaMHKeMtVDIMQr64W3jLd3kBoCyIHdffAFe6Xps7Ia BJnIgQ6UwhnNlfY0seuPWEBHrI9YeoOppctWzrk7xINyfonsfZ3wHdZKjhoWtJDjuL rPE0vKSG8vyUUk0NYha50DWZ4Gih65XlQdLhtIYaQKoQbPnbsmEPrj8iUO485NOAms xPF/v+VKykzV6f2/gab2rfXFo3tiC5hCeLczsE8nL5fkYW1VuhMMVKB5dp31nF6je+ Hcn/NfUbLZ3NuKDJCPHc6Tlua3A4NQ1lNVaDqJFIY/TKHKlBBo1jxXWawppNe+ag5o toD2d0/ltFY1A== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id 1vP61t0041nMCLR01vP6ZE; Thu, 02 Jun 2016 19:23:06 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u52JN5LH025704; Thu, 2 Jun 2016 15:23:05 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u52JN5D3025701; Thu, 2 Jun 2016 15:23:05 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org References: <20160523.195854.939392582596188168.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 02 Jun 2016 15:23:05 -0400 Message-ID: <87zir3fl9i.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [netmod] Fwd: if-feature in default value X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 19:23:11 -0000 Martin Bjorklund wrote: >>>>> mbj> OLD: >>>>> mbj> >>>>> mbj> The definition of the default value MUST NOT be marked with an >>>>> mbj> "if-feature" statement. >>>>> mbj> >>>>> mbj> NEW: >>>>> mbj> >>>>> mbj> If the definition of the default value is conditional based >>>>> mbj> on one or more features (see ^if-feature^), then the leaf >>>>> mbj> node MUST also be conditional based on at least the same >>>>> mbj> set of features. >>>>> mbj> >>>>> mbj> (modelled after the text in 9.9) >>>>> >>>>> Does anyone have comments on this proposal? > I was careful to use the same wording as is used in section 9.9 on > leafrefs: > > If the leaf that the leafref refers to is conditional based on one or > more features (see Section 7.20.2), then the leaf with the leafref > type MUST also be conditional based on at least the same set of > features. > > So we already have the complexity. That sounds good to me. As y'all say, it's complex to check, but it's the same check being done for leafrefs, so there's no additional conceptual complexity. Dale From nobody Thu Jun 2 13:15:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF07A12D602 for ; Thu, 2 Jun 2016 13:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 fKxTkubkE1kr for ; Thu, 2 Jun 2016 13:15:05 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 25D5F12D7F2 for ; Thu, 2 Jun 2016 13:15:00 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by comcast with SMTP id 8YwBbYk6ajuYR8Z19bc3Kv; Thu, 02 Jun 2016 20:14:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1464898499; bh=4KkCIkEX/u9pRo0j60EgaAZiW6n+NIv6XnzMh9Gze7M=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=H+dFZnwQq4Ibu8N1t0MErzlYSwSNVryODpmSGEplcF9WkQh1fxq9AY/jVuT9PxVz8 HzKHpC/v1OcYCDYNoqVTU4g6rku+3MVtw+asialHpoDkRpKGZbXTle4fwiWlmY3jlx DijTXK8ANJvfzLFoQg5KzMaziH7g48xWAPdcajwDQz9jM9hAZXWdJ1N9hNsQ/J8dl+ tbPlqRNT4n5SkSlyebFwCLFB3e26Y+HGZ1tE2sf3XaHfg3ZuOwxG36DFSSD85kuq6Z DIA1MD8LfYgHNXAUmp7Ect56cwRHspf5DGeMspDV6WW/r5wdK8q3rQp8Uhb6o07p0K SBHDk4itESAVg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-14v.sys.comcast.net with comcast id 1wEy1t00C1nMCLR01wEyNN; Thu, 02 Jun 2016 20:14:59 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u52KEvWF028471; Thu, 2 Jun 2016 16:14:57 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u52KEvh5028467; Thu, 2 Jun 2016 16:14:57 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org In-Reply-To: <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz> (lhotka@nic.cz) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 02 Jun 2016 16:14:56 -0400 Message-ID: <87twhbfiv3.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:15:07 -0000 Martin Bjorklund wrote: > Also, the text needs to mention leaf-lists. This gives: > > The leafref type is restricted to the value space of some leaf or > leaf-list node in the schema tree and optionally further restricted > by corresponding instance nodes in the data tree. The "path" > substatement (Section 9.9.2) is used to identify the referred leaf > or leaf-list node in the schema tree. The value space of the > referring node is the value space of the referred node. > > If the "require-instance" property is "true", there MUST exist an > node in the data tree, or a node with a default value in use (see > Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf > or leaf-list node with the same value as the leafref value in a > valid data tree. > > If the referring node represents configuration data, and the > "require-instance" property (Section 9.9.3) is "true", the referred > node MUST also represent configuration. How about: The leafref type contains an XPath expression in the "path" substatement. Due to the restrictions on the expression, all instances in the result set of the expression evaluated on all possible data tree are instances of one single data node, called the "referred node". The leafref type has the value space of the type of the referred node. If the "require-instance" property is "true", the leafref type also imposes a constraint on any node of its type: the value must be the same as that of some instance in the data tree, or an instance with a default value in use, selected by the XPath expression. Such a constraint is enforced according to the rules in Section 8. If the referring node represents configuration data, and the "require-instance" property (Section 9.9.3) is "true", the referred node MUST also represent configuration. I started with a discussion of the XPath expression to state explicitly that all selected instances must be instances of one data node, and used that to define "referred node". With that clarified, it's easier to state the conditions that we care about. I want to clearly separate the question of value space (which is enforced roughly any time XML using the module is parsed) from the constraint (which is enforced only at the times specified in section 8). I do exploit the convention that default values cause instance nodes to exist in the data tree in a sort of virtual sense, in that the XPath expression can return them in its data set. But I think that is consistent with the philosophy of Yang. Does that need to be stated more explicitly? Also, in the lexicon: o anydata: A data node that can contain an unknown set of nodes that can be modelled by YANG, except anyxml. o anyxml: A data node that can contain an unknown chunk of XML data. Both definitions should start with "a data node *whose instances* can contain..." Dale From nobody Thu Jun 2 17:44:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CBF12B02F for ; Thu, 2 Jun 2016 17:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 lThAcaV3i3O6 for ; Thu, 2 Jun 2016 17:44:23 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 F40CA1200A0 for ; Thu, 2 Jun 2016 17:44:22 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 582C192B2CA6A; Fri, 3 Jun 2016 00:44:18 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u530iLRg009765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 00:44:22 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u530iLWQ001950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 00:44:21 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 2 Jun 2016 20:44:21 -0400 From: "Sterne, Jason (Nokia - CA)" To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt Thread-Index: AQHRqwEIoPXkjp2l/k2OqqhnpwdmNZ+yjKoAgBqvymCABkkegIADfDLA Date: Fri, 3 Jun 2016 00:44:20 +0000 Message-ID: References: <20160510211427.390.80951.idtracker@ietfa.amsl.com> <3BC3991A-615F-47CE-A567-721C8272404E@cisco.com> <2DC04BC2-4A02-49CF-AD39-6AFE13F09A0E@cisco.com> In-Reply-To: <2DC04BC2-4A02-49CF-AD39-6AFE13F09A0E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 00:44:26 -0000 VGh4IENseWRlLiAgVGhlIGFuYWx5c2lzIGFwcHJvYWNoIGJlbG93IGlzIHJlYWxseSB1c2VmdWwg LSB0aHggZm9yIHB1dHRpbmcgdGhhdCB0b2dldGhlci4NCg0KR2l2ZW4gdGhhdCBNYWhlc2gncyBj b21tZW50cyBhYm91dCBsb2ctaW5wdXQgd2VyZSBtYXliZSBtZWFudCBmb3Igc29tZXRoaW5nIGVs c2Ugd2Ugc2hvdWxkIHJlY29uc2lkZXIgdGhlIGFkZGl0aW9uIG9mIHRoYXQgaXRlbS4gV2UgYXJl bid0IGV4YWN0bHkgdHJ5aW5nIHRvIG1vZGVsIFJGQzU0MjQgaGVyZSAod2hpY2ggaXMgbW9yZSBv ZiBhIHByb3RvY29sIGFuZCBkYXRhIGZvcm1hdCBkb2N1bWVudCkuICBXZSdyZSBtb3JlIHRyeWlu ZyB0byBtb2RlbCBob3cgZGV2aWNlcyBjb25maWd1cmUgbG9nZ2luZy4gIA0KDQpJZiBpdCBpcyBw dXJlbHkgYSBMaW51eCBSc3lzbG9nIHRoaW5nIHRoZW4gbWF5YmUgaXQgYmVsb25ncyBpbiBhIHNl cGFyYXRlIG1vZHVsZSB0aGF0IHdvdWxkIGJlIHNlcGFyYXRlbHkgYWR2ZXJ0aXNlZC4gIFRoZSB3 aG9sZSBSeCBzaWRlIG9mIHRoaXMgaXMgYSBkaWZmZXJlbnQgYmVhc3QgSU1PLg0KDQpPdGhlciBv cGluaW9ucyBvbiB0aGlzIG9uZSA/DQoNCkFsY2F0ZWwgc2hvdWxkIHByb2JhYmx5IGJlIE5va2lh IG5vdyA6LSkNCg0KQ29ycmVjdGlvbnMgdG8gdGhlIEFsY2F0ZWwvTm9raWEgY29sdW1uOg0KLSBB ZGQgYW4geCBpbiB0aGUgbG9nLWFjdGlvbiByZW1vdGUgcm93DQotIGZlYXR1cmUgYnVmZmVyLWxp bWl0LWJ5dGVzIGlzIG5vdCBzdXBwb3J0ZWQNCi0gZmVhdHVyZSBidWZmZXItbGltaXQtbWVzc2Fn ZXMgKGZyb20gcHJldiB2ZXJzaW9uIG9mIGRyYWZ0KSBpcyBzdXBwb3J0ZWQNCi0gQWRkIGFuIHgg aW4gdGhlIGZlYXR1cmUgZmlsZS1saW1pdC1kdXJhdGlvbiByb3cNCi0gcmVtb3ZlIHRoZSB4IGZy b20gdGhlIHNlc3Npb24tZmFjaWxpdHktdXNlci1sb2dnaW5nIHJvdw0KDQpTbyB0aGUgdXBkYXRl ZCB0YWJsZSBiZWNvbWVzIHRoaXM6DQogICAgICAgIEZlYXR1cmUgICAgICAgICAgICAgIE5va2lh ICAgQnJvY2FkZSAgQ2llbmEgIENpc2NvIElPUy9YRSAgQ2lzY28gSU9TL1hSICBDaXNjbyBOWE9T ICBKdW5pcGVyIEp1bk9TICBMaW51eCBSc3lzbG9nICBDb21tZW50cw0KbG9nLWlucHV0LXRyYW5z cG9ydHMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeA0KbG9nLWFjdGlvbiBj b25zb2xlICAgICAgICAgICAgIHggICAgICAgIHggICAgICAgICAgICAgICAgIHggICAgICAgICAg ICAgIHggICAgICAgICAgIHggICAgICAgICAgICB4ICAgICAgICAgICAgICAgeAkNCmxvZy1hY3Rp b24gYnVmZmVyICAgICAgICAgICAgICB4ICAgICAgICAgICAgICAgICAgICAgICAgICB4ICAgICAg ICAgICAgICB4DQpsb2ctYWN0aW9uIGZpbGUgICAgICAgICAgICAgICAgeCAgICAgICAgICAgICAg ICAgICAgICAgICAgeCAgICAgICAgICAgICAgeCAgICAgICAgICAgeCAgICAgICAgICAgIHggICAg ICAgICAgICAgICB4DQpsb2ctYWN0aW9uIHJlbW90ZSAgICAgICAgICAgICAgeCAgICAgICAgeCAg ICAgICB4ICAgICAgICAgeCAgICAgICAgICAgICAgeCAgICAgICAgICAgeCAgICAgICAgICAgIHgg ICAgICAgICAgICAgICB4DQpsb2ctYWN0aW9uIHRlcm1pbmFsICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgeCAgICAgICAgICAgICAgeCAgICAgICAgICAgeCAgICAgICAgICAg ICAgICAgICAgICAgICAgICB4DQpsb2ctYWN0aW9uIHNlc3Npb24gICAgICAgICAgICAgeCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHgNCmZlYXR1cmUgYnVmZmVyLWxpbWl0LWJ5dGVzCSAgICAgICAgICAgICAgICAgICAgICAg ICAgeCAgICAgICAgICAgICAgeA0KZmVhdHVyZSBidWZmZXItbGltaXQtbWVzc2FnZXMgIHgNCmZl YXR1cmUgZmlsZS1saW1pdC1zaXplICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4 ICAgICAgICAgICAgICB4ICAgICAgICAgICAgICAgICAgICAgICAgeA0KZmVhdHVyZSBmaWxlLWxp bWl0LWR1cmF0aW9uICAgIHggICAgICAgICAgICAgICAgICAgICAgICAgIHggICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB4DQpmZWF0dXJlDQogdGVybWluYWwtZmFjaWxpdHkt ZGV2aWNlLWxvZ2dpbmcNCmZlYXR1cmUgDQogc2Vzc2lvbi1mYWNpbGl0eS11c2VyLWxvZ2dpbmcg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHgNCmZlYXR1cmUgc2VsZWN0LXNldi1jb21wYXJlICAgICB4ICAgICAgICAgICAg ICAgICAgICAgICAgICB4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHgNCmZlYXR1cmUgc2VsZWN0LW1hdGNoICAgICAgICAgICB4ICAgICAgICAg ICAgICAgICAgICAgICAgICB4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg eCAgICAgICAgICAgICAgIHgNCmZlYXR1cmUgc3RydWN0dXJlZC1kYXRhICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgeCAgICAgICAgICAgICAgIHggICAgIFJlcXVpcmVkIGJlY2F1c2Ugb2YgUkZDIDU0MjQNCmZl YXR1cmUgc2lnbmVkLW1lc3NhZ2VzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHgg ICAgIFJlcXVpcmVkIGJlY2F1c2Ugb2YgUkZDIDU4NDgNCg0KQmFzZWQgb24gdGhhdCB3ZSBjb3Vs ZCBjb25zaWRlciB0aGUgZm9sbG93aW5nIHRvIHNpbXBsaWZ5IHRoaW5nczoNCi0gcmVtb3Zpbmcg Ym90aCBidWZmZXItbGltaXQtYnl0ZXMgYW5kIGJ1ZmZlci1saW1pdC1tZXNzYWdlcyBhbmQgbGVh dmUgdGhvc2UgdG8gYXVnbWVudGF0aW9ucyAob3IgZXZlbiByZW1vdmUgYnVmZmVyIGFsbCB0b2dl dGhlciBmcm9tIHRoZSBtb2RlbCBhcyBhbiBhY3Rpb24pDQotIG1ha2luZyBzZWxlY3QtbWF0Y2gg cGFydCBvZiB0aGUgYmFzZSBtb2RlbCB3aXRob3V0IGFueSBpZi1mZWF0dXJlDQotIHJlbW92ZSBm ZWF0dXJlIHNlc3Npb24tZmFjaWxpdHktdXNlci1sb2dnaW5nIGZyb20gdGhlIGRyYWZ0DQotIHJl bW92ZSBmZWF0dXJlIHNpZ25lZC1tZXNzYWdlcyBmcm9tIHRoZSBkcmFmdA0KDQpJJ20gbm90IHN1 cmUgaWYgdGhlIHB5YW5nIHRyZWUgZnVsbHkgbWF0Y2hlcyB0aGUgbW9kZWwgaW4gdGhlIGRvYy4g IE9uZSBleGFtcGxlIC0+IHRoZSB0cmVlIGhhcyBzZWxlY3Qtc2V2LWNvbXBhcmUgYnV0IHRoZSBt b2RlbCBpdHNlbGYgYmVsb3cgaGFzIHNlbGVjdG9yLXNldm9wLWNvbmZpZy4gIEkgdGhpbmsgSSBz YXcgb3RoZXIgZGlmZmVyZW5jZXMgd2hlbiBJIHdhcyBsb29raW5nIGFyb3VuZCAoc2VsZWN0LW1h dGNoIGlzIGFub3RoZXIgb25lKS4NCg0KUmVnYXJkcywNCkphc29uDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBDbHlkZSBXaWxkZXMgKGN3aWxkZXMpIFttYWlsdG86Y3dpbGRl c0BjaXNjby5jb21dIA0KU2VudDogVHVlc2RheSwgTWF5IDMxLCAyMDE2IDE2OjU0DQpUbzogU3Rl cm5lLCBKYXNvbiAoTm9raWEgLSBDQSk7IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtu ZXRtb2RdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0wOC50eHQN Cg0KSmFzb24sDQoNCldpdGggcmVnYXJkcyB0byBhZGRpbmcgbG9nLWlucHV0LXRyYW5zcG9ydHM6 IHBsZWFzZSBzZWUgUkZDIDU0MjQg4oCTIFRoZSBTeXNsb2cgUHJvdG9jb2wsIHNlY3Rpb25zIDMg YW5kIDQgd2hlcmUgcmVsYXkgYW5kIGNvbGxlY3RvciBmdW5jdGlvbnMgYXJlIGRpc2N1c3NlZC4g SW4gb3JkZXIgdG8gc3VwcG9ydCB0aGUgcmVsYXkgYW5kL29yIGNvbGxlY3RvciBmdW5jdGlvbiwg bG9nLWlucHV0LXRyYW5zcG9ydHMgaXMgcmVxdWlyZWQgYW5kIEkgYmVsaWV2ZSBpdCBpcyBiZXN0 IHRvIHN1cHBvcnQgdGhlIGVudGlyZSBSRkMgNTQyNCBwcm90b2NvbC4NCg0KSSBwcm9kdWNlZCB0 aGUgZm9sbG93aW5nIHRhYmxlIHRvIGhlbHAgd2l0aCB0aGUgYW5hbHlzaXMgb2Ygd2hhdCBmZWF0 dXJlcyBtaWdodCBiZSBpbmNsdWRlZC4gUGxlYXNlIHByb3ZpZGUgdXBkYXRlcyB0byB0aGUgdGFi bGUgdG8gaGVscCB3aXRoIHRoZSBhbmFseXNpcy4NCg0KICAgICAgICBGZWF0dXJlICAgICAgICAg ICAgIEFsY2F0ZWwgIEJyb2NhZGUgIENpZW5hICBDaXNjbyBJT1MvWEUgIENpc2NvIElPUy9YUiAg Q2lzY28gTlhPUyAgSnVuaXBlciBKdW5PUyAgTGludXggUnN5c2xvZyAgQ29tbWVudHMNCmxvZy1p bnB1dC10cmFuc3BvcnRzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHgNCmxv Zy1hY3Rpb24gY29uc29sZSAgICAgICAgICAgICB4ICAgICAgICB4ICAgICAgICAgICAgICAgICB4 ICAgICAgICAgICAgICB4ICAgICAgICAgICB4ICAgICAgICAgICAgeCAgICAgICAgICAgICAgIHgJ DQpsb2ctYWN0aW9uIGJ1ZmZlciAgICAgICAgICAgICAgeCAgICAgICAgICAgICAgICAgICAgICAg ICAgeCAgICAgICAgICAgICAgeA0KbG9nLWFjdGlvbiBmaWxlICAgICAgICAgICAgICAgIHggICAg ICAgICAgICAgICAgICAgICAgICAgIHggICAgICAgICAgICAgIHggICAgICAgICAgIHggICAgICAg ICAgICB4ICAgICAgICAgICAgICAgeA0KbG9nLWFjdGlvbiByZW1vdGUgICAgICAgICAgICAgICAg ICAgICAgIHggICAgICAgeCAgICAgICAgIHggICAgICAgICAgICAgIHggICAgICAgICAgIHggICAg ICAgICAgICB4ICAgICAgICAgICAgICAgeA0KbG9nLWFjdGlvbiB0ZXJtaW5hbCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHggICAgICAgICAgICAgIHggICAgICAgICAgIHgg ICAgICAgICAgICAgICAgICAgICAgICAgICAgeA0KbG9nLWFjdGlvbiBzZXNzaW9uICAgICAgICAg ICAgIHggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB4DQpmZWF0dXJlIGJ1ZmZlci1saW1pdC1ieXRlcwkgPyAgICAgICAgICAg ICAgICAgICAgICAgICAgeCAgICAgICAgICAgICAgeA0KZmVhdHVyZSBmaWxlLWxpbWl0LXNpemUg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHggICAgICAgICAgICAgIHggICAgICAg ICAgICAgICAgICAgICAgICB4DQpmZWF0dXJlIGZpbGUtbGltaXQtZHVyYXRpb24gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgeCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHgNCmZlYXR1cmUNCiB0ZXJtaW5hbC1mYWNpbGl0eS1kZXZpY2UtbG9nZ2luZw0KZmVhdHVy ZSANCiBzZXNzaW9uLWZhY2lsaXR5LXVzZXItbG9nZ2luZyB4ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeA0KZmVhdHVyZSBz ZWxlY3Qtc2V2LWNvbXBhcmUgICAgIHggICAgICAgICAgICAgICAgICAgICAgICAgIHggICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeA0KZmVhdHVy ZSBzZWxlY3QtbWF0Y2ggICAgICAgICAgIHggICAgICAgICAgICAgICAgICAgICAgICAgIHggICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4ICAgICAgICAgICAgICAgeA0KZmVh dHVyZSBzdHJ1Y3R1cmVkLWRhdGEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4ICAgICAgICAgICAgICAgeCAg ICAgUmVxdWlyZWQgYmVjYXVzZSBvZiBSRkMgNTQyNA0KZmVhdHVyZSBzaWduZWQtbWVzc2FnZXMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeCAgICAgUmVxdWlyZWQgYmVjYXVzZSBv ZiBSRkMgNTg0OA0KCQkJCQkJCQkJDQpBbGNhdGVsIC0gaHR0cHM6Ly9pbmZvcHJvZHVjdHMuYWxj YXRlbC1sdWNlbnQuY29tL2NnaS1iaW4vZGJhY2Nlc3NmaWxlbmFtZS5jZ2kvOTMwMDcxMDcwMl9W MV83NzUwJTIwU1IlMjAoU0VSVklDRSUyMFJPVVRFUikucGRmDQpDaWVuYSAtIGh0dHBzOi8vd3d3 LmNvbW1vbmNyaXRlcmlhcG9ydGFsLm9yZy9maWxlcy9lcGZpbGVzL3N0X3ZpZDEwNDYwLXN0LnBk Zg0KQ2lzY28gSU9TL1hFIC0gaHR0cDovL3d3dy5jaXNjby5jb20vYy9lbi91cy90ZC9kb2NzL2lv cy14bWwvaW9zL2VzbS9jb21tYW5kL2VzbS1jci1ib29rL2VzbS1jci1hMS5odG1sDQpDaXNjbyBJ T1MvWFIgLSBodHRwOi8vd3d3LmNpc2NvLmNvbS9jL2VuL3VzL3RkL2RvY3Mvcm91dGVycy9hc3I5 MDAwL3NvZnR3YXJlL3N5c3RlbV9tb25pdG9yaW5nL2NvbW1hbmQvcmVmZXJlbmNlL2Itc3lzbW9u LWNyLWFzcjlrL2Itc3lzbW9uLWNyLWFzcjlrX2NoYXB0ZXJfMDEwMC5odG1sDQpDaXNjbyBOWE9T IC0gaHR0cDovL3d3dy5jaXNjby5jb20vYy9lbi91cy90ZC9kb2NzL3N3aXRjaGVzL2RhdGFjZW50 ZXIvbmV4dXM3MDAwL3N3L3N5c3RlbS1tYW5hZ2VtZW50L2NvbW1hbmQvcmVmZXJlbmNlL243a19z bV9jbWRfcmVmL3NtX2NtZF9sLmh0bWwjcGdmSWQtMTAxNDY4Ng0KQnJvY2FkZSAtIGh0dHA6Ly93 d3cuYnJvY2FkZS5jb20vY29udGVudC9odG1sL2VuL2NvbW1hbmQtcmVmZXJlbmNlLWd1aWRlL25v cy03MDAtY29tbWFuZHJlZi9HVUlELTIyOTdFNENBLTc2REMtNDNFNS05MTY0LUFDMUFDOUQzRjRF Ny5odG1sDQpKdW5pcGVyIEp1bk9TIC0gaHR0cDovL3d3dy5qdW5pcGVyLm5ldC9kb2N1bWVudGF0 aW9uL2VuX1VTL2p1bm9zMTIuMy90b3BpY3MvcmVmZXJlbmNlL2NvbmZpZ3VyYXRpb24tc3RhdGVt ZW50L3N5c2xvZy1lZGl0LXN5c3RlbS5odG07DQpMaW51eCBSc3lzbG9nIC0gaHR0cDovL3d3dy5y c3lzbG9nLmNvbS9kb2Mvdjgtc3RhYmxlLwkJCQkJCQkJCQ0KDQpUaGFua3MsDQoNCkNseWRlDQoN Cg0KT24gNS8yNy8xNiwgMTI6MzAgUE0sICJTdGVybmUsIEphc29uIChOb2tpYSAtIENBKSIgPGph c29uLnN0ZXJuZUBub2tpYS5jb20+IHdyb3RlOg0KDQo+SGkgQ2x5ZGUsDQo+DQo+SSB3YXMgYSBi aXQgc3VycHJpc2VkIHRvIHNlZSB0aGUgcmVjZWl2ZXIvc2VydmVyIHNpZGUgY29uZmlnIGluIGhl cmUgKGxvZy1pbnB1dC10cmFuc3BvcnRzKS4gIFRoYXQgc2VlbXMgdG8gYmUgYSBzb21ld2hhdCBz aWduaWZpY2FudCBjaGFuZ2UgaW4gc2NvcGUuICBJIHRob3VnaHQgdGhlIGZvY3VzIG9mIHRoaXMg d2FzIG1vcmUgb24gdGhlIGdlbmVyYXRpb24gJiBkaXN0cmlidXRpb24uICBEbyBtYW55IGltcGxl bWVudGF0aW9ucyBoYXZlIGZ1bmN0aW9uYWxpdHkgdGhhdCBtYXBzIHRvIHRoaXMgbG9nLWlucHV0 LXRyYW5zcG9ydHMgPyAgIEluIGFueSBjYXNlIHRoZSBweWFuZyB0cmVlIGhhcyBsb2ctaW5wdXQt dHJhbnNwb3J0cyBidXQgaXQgZG9lc24ndCBzZWVtIHRvIGJlIGRvd24gaW4gdGhlIGFjdHVhbCBt b2RlbCBpdHNlbGYuICBCdXQgSSdkIGJlIGluY2xpbmVkIHRvIGp1c3QgcmVtb3ZlIHRoaXMgZnJv bSB0aGUgbW9kZWwuICBNYXliZSBNYWhlc2ggaGFzIHNvbWUgdGhvdWdodHMgaGVyZSAoSSBkaWRu J3Qgc2VlIGEgcG9zdGluZyBhYm91dCB0aGlzIGluIHRoZSBtYWlsaW5nIGxpc3QpLg0KPg0KPkkg YWdyZWUgdGhlcmUgYXJlIG11bHRpcGxlIGltcGxlbWVudGF0aW9ucyBvZiBjb25zb2xlLCBidWZm ZXIgYW5kIHNlc3Npb24gbG9ncy4gIEJ1dCBtYXliZSAndGVybWluYWwnIHNob3VsZCBiZSByZW1v dmVkIG9yIGFuIGlmLWZlYXR1cmUgPyAgSSdtIG5vdCBzdXJlIHRoYXQgb25lIGlzIHNvIHdpZGVz cHJlYWQgKG5vdCBpbiBKVU5PUywgbm90IGluIFNSIE9TKS4NCj4NCj5CdWZmZXItbGltaXQtbWVz c2FnZXMgYW5kIGhhdmluZyBtdWx0aXBsZSBsb2cgYnVmZmVycyBhcmUgYm90aCBzdXBwb3J0ZWQg YnkgTm9raWEgU1IgT1MuIEkgd291bGQgdGhpbmsgdGhhdCBib3RoIG9mIHRob3NlIHdvdWxkIGhh dmUgc3VwcG9ydCBpbiBvdGhlciBsb2dnaW5nIGltcGxlbWVudGF0aW9ucyBhcyB3ZWxsLiAgSSdt IG5vdCBzdXJlIGlmIFRvbSBQLiB3YXMgcmVhbGx5IGNvbmNsdWRpbmcgdGhhdCB0aGVyZSBhcmUg bm8gaW1wbGVtZW50YXRpb25zIG9mIHRoZXNlIGluIGhpcyBlbWFpbC4gIERvIHdlIGhhdmUgbXVs dGlwbGUgZXhhbXBsZXMgb2YgaW1wbGVtZW50YXRpb25zIHRoYXQgbGltaXQgbG9nIGJ1ZmZlcnMg dXNpbmcgYnl0ZXMgPw0KPg0KPkJ1ZmZlci1saW1pdC1tZXNzYWdlcyB3b3VsZCBiZSBlYXN5IHRv IGRvIGFzIGFuIGF1Z21lbnRhdGlvbiBidXQgbWFraW5nIHRoZSBsb2ctYnVmZmVyIGEgbGlzdCBp cyBwcm9iYWJseSBzb21ldGhpbmcgd2Ugc2hvdWxkIGp1c3QgZG8gZnJvbSB0aGUgc3RhcnQuICBU aGF0IGlzIGFsc28gY29uc2lzdGVudCB3aXRoIGFsbCB0aGUgb3RoZXIgdHlwZXMgb2YgYWN0aW9u cyAoZXhjZXB0IGNvbnNvbGUgb2YgY291cnNlKS4gVGhlIHVzZSBjYXNlIGZvciBtdWx0aXBsZSBs b2cgYnVmZmVycyBpcyB0aGF0IHlvdSBtaWdodCBzb3J0L2ZpbHRlciBkaWZmZXJlbnQgdHlwZXMg b2YgbG9nIGV2ZW50cyBpbnRvIGRpZmZlcmVudCBjaXJjdWxhciBidWZmZXJzIChpLmUuIGhhdmUg b25lIGZvciByZWFsbHkgY3JpdGljYWwgbG9nIGV2ZW50cywgZXRjKSBmb3Igdmlld2luZyBvbiB0 aGUgbm9kZS4NCj4NCj5SZWdhcmRzLA0KPkphc29uDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj5Gcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEVYVCBDbHlkZSANCj5XaWxkZXMgKGN3aWxkZXMpDQo+U2VudDogVHVlc2RheSwg TWF5IDEwLCAyMDE2IDE3OjIzDQo+VG86IG5ldG1vZEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBb bmV0bW9kXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMDgudHh0 DQo+DQo+SGksDQo+DQo+VGhpcyB1cGRhdGUgdG8gdGhlIGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xv Zy1tb2RlbC0wOCBpbmNvcnBvcmF0ZXMgdGhlIGNoYW5nZXMgbGlzdGVkIGJlbG93IGJhc2VkIG9u IGZlZWRiYWNrIHJlY2VpdmVkLg0KPg0KPkFuIGFkZGl0aW9uYWwgcmV2aXNpb24gdG8gdGhpcyBk cmFmdCB3aWxsIGJlIG5lY2Vzc2FyeSB0byBmaW5hbGl6ZSBUTFMgY29uZmlndXJhdGlvbiBsZWF2 ZXMgb25jZSB0aGUgaWV0Zi10bHMtY2xpZW50LXNlcnZlci1tb2RlbCB0aGF0IHRoZSBORVRDT05G IFdHIHBsYW5zIHRvIHNwaW4gb3V0IG9mIHRoZSBuZXRjb25mLXNlcnZlci1tb2RlbCBkcmFmdCBp cyBhdmFpbGFibGUuDQo+DQo+Q2hhbmdlcyBmcm9tIGZlZWRiYWNrIGZyb20gTWFoZXNoIEo6DQo+ LSBhZGRlZCBzdXBwb3J0IGZvciBjb25maWd1cmluZyBhIHN5c2xvZyBzZXJ2ZXINCj4NCj5DaGFu Z2VzIGZyb20gZmVlZGJhY2sgZnJvbSBUb20gUC46DQo+LSByZW1vdmVkIGZvdXIgZmVhdHVyZXMg Zm9yIGxvZyBhY3Rpb24gbGVhdmVzIGNvbnNvbGUsIGJ1ZmZlciwgdGVybWluYWwgYW5kIHNlc3Np b24gc2luY2UgdGhleSBhcmUgaW1wbGVtZW50ZWQgYnkgbXVsdGlwbGUgdmVuZG9ycy4gTGFjayBv ZiBzdXBwb3J0IGZvciB0aGVzZSBhY3Rpb25zIGNhbiBiZSBpbmRpY2F0ZWQgdXNpbmcgYSBkZXZp YXRpb24uDQo+LSByZW1vdmVkIGZlYXR1cmUgYnVmZmVyLWxpbWl0LW1lc3NhZ2VzIHNpbmNlIGlt cGxlbWVudGF0aW9uIGJ5IGFueSANCj52ZW5kb3IgaXMgdW5rbm93bg0KPi0gcmVuYW1lZCBmZWF0 dXJlIHRlcm1pbmFsLWZhY2lsaXR5LXVzZXItbG9nZ2luZy1jb25maWcgdG8gDQo+dGVybWluYWwt ZmFjaWxpdHktZGV2aWNlLWxvZ2dpbmcgdG8gc2hvcnRlbiB0aGUgbmFtZSBhbmQgdG8gY2xhcmlm eQ0KPi0gcmVuYW1lZCBmZWF0dXJlIHNlc3Npb24tZmFjaWxpdHktdXNlci1sb2dnaW5nLWNvbmZp ZyB0byANCj5zZXNzaW9uLWZhY2lsaXR5LXVzZXItbG9nZ2luZyB0byBzaG9ydGVuIHRoZSBuYW1l DQo+LSByZW5hbWVkIGZlYXR1cmUgc2VsZWN0b3Itc2V2b3AtY29uZmlnIHRvIGZlYXR1cmUgc2Vs ZWN0LXNldi1jb21wYXJlIA0KPnRvIHNob3J0ZW4gdGhlIG5hbWUNCj4tIHJlbmFtZWQgZmVhdHVy ZSBzZWxlY3Rvci1tYXRjaC1jb25maWcgdG8gZmVhdHVyZSBzZWxlY3QtbWF0Y2ggdG8gDQo+c2hv cnRlbiB0aGUgbmFtZQ0KPi0gcmVuYW1lZCBmZWF0dXJlIHN0cnVjdHVyZWQtZGF0YS1jb25maWcg dG8gZmVhdHVyZSBzdHJ1Y3R1cmVkLWRhdGEgdG8gDQo+c2hvcnRlbiB0aGUgbmFtZQ0KPi0gcmVu YW1lZCBmZWF0dXJlIHNpZ25lZC1tZXNzYWdlcy1jb25maWcgdG8gZmVhdHVyZSBzaWduZWQtbWVz c2FnZXMgdG8gDQo+c2hvcnRlbiB0aGUgbmFtZQ0KPi0gcmVtb3ZlZCB0aGUgbG9nLWJ1ZmZlciBs aXN0IGFuZCBuYW1lIGZyb20gbG9nLWFjdGlvbiBidWZmZXIgc2luY2UgDQo+aW1wbGVtZW50YXRp b24gYnkgYW55IHZlbmRvciBpcyB1bmtub3duDQo+LSByZW1vdmVkIHRoZSB3b3JkIGRyYWZ0IGZy b20gc2VjdGlvbiAxDQo+LSB1cGRhdGVkIHRoZSBjb3B5cmlnaHQgZGF0ZXMgYW5kIHRoZSByZXZp c2lvbiBkYXRlcyBpbiB0aGUgbW9kZWxzDQo+LSBtb3ZlZCB0aGUgZXhhbXBsZSB0byBhbiBBcHBl bmRpeA0KPi0gcmVtb3ZlZCBlLW1haWwgYWRkcmVzc2VzIGZyb20gdGhlIGFja25vd2xlZGdlbWVu dCBzZWN0aW9uDQo+DQo+Q2hhbmdlcyBmcm9tIGZlZWRiYWNrIGZyb20gQmVub2l0Og0KPi0gcmVu YW1lIG1vZHVsZSB2ZW5kb3Itc3lzbG9nLXR5cGVzIHRvIG1vZHVsZSANCj52ZW5kb3Itc3lzbG9n LXR5cGVzLWV4YW1wbGUNCj4NCj4NCj5UaGFua3MsDQo+DQo+S2lyYW4gYW5kIENseWRlDQo+DQo+ DQo+DQo+DQo+T24gNS8xMC8xNiwgMjoxNCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQo+DQo+Pg0KPj5BIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuDQo+PlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5FVENPTkYgRGF0 YSBNb2RlbGluZyBMYW5ndWFnZSBvZiB0aGUgSUVURi4NCj4+DQo+PiAgICAgICAgVGl0bGUgICAg ICAgICAgIDogU1lTTE9HIFlBTkcgTW9kZWwNCj4+ICAgICAgICBBdXRob3JzICAgICAgICAgOiBD bHlkZSBXaWxkZXMNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBLaXJhbiBLb3VzaGlrDQo+ PglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMDgudHh0 DQo+PglQYWdlcyAgICAgICAgICAgOiAzNQ0KPj4JRGF0ZSAgICAgICAgICAgIDogMjAxNi0wNS0x MA0KPj4NCj4+QWJzdHJhY3Q6DQo+PiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgZGF0YSBt b2RlbCBmb3IgdGhlIFN5c2xvZyBwcm90b2NvbCB3aGljaCBpcw0KPj4gICB1c2VkIHRvIGNvbnZl eSBldmVudCBub3RpZmljYXRpb24gbWVzc2FnZXMuDQo+Pg0KPj4NCj4+VGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC8NCj4+DQo+PlRo ZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA4DQo+Pg0K Pj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pmh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ct bW9kZWwtMDgNCj4+DQo+Pg0KPj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4+c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K Pj4NCj4+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KPj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+bmV0bW9kIG1haWxp bmcgbGlzdA0KPj5uZXRtb2RAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Mon Jun 6 01:13:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A419E12D0C0 for ; Mon, 6 Jun 2016 01:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fQY2LzFkx9a for ; Mon, 6 Jun 2016 01:13:40 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33812B055 for ; Mon, 6 Jun 2016 01:13:40 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 012411CC027D for ; Mon, 6 Jun 2016 10:13:39 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 06 Jun 2016 10:13:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] keys in instance-identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 08:13:42 -0000 Hi, section 9.13 in rfc6020-bis says: The syntax for an instance-identifier is a subset of the XPath abbreviated syntax, formally defined by the rule "instance-identifier" in Section 14. However, the ABNF only allows string literals in key predicates: key-predicate = "[" *WSP key-predicate-expr *WSP "]" key-predicate-expr = node-identifier *WSP "=" *WSP quoted-string I think this leads to problems with keys that have a numeric type. Consider this module: module ii-key { yang-version 1.1; namespace "http://example.com/ii-key"; prefix ik; list arr { key "k1"; leaf k1 { type uint8; } leaf k2 { type string; } } leaf ii { type instance-identifier { require-instance true; } } } Now, is the following instance data valid? 3 foo /ik:arr[ik:k1='03']/ik:k2 DSDL validation says it isn't: == Validating semantic constraints ... --- Failed assert at "/nc:data/ik:ii": The instance "/nc:data/ik:arr[ik:k1='03']/ik:k2" must exist. This is because XPath 1.0 spec mandates the *string* equality comparison for the "k1" key, and '3' != '03'. If we used a number in the key-predicate, then Schematron validation would succeed: /ik:arr[ik:k1=03]/ik:k2 This is however not a valid instance-identifier. There are IMO two possible solutions to this issue: 1. Avoid reference to XPath, just use the ABNF for instance-indentifier syntax, and say that the equality comparison is performed on canonical values of keys and string literals in key-predicates. 2. Permit numeric literals in key-predicate and leaf-list-predicate. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jun 6 06:10:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A40F12D787 for ; Mon, 6 Jun 2016 06:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 3Qtbc9TUmwE3 for ; Mon, 6 Jun 2016 06:10:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE7A12D785 for ; Mon, 6 Jun 2016 06:09:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8E547DE; Mon, 6 Jun 2016 15:09:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YQQFvqt9Xf47; Mon, 6 Jun 2016 15:09:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 6 Jun 2016 15:09:56 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 494C520047; Mon, 6 Jun 2016 15:09:56 +0200 (CEST) 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 6Kkev3-fBOBm; Mon, 6 Jun 2016 15:09:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E05112004E; Mon, 6 Jun 2016 15:09:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 055B53B0825E; Mon, 6 Jun 2016 15:09:53 +0200 (CEST) Date: Mon, 6 Jun 2016 15:09:53 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160606130953.GA6900@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] keys in instance-identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 13:10:02 -0000 On Mon, Jun 06, 2016 at 10:13:47AM +0200, Ladislav Lhotka wrote: > Hi, > > section 9.13 in rfc6020-bis says: > > The syntax for an instance-identifier is a subset of the XPath > abbreviated syntax, formally defined by the rule > "instance-identifier" in Section 14. > > However, the ABNF only allows string literals in key predicates: > > key-predicate = "[" *WSP key-predicate-expr *WSP "]" > > key-predicate-expr = node-identifier *WSP "=" *WSP quoted-string > > I think this leads to problems with keys that have a numeric > type. Consider this module: > > module ii-key { > yang-version 1.1; > namespace "http://example.com/ii-key"; > prefix ik; > > list arr { > key "k1"; > leaf k1 { > type uint8; > } > leaf k2 { > type string; > } > } > leaf ii { > type instance-identifier { > require-instance true; > } > } > } > > Now, is the following instance data valid? > > xmlns:ik="http://example.com/ii-key"> > > 3 > foo > > /ik:arr[ik:k1='03']/ik:k2 > > > DSDL validation says it isn't: > > == Validating semantic constraints ... > --- Failed assert at "/nc:data/ik:ii": > The instance "/nc:data/ik:arr[ik:k1='03']/ik:k2" must exist. > > This is because XPath 1.0 spec mandates the *string* equality comparison > for the "k1" key, and '3' != '03'. If we used a number in the > key-predicate, then Schematron validation would succeed: > > /ik:arr[ik:k1=03]/ik:k2 > > This is however not a valid instance-identifier. > > There are IMO two possible solutions to this issue: > > 1. Avoid reference to XPath, just use the ABNF for instance-indentifier > syntax, and say that the equality comparison is performed on > canonical values of keys and string literals in key-predicates. > > 2. Permit numeric literals in key-predicate and leaf-list-predicate. > Section 7.6: A leaf node has a value, but no child nodes in the data tree. Conceptually, the value in the data tree is always in the canonical form (see Section 9.1). Section 7.7: Conceptually, the values in the data tree are always in the canonical form (see Section 9.1). Section 7.5.3: Note that since all leaf values in the data tree are conceptually stored in their canonical form (see Section 9.1), any XPath comparisons are done on the canonical value. Do you suggest that there should be additional notes inserted at various places? The general spirit I think has always been to use canonical forms of the values. /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 Jun 6 06:43:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA0812D79F for ; Mon, 6 Jun 2016 06:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 Xl6dEZZibPwj for ; Mon, 6 Jun 2016 06:43:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F48312D095 for ; Mon, 6 Jun 2016 06:43:10 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:2879:dd37:cb32:3c99] (unknown [IPv6:2001:718:1a02:1:2879:dd37:cb32:3c99]) by mail.nic.cz (Postfix) with ESMTPSA id 62F8360C1F; Mon, 6 Jun 2016 15:43:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465220588; bh=+6cBZtx3VSJLhramxsto7mYDWHgUCnZg38sUtuPKkRs=; h=From:Date:To; b=DLNncgWPLxB3QBOza06S1yULVaqsh9fxy8HPt/kmAKbj5K6ekj5V11W79GlqwEi0o QT69tQBXrXO6JVxGDVxnNIcHeR1fwYfaB+ZhxX3z9OOz8ukEwV0JVtC8lWLluNM9zI Y5NnDAuJVPYReS/uwEA7FhnJFurIvv6c2lK85ppw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160606130953.GA6900@elstar.local> Date: Mon, 6 Jun 2016 15:43:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160606130953.GA6900@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] keys in instance-identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 13:43:13 -0000 > On 06 Jun 2016, at 15:09, Juergen Schoenwaelder = wrote: >=20 > On Mon, Jun 06, 2016 at 10:13:47AM +0200, Ladislav Lhotka wrote: >> Hi, >>=20 >> section 9.13 in rfc6020-bis says: >>=20 >> The syntax for an instance-identifier is a subset of the XPath >> abbreviated syntax, formally defined by the rule >> "instance-identifier" in Section 14. >>=20 >> However, the ABNF only allows string literals in key predicates: >>=20 >> key-predicate =3D "[" *WSP key-predicate-expr *WSP "]" >>=20 >> key-predicate-expr =3D node-identifier *WSP "=3D" *WSP = quoted-string >>=20 >> I think this leads to problems with keys that have a numeric >> type. Consider this module: >>=20 >> module ii-key { >> yang-version 1.1; >> namespace "http://example.com/ii-key"; >> prefix ik; >>=20 >> list arr { >> key "k1"; >> leaf k1 { >> type uint8; >> } >> leaf k2 { >> type string; >> } >> } >> leaf ii { >> type instance-identifier { >> require-instance true; >> } >> } >> } >>=20 >> Now, is the following instance data valid? >>=20 >> > xmlns:ik=3D"http://example.com/ii-key"> >> >> 3 >> foo >> >> /ik:arr[ik:k1=3D'03']/ik:k2 >> >>=20 >> DSDL validation says it isn't: >>=20 >> =3D=3D Validating semantic constraints ... >> --- Failed assert at "/nc:data/ik:ii": >> The instance "/nc:data/ik:arr[ik:k1=3D'03']/ik:k2" must exist. >>=20 >> This is because XPath 1.0 spec mandates the *string* equality = comparison >> for the "k1" key, and '3' !=3D '03'. If we used a number in the >> key-predicate, then Schematron validation would succeed: >>=20 >> /ik:arr[ik:k1=3D03]/ik:k2 >>=20 >> This is however not a valid instance-identifier. >>=20 >> There are IMO two possible solutions to this issue: >>=20 >> 1. Avoid reference to XPath, just use the ABNF for = instance-indentifier >> syntax, and say that the equality comparison is performed on >> canonical values of keys and string literals in key-predicates. >>=20 >> 2. Permit numeric literals in key-predicate and leaf-list-predicate. >>=20 >=20 > Section 7.6: >=20 > A leaf node has a value, but no child nodes in the data tree. > Conceptually, the value in the data tree is always in the canonical > form (see Section 9.1). >=20 > Section 7.7: >=20 > Conceptually, the values in the data tree are always in the = canonical > form (see Section 9.1). >=20 > Section 7.5.3: >=20 > Note that since all leaf values in the data tree are conceptually > stored in their canonical form (see Section 9.1), any XPath > comparisons are done on the canonical value. For the leaf that's in the data tree =E2=80=93 3 =E2=80=93 = the canonical value is indeed used. And instance-identifier has no = canonical value. >=20 > Do you suggest that there should be additional notes inserted at > various places? The general spirit I think has always been to use > canonical forms of the values. We can assume that the data tree has all leaf values in their canonical = form, but after that we must IMO exactly follow the XPath semantics = because otherwise we could easily run into troubles. For example, = sometimes the canonical form of comparison operands cannot be = determined: container top { must "foo + bar < '3'"; leaf foo { type uint8; } leaf bar { type decimal64 { fraction-digits 2; } } } The canonical form of the sum foo + bar is undefined. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jun 6 07:03:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C228312D7B1 for ; Mon, 6 Jun 2016 07:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 Feq-zIRlRvIK for ; Mon, 6 Jun 2016 07:03:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB99012D6B1 for ; Mon, 6 Jun 2016 07:03:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BA7C411CC; Mon, 6 Jun 2016 16:03:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ykXFE2nzhIJC; Mon, 6 Jun 2016 16:03:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 6 Jun 2016 16:03:25 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 180E320058; Mon, 6 Jun 2016 16:02:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XgHDHRgs1q-N; Mon, 6 Jun 2016 16:02:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD79720051; Mon, 6 Jun 2016 16:02:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 884003B087C2; Mon, 6 Jun 2016 16:02:06 +0200 (CEST) Date: Mon, 6 Jun 2016 16:02:06 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160606140206.GA7125@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20160606130953.GA6900@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] keys in instance-identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 14:03:33 -0000 On Mon, Jun 06, 2016 at 03:43:23PM +0200, Ladislav Lhotka wrote: > > > On 06 Jun 2016, at 15:09, Juergen Schoenwaelder wrote: > > > > On Mon, Jun 06, 2016 at 10:13:47AM +0200, Ladislav Lhotka wrote: > >> Hi, > >> > >> section 9.13 in rfc6020-bis says: > >> > >> The syntax for an instance-identifier is a subset of the XPath > >> abbreviated syntax, formally defined by the rule > >> "instance-identifier" in Section 14. > >> > >> However, the ABNF only allows string literals in key predicates: > >> > >> key-predicate = "[" *WSP key-predicate-expr *WSP "]" > >> > >> key-predicate-expr = node-identifier *WSP "=" *WSP quoted-string > >> > >> I think this leads to problems with keys that have a numeric > >> type. Consider this module: > >> > >> module ii-key { > >> yang-version 1.1; > >> namespace "http://example.com/ii-key"; > >> prefix ik; > >> > >> list arr { > >> key "k1"; > >> leaf k1 { > >> type uint8; > >> } > >> leaf k2 { > >> type string; > >> } > >> } > >> leaf ii { > >> type instance-identifier { > >> require-instance true; > >> } > >> } > >> } > >> > >> Now, is the following instance data valid? > >> > >> >> xmlns:ik="http://example.com/ii-key"> > >> > >> 3 > >> foo > >> > >> /ik:arr[ik:k1='03']/ik:k2 > >> > >> > >> DSDL validation says it isn't: > >> > >> == Validating semantic constraints ... > >> --- Failed assert at "/nc:data/ik:ii": > >> The instance "/nc:data/ik:arr[ik:k1='03']/ik:k2" must exist. > >> > >> This is because XPath 1.0 spec mandates the *string* equality comparison > >> for the "k1" key, and '3' != '03'. If we used a number in the > >> key-predicate, then Schematron validation would succeed: > >> > >> /ik:arr[ik:k1=03]/ik:k2 > >> > >> This is however not a valid instance-identifier. > >> > >> There are IMO two possible solutions to this issue: > >> > >> 1. Avoid reference to XPath, just use the ABNF for instance-indentifier > >> syntax, and say that the equality comparison is performed on > >> canonical values of keys and string literals in key-predicates. > >> > >> 2. Permit numeric literals in key-predicate and leaf-list-predicate. > >> > > > > Section 7.6: > > > > A leaf node has a value, but no child nodes in the data tree. > > Conceptually, the value in the data tree is always in the canonical > > form (see Section 9.1). > > > > Section 7.7: > > > > Conceptually, the values in the data tree are always in the canonical > > form (see Section 9.1). > > > > Section 7.5.3: > > > > Note that since all leaf values in the data tree are conceptually > > stored in their canonical form (see Section 9.1), any XPath > > comparisons are done on the canonical value. > > For the leaf that's in the data tree – 3 – the canonical value is indeed used. And instance-identifier has no canonical value. > > > > > Do you suggest that there should be additional notes inserted at > > various places? The general spirit I think has always been to use > > canonical forms of the values. > > We can assume that the data tree has all leaf values in their canonical form, but after that we must IMO exactly follow the XPath semantics because otherwise we could easily run into troubles. For example, sometimes the canonical form of comparison operands cannot be determined: > > container top { > must "foo + bar < '3'"; > leaf foo { > type uint8; > } > leaf bar { > type decimal64 { > fraction-digits 2; > } > } > } > > The canonical form of the sum foo + bar is undefined. This example does not seem to relate to instance identifiers. I am not sure what you are asking for. OLD NEW style of text proposals would help me. /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 Jun 6 07:21:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E944F12D7C4 for ; Mon, 6 Jun 2016 07:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 4p_inyRiXkqk for ; Mon, 6 Jun 2016 07:21:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C42012D0F4 for ; Mon, 6 Jun 2016 07:21:30 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:2879:dd37:cb32:3c99] (unknown [IPv6:2001:718:1a02:1:2879:dd37:cb32:3c99]) by mail.nic.cz (Postfix) with ESMTPSA id 49F7D60FC6; Mon, 6 Jun 2016 16:21:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465222889; bh=7sMi4SPuYaAgl8JOF7xQ3GXOl1bo0nNscG1hwZIqYr0=; h=From:Date:To; b=C8gvaCydoBxGiJaKwh7hnM74pu71MQdPp47olM3OF5kEwF6km949SVI+KjlcBKQJr QAQ8IoShDhWtGsLR/H3WMPQBi9bxFY2WmiTTfU442/zXwGJUr3q0/CUnejYgoaZdXn CvZgwVNsNlC7SIfIYh4wZa/nst4Su8i0dMqE1mbc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160606140206.GA7125@elstar.local> Date: Mon, 6 Jun 2016 16:21:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75A8B2DB-7D6D-4D65-BCCD-3B747A0BFC26@nic.cz> References: <20160606130953.GA6900@elstar.local> <20160606140206.GA7125@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] keys in instance-identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 14:21:34 -0000 > On 06 Jun 2016, at 16:02, Juergen Schoenwaelder = wrote: >=20 > On Mon, Jun 06, 2016 at 03:43:23PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 06 Jun 2016, at 15:09, Juergen Schoenwaelder = wrote: >>>=20 >>> On Mon, Jun 06, 2016 at 10:13:47AM +0200, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> section 9.13 in rfc6020-bis says: >>>>=20 >>>> The syntax for an instance-identifier is a subset of the XPath >>>> abbreviated syntax, formally defined by the rule >>>> "instance-identifier" in Section 14. >>>>=20 >>>> However, the ABNF only allows string literals in key predicates: >>>>=20 >>>> key-predicate =3D "[" *WSP key-predicate-expr *WSP "]" >>>>=20 >>>> key-predicate-expr =3D node-identifier *WSP "=3D" *WSP = quoted-string >>>>=20 >>>> I think this leads to problems with keys that have a numeric >>>> type. Consider this module: >>>>=20 >>>> module ii-key { >>>> yang-version 1.1; >>>> namespace "http://example.com/ii-key"; >>>> prefix ik; >>>>=20 >>>> list arr { >>>> key "k1"; >>>> leaf k1 { >>>> type uint8; >>>> } >>>> leaf k2 { >>>> type string; >>>> } >>>> } >>>> leaf ii { >>>> type instance-identifier { >>>> require-instance true; >>>> } >>>> } >>>> } >>>>=20 >>>> Now, is the following instance data valid? >>>>=20 >>>> >>> xmlns:ik=3D"http://example.com/ii-key"> >>>> >>>> 3 >>>> foo >>>> >>>> /ik:arr[ik:k1=3D'03']/ik:k2 >>>> >>>>=20 >>>> DSDL validation says it isn't: >>>>=20 >>>> =3D=3D Validating semantic constraints ... >>>> --- Failed assert at "/nc:data/ik:ii": >>>> The instance "/nc:data/ik:arr[ik:k1=3D'03']/ik:k2" must exist. >>>>=20 >>>> This is because XPath 1.0 spec mandates the *string* equality = comparison >>>> for the "k1" key, and '3' !=3D '03'. If we used a number in the >>>> key-predicate, then Schematron validation would succeed: >>>>=20 >>>> /ik:arr[ik:k1=3D03]/ik:k2 >>>>=20 >>>> This is however not a valid instance-identifier. >>>>=20 >>>> There are IMO two possible solutions to this issue: >>>>=20 >>>> 1. Avoid reference to XPath, just use the ABNF for = instance-indentifier >>>> syntax, and say that the equality comparison is performed on >>>> canonical values of keys and string literals in key-predicates. >>>>=20 >>>> 2. Permit numeric literals in key-predicate and = leaf-list-predicate. >>>>=20 >>>=20 >>> Section 7.6: >>>=20 >>> A leaf node has a value, but no child nodes in the data tree. >>> Conceptually, the value in the data tree is always in the canonical >>> form (see Section 9.1). >>>=20 >>> Section 7.7: >>>=20 >>> Conceptually, the values in the data tree are always in the = canonical >>> form (see Section 9.1). >>>=20 >>> Section 7.5.3: >>>=20 >>> Note that since all leaf values in the data tree are conceptually >>> stored in their canonical form (see Section 9.1), any XPath >>> comparisons are done on the canonical value. >>=20 >> For the leaf that's in the data tree =E2=80=93 3 =E2=80=93= the canonical value is indeed used. And instance-identifier has no = canonical value. >>=20 >>>=20 >>> Do you suggest that there should be additional notes inserted at >>> various places? The general spirit I think has always been to use >>> canonical forms of the values. >>=20 >> We can assume that the data tree has all leaf values in their = canonical form, but after that we must IMO exactly follow the XPath = semantics because otherwise we could easily run into troubles. For = example, sometimes the canonical form of comparison operands cannot be = determined: >>=20 >> container top { >> must "foo + bar < '3'"; >> leaf foo { >> type uint8; >> } >> leaf bar { >> type decimal64 { >> fraction-digits 2; >> } >> } >> } >>=20 >> The canonical form of the sum foo + bar is undefined. >=20 > This example does not seem to relate to instance identifiers. It doesn't, but you referred to generic rules for XPath usage in YANG. = My point is that canonical form cannot be applied to literal values = appearing in XPath expressions. > I am not > sure what you are asking for. OLD NEW style of text proposals would > help me. This is for my option #2: OLD key-predicate-expr =3D node-identifier *WSP "=3D" *WSP quoted-string NEW key-predicate-expr =3D node-identifier *WSP "=3D" *WSP ( = quoted-string / decimal-value ) Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jun 6 10:09:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3151312D735 for ; Mon, 6 Jun 2016 10:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 we_EBRaXG-U3 for ; Mon, 6 Jun 2016 10:08:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C8412D864 for ; Mon, 6 Jun 2016 10:08:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 23E4F10EF; Mon, 6 Jun 2016 19:08:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cJczhCcQMqbR; Mon, 6 Jun 2016 19:08:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 6 Jun 2016 19:08:52 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F69E2004E; Mon, 6 Jun 2016 19:08:52 +0200 (CEST) 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 EPAJE33lT9Jd; Mon, 6 Jun 2016 19:08:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54B2220047; Mon, 6 Jun 2016 19:08:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6FE1A3B08CB9; Mon, 6 Jun 2016 19:08:49 +0200 (CEST) Date: Mon, 6 Jun 2016 19:08:48 +0200 From: Juergen Schoenwaelder To: "Dale R. Worley" , Martin Bjorklund Message-ID: <20160606170848.GA7405@elstar.local> Mail-Followup-To: "Dale R. Worley" , Martin Bjorklund , netmod@ietf.org References: <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz> <87twhbfiv3.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87twhbfiv3.fsf@hobgoblin.ariadne.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:08:58 -0000 On Thu, Jun 02, 2016 at 04:14:56PM -0400, Dale R. Worley wrote: > Martin Bjorklund wrote: > > Also, the text needs to mention leaf-lists. This gives: > > > > The leafref type is restricted to the value space of some leaf or > > leaf-list node in the schema tree and optionally further restricted > > by corresponding instance nodes in the data tree. The "path" > > substatement (Section 9.9.2) is used to identify the referred leaf > > or leaf-list node in the schema tree. The value space of the > > referring node is the value space of the referred node. > > > > If the "require-instance" property is "true", there MUST exist an > > node in the data tree, or a node with a default value in use (see > > Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf > > or leaf-list node with the same value as the leafref value in a > > valid data tree. > > > > If the referring node represents configuration data, and the > > "require-instance" property (Section 9.9.3) is "true", the referred > > node MUST also represent configuration. > > How about: > > The leafref type contains an XPath expression in the "path" > substatement. Due to the restrictions on the expression, all > instances in the result set of the expression evaluated on all > possible data tree are instances of one single data node, called the > "referred node". I think the first sentence is potentially misleading (the "path" expression does not contain arbitrary XPath) and the second sentence is really hard to parse - if it makes sense at all the way it is written. > The leafref type has the value space of the type of the referred > node. > > If the "require-instance" property is "true", the leafref type also > imposes a constraint on any node of its type: the value must be the > same as that of some instance in the data tree, or an instance with > a default value in use, selected by the XPath expression. Such a > constraint is enforced according to the rules in Section 8. > > If the referring node represents configuration data, and the > "require-instance" property (Section 9.9.3) is "true", the referred > node MUST also represent configuration. > > I started with a discussion of the XPath expression to state explicitly > that all selected instances must be instances of one data node, and used > that to define "referred node". With that clarified, it's easier to > state the conditions that we care about. Martin's original text says 'schema node' so there is not confusion that I see. The referred node is in the schema tree, not in the data tree. > I want to clearly separate the question of value space (which is > enforced roughly any time XML using the module is parsed) from the > constraint (which is enforced only at the times specified in section 8). > > I do exploit the convention that default values cause instance nodes to > exist in the data tree in a sort of virtual sense, in that the XPath > expression can return them in its data set. But I think that is > consistent with the philosophy of Yang. Does that need to be stated > more explicitly? I think we should go with Martin's text and close this issue. > Also, in the lexicon: > > o anydata: A data node that can contain an unknown set of nodes that > can be modelled by YANG, except anyxml. > > o anyxml: A data node that can contain an unknown chunk of XML data. > > Both definitions should start with "a data node *whose instances* can > contain..." I would leave this is Martin's discretion (since he knows best whether this causes inconsistencies with other wordings in the document). Martin, how close are we to have a final version addressing all the review comments we received during the journey through the IESG? /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 Jun 6 11:07:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A72712D14D for ; Mon, 6 Jun 2016 11:07:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "In-Reply-To" X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 Ia7heGraJIXZ for ; Mon, 6 Jun 2016 11:07:00 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 0E4D812B040 for ; Mon, 6 Jun 2016 11:06:59 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by comcast with SMTP id 9yokbnf4M8DPn9yvTbFb5Z; Mon, 06 Jun 2016 18:06:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465236419; bh=+0YBzgHZSMdRNk7cVhEwhHLF82MJJym6leTK0cf0KOU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=rgSrhKQ1CDzoin4mI0vFeQLJ0EjS51zJauYU5XxRAE/X/HwN/UIWYfl/hsqIzRrk6 07KAfSBwRw8fbuGIEuoHtOwD98K2/7kdoBbTa8+EyLPOT5n7XJlEukiFw2xRaFEPck Kux7G38WRjvuaa0lsikMi+z5MmAqP74HQOaPMRz+rFOgGh/2H/9MdFf/wapf883w7T bu9N93Jg49pUkDE2QU6/Uy1Zxx5+AJluHmC1akGDUv4LPxIeH+UFf2XzOAz2KUXEj9 lKOW4TO0m5P1+Bbb1svQ4lw6uhb1/WI2EcsYpT4cW94oxvURwEUu5uO9u6A03SjEgn m2C7NofJm/Srg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id 3W6y1t00M1nMCLR01W6yH3; Mon, 06 Jun 2016 18:06:59 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u56I6veC013660 for ; Mon, 6 Jun 2016 14:06:57 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u56I6vb2013655; Mon, 6 Jun 2016 14:06:57 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org In-Reply-To: <20160606170848.GA7405@elstar.local> (j.schoenwaelder@jacobs-university.de) References: <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz> <87twhbfiv3.fsf@hobgoblin.ariadne.com> <20160606170848.GA7405@elstar.local> Sender: worley@ariadne.com (Dale R. Worley) In-reply-to: <20160606170848.GA7405@elstar.local> Date: Mon, 06 Jun 2016 14:06:57 -0400 Message-ID: <87mvmyb39a.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:07:01 -0000 A difficulty I have with the current wording is that it doesn't point out the crucial fact about leafref that the XPath expression can only select elements that are instantiations of one particular data node. I don't know XPath, but it seems that that is not a general property of XPath expressions, you seem to be able to write XPath expressions that select heterogenous groups of elements. So it's worth pointing out that the allowed XPath expressions can't do that, and that is because of the restriction that the expression must match path-arg. Perhaps my problem is that XPath is almost always used in this style, and so the limitations in leafref aren't anything unusual. Dale From nobody Mon Jun 6 11:15:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5C912D8B2 for ; Mon, 6 Jun 2016 11:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elQEy3SiTCg5 for ; Mon, 6 Jun 2016 11:14:59 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 C958B12D8A5 for ; Mon, 6 Jun 2016 11:14:58 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id h19so147980174ywc.0 for ; Mon, 06 Jun 2016 11:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=TxrvCSEILvNTc6KvNrQ7jRNmaoX9NqvA/9pOcE2SBq4=; b=AT4HAXTctTvxi7+5JzaJNtS/AqVPVufTkHH7JGaVWy4kpVneO1lKrccZAlRsUaATre GkcuSRDWUI/hg2CSK9gjs+LLTh/YKGuZU7c69qOxO6SYuOVZ0WzcbVfPE6nU7Qy/FBwl c2UhyJ4sDnjIBdhUoxbH9AcxUjy6VSM3bSg8eZQFLb9EJODDBVnqIoHGgOkeI7nkVDED uBnNZ2GD5J+Jupy3SRJIK3GfWd8WZ4JpXb//BdW37OdaEkyf6G77E9nIYSaCpxBdG3dI koLsEuFakes8l3LMkcn5FbSWj70xLbIUWdh2UNqD1XRsBw2Z7KZ8ASZqnj31QJQ4+KHT NmKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=TxrvCSEILvNTc6KvNrQ7jRNmaoX9NqvA/9pOcE2SBq4=; b=L+9ibw9pjcfgYcly8Mc14oeuDi636qxFx+JfXoimNFZPyWA5XAQ0J6YMaDEM6i2WOH 4KM2BFqrg2tFut77+qJEG4YvMlpkkDGmp90A/lrCVL0FMnX0dmh/nuE4UKV3vECsZA+H ZyaT4I7m1AZ2RKiRD8lnrQosa19NqJg+Naa3WGRi+R2E7kgpm1yBt8D5NVVkqmFfyEy9 okc8mCa2xFvzswWwxWIY9rYllKMo039rKU0SkxLsFVnIIlcz2sS6mx1AGwunIHEpqpdR +Op6IF2FIHsHpv9m+RRmqxp3esyxVpv80EHI1Y45fimwY26EFUD5Ig9Fy3jYOl4R0dYV mBGA== X-Gm-Message-State: ALyK8tI2aZ6Lq0UJqaPov4ufP7xgtQzWEpgiYrlcSllwJspR2elBmifRSNcJajx1iQ270664VgrEtD1Dbysk1g== MIME-Version: 1.0 X-Received: by 10.129.111.132 with SMTP id k126mr12016561ywc.11.1465236897550; Mon, 06 Jun 2016 11:14:57 -0700 (PDT) Received: by 10.37.115.68 with HTTP; Mon, 6 Jun 2016 11:14:57 -0700 (PDT) In-Reply-To: <87mvmyb39a.fsf@hobgoblin.ariadne.com> References: <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz> <87twhbfiv3.fsf@hobgoblin.ariadne.com> <20160606170848.GA7405@elstar.local> <87mvmyb39a.fsf@hobgoblin.ariadne.com> Date: Mon, 6 Jun 2016 11:14:57 -0700 Message-ID: From: Andy Bierman To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a11492606ca85db0534a00c51 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:15:02 -0000 --001a11492606ca85db0534a00c51 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 6, 2016 at 11:06 AM, Dale R. Worley wrote: > A difficulty I have with the current wording is that it doesn't point > out the crucial fact about leafref that the XPath expression can only > select elements that are instantiations of one particular data node. I > don't know XPath, but it seems that that is not a general property of > XPath expressions, you seem to be able to write XPath expressions that > select heterogenous groups of elements. So it's worth pointing out that > the allowed XPath expressions can't do that, and that is because of the > restriction that the expression must match path-arg. > > Perhaps my problem is that XPath is almost always used in this style, > and so the limitations in leafref aren't anything unusual. > > I can say that the implementation details are much easier than the convoluted text might imply. 1) the value MUST be valid for the final "type" statement. The server validates that the value is valid for the type of the pointed-at leaf. (Or final pointed-at leaf if it is also a leafref). 2) If require-instance is true then the value MUST also be in use by the first pointed-at leaf. i.e., the value is valid for the data type and there exists an instance of the pointed-at leaf with the same canonical value > Dale > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11492606ca85db0534a00c51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 6, 2016 at 11:06 AM, Dale R. Worley <<= a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
A difficulty I have = with the current wording is that it doesn't point
out the crucial fact about leafref that the XPath expression can only
select elements that are instantiations of one particular data node.=C2=A0 = I
don't know XPath, but it seems that that is not a general property of XPath expressions, you seem to be able to write XPath expressions that
select heterogenous groups of elements.=C2=A0 So it's worth pointing ou= t that
the allowed XPath expressions can't do that, and that is because of the=
restriction that the expression must match path-arg.

Perhaps my problem is that XPath is almost always used in this style,
and so the limitations in leafref aren't anything unusual.


I can say that the implementation deta= ils are much easier than the convoluted
text might imply.

1) the value MUST be valid for the final "type"= statement.
The server validates that the value is valid for the = type of the pointed-at leaf.
(Or final pointed-at leaf if it is a= lso a leafref).

2) If require-instance is true the= n the value MUST also be in use by
the first pointed-at leaf. i.e= ., the value is valid for the data type and
there exists an insta= nce of the pointed-at leaf with the same canonical value
=C2=A0
Dale


Andy

=
=C2=A0

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

--001a11492606ca85db0534a00c51-- From nobody Mon Jun 6 11:44:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11B512D7D5 for ; Mon, 6 Jun 2016 11:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 I1hIU8nJhzUC for ; Mon, 6 Jun 2016 11:44:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE0912D5AE for ; Mon, 6 Jun 2016 11:44:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5052210B3; Mon, 6 Jun 2016 20:44:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XtG3f4fMwDS3; Mon, 6 Jun 2016 20:44:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 6 Jun 2016 20:44:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBA9E20047; Mon, 6 Jun 2016 20:44:14 +0200 (CEST) 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 Fb2cXg0_PCaQ; Mon, 6 Jun 2016 20:44:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DB432004E; Mon, 6 Jun 2016 20:44:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E2B203B0911D; Mon, 6 Jun 2016 20:44:11 +0200 (CEST) Date: Mon, 6 Jun 2016 20:44:11 +0200 From: Juergen Schoenwaelder To: "Dale R. Worley" Message-ID: <20160606184411.GC7624@elstar.local> Mail-Followup-To: "Dale R. Worley" , netmod@ietf.org References: <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz> <87twhbfiv3.fsf@hobgoblin.ariadne.com> <20160606170848.GA7405@elstar.local> <87mvmyb39a.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mvmyb39a.fsf@hobgoblin.ariadne.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:44:18 -0000 On Mon, Jun 06, 2016 at 02:06:57PM -0400, Dale R. Worley wrote: > A difficulty I have with the current wording is that it doesn't point > out the crucial fact about leafref that the XPath expression can only > select elements that are instantiations of one particular data node. I > don't know XPath, but it seems that that is not a general property of > XPath expressions, you seem to be able to write XPath expressions that > select heterogenous groups of elements. So it's worth pointing out that > the allowed XPath expressions can't do that, and that is because of the > restriction that the expression must match path-arg. > > Perhaps my problem is that XPath is almost always used in this style, > and so the limitations in leafref aren't anything unusual. Does section 9.9.2, which describes the path statement, not describe this is sufficient detail? Note also that 9.9.2 is a subsection of 9.9, which describes the leafref type. /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 Jun 6 14:34:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9093C12D61A for ; Mon, 6 Jun 2016 14:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 bBi8ENVJx9RA for ; Mon, 6 Jun 2016 14:34:24 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 631E112B00D for ; Mon, 6 Jun 2016 14:34:24 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by comcast with SMTP id A29nbegm3juYRA2ABboSu4; Mon, 06 Jun 2016 21:34:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465248863; bh=z+mAfe4x95ilqmvW55MAE7jgMDTvJzanlhzQPpB7EPU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=k2OG9yqtX+Nw2SFVDNAhrBZ0P+8VckHCDkCZ17THkUv+Igw99N1QsgV2LopmcOrKG ulBMeK5bW/i2NljllV5A9QWUTpjKzQLpdTn+VZRS67XGvB1HuhmlV7JtzDRrgvtGLY wRLKMBVAcxegdUJs8iROPe/7rWbwosFg5MXZY6I3NDAIzsLxe0RgVPNEwykT4Mq9eL 0X0RFTG/7R/1QXHkSzodwHUF99LoTfZJ+j6Ud52dkcyQLkPVpyHbebSk6ccEf894+Z 0gWOOAVGaKe+haeA3VFjit2Gg0Lgv3Xnc5OO2hkBAbME6+GPjmZeNDIv7ium2Q87Qd hvkWFxEXo4AyA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-10v.sys.comcast.net with comcast id 3ZaN1t00V1nMCLR01ZaPiE; Mon, 06 Jun 2016 21:34:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u56LYM0Z002531 for ; Mon, 6 Jun 2016 17:34:22 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u56LYL0J002527; Mon, 6 Jun 2016 17:34:21 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org In-Reply-To: <20160523.154309.848500367505009627.mbj@tail-f.com> References: <877feyrdz9.fsf@hobgoblin.ariadne.com> <20160523.154309.848500367505009627.mbj@tail-f.com> <20160523.154309.848500367505009627.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 06 Jun 2016 17:34:21 -0400 Message-ID: <87vb1m9f36.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 21:34:26 -0000 (This is the first part of my response, which I am sending seperately to speed things up.) Martin Bjorklund wrote: > worley@ariadne.com (Dale R. Worley) wrote: > > Martin Bjorklund wrote on Mon, 23 May 2016 15:43:09 +0200 (CEST): > > > worley@ariadne.com (Dale R. Worley) wrote: > > > > Almost all of these points I'm happy with the authors fixing in the > > manner they suggest. The points where I have further comment are: > > > > > > The incompatibilities should be marked whether the old, incompatible > > > > usage always causes an error "at compile time", "at run time", or > > > > changed behavior. > > > > > > Ok, but I'd like to avoid the term "compile-time" here. > > > > True... The distinction I'm looking for is "Incompatible usage will > > cause an error report before the software is put into operation." > > vs. "Incompatible usage will cause an error report when the software is > > in operation." vs. "Incompatible usage will cause a difference in > > behavior without an error report." > > The spec defines what is legal YANG. How this is enforced by tools > must be up to the tools, right? It depends. When reading about incompatibilities, it's really nice to be informed what will happen. E.g., if the compiler will catch it, you just recompile the code and watch for error messages. If it will cause incompatible run-time behavior, you have to inspect the code, which is a lot of work. > > > How about: > > > > > > The following changes are not backwards compatible with YANG version > > > 1: > > > > > > o Changed the rules for the interpretation of escaped characters in > > > double quoted strings. This is an backwards incompatible change > > > from YANG version 1. A module that uses a character sequence that > > > is now illegal must change the string to match the new rules. See > > > Section 6.1.3 for details. > > > > > > o An unquoted string cannot contain any single or double quote > > > characters. This is an backwards incompatible change from YANG > > > version 1. A module that uses such quote characters must change > > > the string to match the new rules. See Section 6.1.3 for details. > > > > I assume that the first two situations will cause an error report before > > the module is put into production. > > > > > o Made noncharacters illegal in the built-in type "string". This > > > change affects the run-time behavior of YANG-based protocols. > > > > What happens if you attempt to use a noncharacter in a string? > > This depends on the protocol. noncharacters are illegal. Maybe in > protocol A you can't even encode noncharacters, but in protocol B > you'll get a protocol error from the other side if you send > noncharacters. Really, the question is "What does 'illegal' mean?" Of course, it means that you shouldn't do it, but does it also contain assertions that some particular stage of processing will explicitly flag it? > > It might be worth inserting a definition of "node" as shorthand for > > "data node", as there seems to be no definition of "node" alone, but it > > is commonly used to mean "data node". In particular, the reader needs > > to be fully aware that "node" is a node in the schema tree, not an > > instantiation thereof. > > But saying that "node" means "data node" is not correct. Sometimes > the text talk about "schema nodes" etc. I think it is better to > qualify the usage of "node" where necessary to avoid the ambiguity. OK, I see. But since I was getting confused, it suggests that there are various places where "node" is used where it wasn't clear from context whether it was a data node or a schema node. > > > > It would be useful to insert a note somewhere that all data is either > > > > "configuration" or "state" data. It's hard to learn that now, because > > > > the terms "configuration data" and "state data" are defined only by > > > > reference to RFC 6241. > > > > > > But this is not strictly correct. For example RPC input is neither > > > config nor state. Section 3 has: > > > > > > o data tree: An instantiated tree of any data modeled with YANG, > > > e.g., configuration data, state data, combined configuration and > > > state data, RPC or action input, RPC or action output, or > > > notification. > > > > Section 4.1 contains a similar statement. > > > > I think the problem I'm having is with the first sentences of 4.2.3: > > > > YANG can model state data, as well as configuration data, based on > > the "config" statement. > > > > At first read, this suggests that data is partitioned into > > "configuration data" and "state data". What's really happening is that > > there are various sorts of data, but some contexts admit a mixture of > > configuration and state data, so the data model definitions of those > > contexts requires that individual data items can be flagged as > > configuration vs. data. Maybe starting 4.2.3 like this would work: > > > > In some contexts, data modeled by YANG can contain mixtures of state > > data and configuration data, based on the "config" statement. When a > > node is tagged with "config false", its subhierarchy is flagged as > > state data. > > I think that this might be a bit confusing (which contexts? what > exacyly is this mixture?) and too detailed for this introductory > section. I would perfer to keep the original text. That leaves the problem that there are forms that are neither state data nor configuration data. Also, the phrasing is odd in that it seems to assume that configuration data is sort of a default condition and state data is an exception. I think what was intended is YANG can differentiate state data and configuration data within one instantiated tree, based on the "config" statement. > > > > - section 5.1.2 > > > > > > > > YANG allows modeling of data in multiple hierarchies, where data may > > > > have more than one top-level node. Models that have multiple top- > > > > level nodes are sometimes convenient, and are supported by YANG. > > > > > > > > Any single module seems to define only one data structure, the one > > > > whose elements are the items listed in the module, and Yang doesn't > > > > seem to provide for any sort of "model" definition other than a > > > > module. Or are the nodes at the top level within the module all > > > > usable as independent data structures? > > > > > > The term "data structure" isn't used in the document. YANG allows > > > a module to define more than one subtree. > > > > OK, I think I see where I was confused. I think that would have been > > avoided if the 5.1.2 started: > > > > YANG allows modeling of data in multiple hierarchies. Each top-level > > data node in a module defines an independent hierarchy. Models that > > have ... > > What does "independent" imply? They are not necessarily semantically > independent. Maybe s/independent/separate/ ? Yes, "separate" would work well. Here, I'll mention again this point from another e-mail: The second sentence of section 4.1 suggests that a Yang module defines *one* hierarchy of data, whereas it seems like any top-level data node in a module has meaning separately and can be instantiated seperately. > > > > - section 5.5 > > > > > > > > This section talks a great deal about why scoping is done, but isn't > > > > specifically clear what the rules are. (Traditionally, the rule is > > > > stated as either what range of source text a particular definition is > > > > visible in, or given an identifier use, how the matching definition is > > > > found.) > > > > > > > > Scoped definitions MUST NOT shadow definitions at a higher scope. A > > > > type or grouping cannot be defined if a higher level in the schema > > > > hierarchy has a definition with a matching identifier. > > > > > > > > I think the second sentence is confusing, because (to me) the term > > > > "schema hierarchy" implies the data tree structure, whereas the > > > > scoping rule seems to be intended to be entirely lexical. In either > > > > case, this needs to be clarified. > > > > > > The first sentence says: > > > > > > Typedefs and groupings may appear nested under many YANG statements, > > > allowing these to be lexically scoped by the hierarchy under which > > > they appear. > > > > > > Maybe it would help to move paragraph 2 and 3 to the end, so that the > > > motivational text is at the end of the section? > > > > It looks like current paragraphs 1, 4, and 5 are prescriptive, and 2 and > > 3 are motivational. Putting 1, 4, and 5 together should make them > > clearer. But since paragraph 2 starts with "Scoping...", it really > > needs to be after 1. So, yes, moving 2 and 3 to the end seems like the > > clearest order. Does it make sense to you to put all of the motivation > > at the end of this section? > > I prefer to have motivational text before the rules ("why" before > "how"). Hmm. The preferred order is "what", "why", "how", and that > is really the order we currently have (1 is "what", 2 + 3 is "why" and > 4 +5 is "how"). > > But obviously this was confusing to you, so we probably need to make > some clarification. > > Since the problem was with the term "schema hierarchy", maybe we could > change this to "statement hierarchy" instead, to stress the fact that > it is lexical scoping? > > [sorry for missing your original point] Yes, I think that will do it. There are two instances of "hierarchy" in para. 1, and at least the first one would be clearer if it was "statement hierarchy". And in para. 4, it seems like "schema hierarchy" is actually incorrect, and should be "statement hierarchy". > > > > - section 5.6.5 > > > > > > > > I suspect that if a server implements module A, and A imports B, the > > > > server is not required to implement B. (Even if A references > > > > groupings in B.) The answer to that should probably be stated > > > > explicitly. > > > > > > It is not so simple. The rest of the text defines the rules for when > > > the server is required to implement B. > > > > Yes, I was wrong there. (I can't see why I made that mistake.) > > > > > > Is this the correct way to specify multiple revisions of this module? > > > > Or is this an informal notation for the two module definitions: > > > > > > > > module b { > > > > yang-version 1.1; > > > > namespace "urn:example:b"; > > > > prefix "b"; > > > > > > > > revision 2015-04-04; > > > > revision 2015-01-01; > > > > > > > > typedef myenum { > > > > type enumeration { > > > > enum zero; // added in 2015-01-01 > > > > enum one; // added in 2015-04-04 > > > > } > > > > } > > > > > > > > container x { // added in 2015-01-01 > > > > container y; // added in 2015-04-04 > > > > } > > > > } > > > > > > > > module b { > > > > yang-version 1.1; > > > > namespace "urn:example:b"; > > > > prefix "b"; > > > > > > > > revision 2015-01-01; > > > > > > > > typedef myenum { > > > > type enumeration { > > > > enum zero; // added in 2015-01-01 > > > > } > > > > } > > > > > > > > container x { // added in 2015-01-01 > > > > } > > > > } > > > > > > > > If it is the latter, it would help the new reader to explain the > > > > convention (as no example of a multi-revision module is given in the > > > > document). > > > > > > The comments are not required. There is no correct (mandated) way to > > > specify which changes are done in a new revision. > > > > What I was concerned with is what does the above module statement do? > > If I understand correctly, it defines the 2015-04-04 revision of b, and > > also tells us that a 2015-01-01 revision exists, but does not define > > that revision. Implicitly, there must be a .yang file somewhere > > containing the module statement that defines the 2015-01-01 revision of > > b. > > > > But despite that the text talks about the 2015-01-01 revision ('can > > implement revision "2015-01-01" or "2015-04-04" of module "b"'), that > > file is not included in the example, which is not what I expected, which > > led me to wonder if the 2015-01-01 revision was somehow also defined by > > the presented "module b" statement. I would have had less trouble with > > the example if the definition of the earlier revision of b was also > > given. > > Ok, I see what you mean. This makes sense. I'll add > > module b { > yang-version 1.1; > namespace "urn:example:b"; > prefix "b"; > > revision 2015-01-01; > > typedef myenum { > type enumeration { > enum zero; > } > } > > container x { > } > } > > and > > module c { > yang-version 1.1; > namespace "urn:example:c"; > prefix "c"; > > revision 2015-02-02; > > typedef bar { > ... > } > } > > > to the example. Yes, I think that will make it all clear. > > > > It is worth noting (either here or in 6.1.3) how line-breaks inside > > > > quoted strings are transcribed into the string's value. As now > > > > written, it seems that the line-break is transcribed identically to > > > > how it is represented in the source. That means (1) If the source is > > > > recoded with the other type of line break, the semantics of the Yang > > > > code change; and (2) if the source uses line-breaks of one type (CRLF > > > > or LF), only that type can be directly transcribed into string values. > > > > (But regardless of the source line-breaks, an LF can be transcribed > > > > into a double-quoted string with "\n". But a CRLF cannot be > > > > transcribed into a double-quoted string with escape sequences. Was > > > > that intended, or was "\r" intended to be legal?) > > > > Don't forget this. I was wondering that (as the text is written) the value of a quoted string that includes a line end will change if the line ends are changed (say, by moving the Yang file to a different host). Normally computer languages are defined so that changing how the program is "represented", e.g., by transforming it into a form with different line-ends, won't change the semantics of the program. But if it's true, I seems desirable to provide an explicit warning about it. > Adding "\r" would be backwards incompatible with YANG 1. I don't see why that is. As far as I can tell from RFC 6020, "\r" is not a defined escape in Yang 1, so existing Yang 1 code can't use it. True, the new draft explicitly states "It is an error if any other character follows the backslash character.", but RFC 6020 doesn't seem to allow "\r" to mean anything. Or is it that in practice, Yang 1 allows people to write "\r", which is interpreted as backslash-r? > You can always get the same effect by using single quoted strings. I don't see how you can get a single CR using single-quoted strings, because line ends are only allowed to be LF and CR-LF; writing a CR without an LF following it isn't allowed. Or is it that in practice, Yang 1 allows people to use CR alone, and it is not interpreted as a line-end? Dale From nobody Mon Jun 6 15:28:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F77E12D95E for ; Mon, 6 Jun 2016 15:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 zrJy_lBvLyKT for ; Mon, 6 Jun 2016 15:28:22 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 ADE8012D929 for ; Mon, 6 Jun 2016 15:28:22 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by comcast with SMTP id A2zabr6Psp1BeA30PbyE7p; Mon, 06 Jun 2016 22:28:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465252101; bh=g05h+OkTGahObfpk7wARnt5YyNOWpOcgHxf6zfGwDes=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Jlk2OsYtIgI5bqA1CrwuH1Ul9uJxnyN2PvBmIcAPc5KcGrp8qPsrBQmPI03NTl8U8 HjlEdpjK6NPRRN5kdHkWFX0u1ug2pzvGuJ6WBj7WUC0E4PhHtwGhR2kgokCW3FGLGT 9QAYnjEXo+sR1yIJwMgXG1EoPS2UUodAYtkzyFOTI456yVEqFnpi6NXQb0qMrRgBRp Po1SahTXjQI90nUkF20gGDiBUZXkqDicBrXnJPK/XoZqwsu3UdmGovFcAzAcn4VYfP obSyGF5EcEvy1tpo2eynPK2GBy+59uY6BTbEI84FC84BRQs7SLN7CIE+WnnYm4DaOi BQMfvCvzVq0Ug== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-14v.sys.comcast.net with comcast id 3aUM1t0071nMCLR01aUMqw; Mon, 06 Jun 2016 22:28:21 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u56MSKen007923 for ; Mon, 6 Jun 2016 18:28:20 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u56MSK4N007920; Mon, 6 Jun 2016 18:28:20 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org In-Reply-To: <20160523.154309.848500367505009627.mbj@tail-f.com> References: <877feyrdz9.fsf@hobgoblin.ariadne.com> <20160523.154309.848500367505009627.mbj@tail-f.com> <20160523.154309.848500367505009627.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 06 Jun 2016 18:28:20 -0400 Message-ID: <87shwq9cl7.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 22:28:24 -0000 (This is the second part of my response.) > > > > - section 6.1 > > > > > > > > This section details the rules for recognizing tokens from an input > > > > stream. > > > > > > > > Generally, language definitions intersperse the narrative text with > > > > the relevant grammar definitions. Yang's statement grammar is simple > > > > enough that one doesn't need to see the context-free part of the > > > > grammar to understand the narrative for statements. But when reading > > > > about tokenization, not having the grammar presented at the same time > > > > is quite a burden. I'd recommend duplicating the relevant productions > > > > from section 14 into the subsections of section 6. > > > > > > > > There is some sort of exposition problem. The result of > > > > "tokenization" is that the sequence of characters of the source is > > > > converted into a sequence of "tokens". Then some subset of the tokens > > > > is discarded as being non-significant (e.g., whitespace and comments), > > > > and the remainder is parsed with a context-free grammar. Here I can't > > > > figure out what the set of tokens is. Looking at the grammar in > > > > section 14, it seems to be a context-free grammar on characters. But > > > > that implies that there is no separate tokenization phase. > > > > > > > > An example that shows the problems: > > > > > > > > mod:ext > > > > > > > > Is this one token, which is also an extension keyword, or is it a > > > > sequence of three tokens? > > > > > > The text says: > > > > > > A token in YANG is either a keyword, a string, a semicolon (";"), or > > > braces ("{" or "}"). > > > > > > and: > > > > > > A keyword is [...] or a prefix identifier, followed by a colon > > > (":"), followed by a language extension keyword. > > > > > > So "mod:ext" is one token. > > > > Certainly it can be one token. My question is how do verify that it is > > not a string? I think that may be the origin of my confusion here is > > that I haven't spotted a clear syntax for unquoted string. In most > > programming languages, mod:ext would be parsed as an identifier, a > > colon, and an identifier. In YANG, identifiers are usually tokenized as > > strings, so I ask whether YANG tokenizes it as a string, a colon, and a > > string. > > > > Looking at the beginning of 6.1.3, it doesn't appear that an unquoted > > string is forbidden from containing a colon. > > > > I think that the underlying problem is that I'm not clear on what gets > > tokenized as an unquoted string. > > Note that this is legal YANG: > > leaf type { > type string; > } So keywords aren't reserved; they can also be used as identifiers. > I think there are two ways to look at this. Either we describe the > tokenizer as being context-dependent, or we describe the "argument" in > a "statement" to be a "string or keyword". > > In the latter case maybe we can do: > > OLD: > > If a string contains any space, tab, or newline characters, a single > or double quote character, a semicolon (";"), braces ("{" or "}"), > or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed > within double or single quotes. > > NEW: > > An unquoted string is any sequence of characters that does not start > with a double or single quote character, is not a keyword, and does > not contain any space, tab, or newline characters, a single or > double quote character, a semicolon (";"), braces ("{" or "}"), or > comment sequences ("//", "/*", or "*/"). That's a lot clearer. Though you can shorten it to: An unquoted string is any sequence of characters that is not a keyword, and does not contain any space, tab, or newline characters, a single or double quote character, a semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"). > In section 6.3 we must also do: > > OLD: > > The argument is a string, as defined in Section 6.1.2. > > NEW: > > The argument is a string or a keyword, as defined in Section 6.1.2. If I understand correctly, the tokens of Yang (as the term is usually used in programming languages) are: whitespace (which is ignored) comments (which is ignored) single-quoted strings double-quoted strings unquoted strings (including keywords) ; { } >From the point of view of the tokenizer, these tokens fall into the obvious classes: type unquoted string "type" double-quoted string abc unquoted-string "abc" double-quoted string '---' single-quoted string I'm not quite sure how they are classified from the parser's point of view, though. type "type" abc "abc" '---' Is a string? ? Y ? Y Y (Can it appear as the argument of "description"?) Is a keyword? Y ? N N N (Can it appear as the first token of some statement?) Is an identifier? Y ? Y ? N (Can it appear as the second token of a type statement?) Usually programming languages use the particular syntax of different types of tokens to determine where they can be used in the context-free grammar. Yang seems to be more relaxed, but I'm not sure whether it is so relaxed thay any of the types of string tokens can be used anywhere. > > > > -- it must be an unquoted string. > > > > > > > > If a double-quoted string contains a line break followed by space or > > > > tab characters that are used to indent the text according to the > > > > layout in the YANG file, this leading whitespace is stripped from the > > > > string, up to and including the column of the double quote character, > > > > or to the first non-whitespace character, whichever occurs first. In > > > > this process, a tab character is treated as 8 space characters. > > > > > > > > This description isn't quite careful enough. Better: > > > > > > > > If a double-quoted string contains a line break followed by space or > > > > tab characters, an initial part of this whitespace is removed from the > > > > string. The amount removed is the longest prefix whose width is no > > > > larger than the width of the prefix of Yang source line containing > > > > the opening double quote character of the string to and including the > > > > opening double quote character. For this purpose, the width of a > > > > tab character is 8 and the width of any other character is 1. > > > > > > > > This does assume that all tabs are considered to have width 8, that > > > > is, tabs do not have the usual semantics of "advance to the next > > > > column that is divisible by 8". That will sometimes cause unexpected > > > > results, e.g., if some source lines start with SPC TAB. (Consider > > > > that whitespace before a line break is removed, which suggests the > > > > intention is that the value of the string should depend only on its > > > > visual appearance.) > > > > > > > > Also, we're using the convention that "whitespace" does NOT include CR > > > > or LF, which is not always how the term is used. Perhaps a definition > > > > of "whitespace" should be put in section 3. > > > > > > > > There is also the special case: > > > > > > > > SPC " LF > > > > TAB x " > > > > > > > > Is the initial TAB of the second line to be removed or not? There is > > > > no whitespace removal in the second line that will exactly reach the > > > > opening double quote. As I've written it, the TAB is not removed. > > > > Don't forget this ugly special case. > > So, let's follow the rules. We need to trim to the column of the > double quote character (2). The second line starts with "space or > tab" so we do whitespace trimming, while treating the tab as 8 > spaces. So from 8 spaces we subtract 2, and get the resulting string > of 6 characters: > > LF SPC SPC SPC SPC SPC SPC x OK, but that process wasn't clear to me. I take it that any tab that appears before the starting double-quote counts as 8 spaces, and any tab that needs to be examined for deletion is turned into 8 spaces -- but any other tabs in the string are unconverted. I think it would be clearer to insert "starting" where I've indicated it, and replace the final sentence: If a double-quoted string contains a line break followed by space or tab characters that are used to indent the text according to the layout in the YANG file, this leading whitespace is stripped from the string, up to and including the column of the >starting< double quote character, or to the first non-whitespace character, whichever occurs first. In this process, any tab character before the starting double quote character is treated as 8 spaces. Any tab character in a succeeding line that must be examined to for stripping is first converted into 8 spaces. > > Actually, there is a somewhat subtle problem: If I say "the system can > > sort them any way it wants", I am asserting that *there is a sorting > > order*. Which means that if value A is put before value B at one time, > > then if values A and B are in the list at some other time, A will > > precede B. > > The next sentences says: > > An implementation SHOULD use the same order for the same data, > regardless of how the data were created. Using a deterministic > order will make comparisons possible using simple tools like "diff". OK, I'm willing to go with that. I mis-read the application of those sentences through an even more arcane ambiguity in the term "the same data". But I'm willing to ignore that. > > > > - section 7.21.4 > > > > > > > > The "reference" statement takes as an argument a string ... > > > > > > > > Perhaps s/a string/a human-readable string/. > > > > > > "string" refers to the YANG token "string". The same wording is used > > > across the document for all arguments. > > > > I was thinking that it is a string, but in this particular case, it is > > supposed to be human-readable, whereas strings in other contexts aren't > > expected to be. > > Ok. Maybe: > > OLD: > > The "reference" statement takes as an argument a string that is used > to specify a textual cross-reference to an external document, > > NEW: > > The "reference" statement takes as an argument a string that is used > to specify a human-readable cross-reference to an external document, Or even "is a human-readable cross-reference ...", but either is OK with me. > > > > - section 7.21.5 > > > > > > > > Note that if a data definition has both an "if-feature" and a "when", > > > > then the "if-feature" is tested first. > > > > > > > > If the XPath expression references any node that also has associated > > > > "when" statements, these "when" expressions MUST be evaluated first. > > > > There MUST NOT be any circular dependencies in these "when" > > > > expressions. > > > > > > > > I think this could be better phrased: > > > > > > > > If the XPath expression references any node that also has > > > > associated "when" statements, then the "when" expressions of the > > > > referenced nodes MUST be evaluated first. There MUST NOT be any > > > > circular dependencies among "when" expressions. > > > > > > Ok to the last sentence. Do you think that the word "these" in the > > > first sentence is ambigious? > > > > I must have thought it was unclear when I read it, otherwise I would not > > have suggested changing it. But reading it again, I think that there is > > no ambiguity. Perhaps it would be a little clearer to use 'those "when" > > expressions' rather than 'these "when" expressions'. (I can't explain > > clearly why "those" seems less ambiguous than "these".) > > Ok, as a non-native english speaker I trust you that "those" is better. I can't tell that you're non-native. Perhaps leave it as is and let the RFC Editor review it. > > By implication, the leafref's value is considered to be a pointer to a > > particular leaf instance, the one with the matching value. But that > > idea is not embedded in the Yang semantics of leafref types in any way > > (other than the output of the deref function), so the fact that there > > might be more than one matching leaf instance does not matter. > > > > As stated in 9.9.4 and 9.9.5, the lexical representations of its values > > are the same as those of the referenced nodes. > > > > How is the leafref's value compared to the values of the referenced > > nodes? I can see that question getting ugly for the more complex types > > (e.g., anyxml) > > You can't have a leafref to an anyxml node; just to a leaf or > leaf-list. > > > which do not have canonical forms. I suspect the > > intention is that values are equal if they have the same canonical form > > No, the idea is that they are equal if their *value* is equal, > regardless of the lexical representation. There are two types that don't have a canonical form, identityref and instance-identifier. It seems that comparisons in XPath expressions are inexact if the type doesn't have a canonical form (section 6.4). But if I understand you correctly, the implicit comparisons in leafref are done based on the abstract values involved, not the lexical representation. > > The current ABNF doesn't allow for "+" for joining quoted strings. > > Also, it doesn't show that \" can be included in a double quoted string > > to include a literal ", and allows the string contents to continue -- > > the current ABNF "DQUOTE string DQUOTE" matches "abcd\", despite that > > the latter is not a proper double-quoted string. > > Note that the prose text (within <...>) says "a string that > matches...". That string can be any YANG token string, for example > one of: > > "hello" > "he" + "llo" If I haven't gotten confused, you're referring to string = < an unquoted string as returned by > < the scanner, that matches the rule > < yang-string > yang-string = *yang-char ;; any Unicode or ISO/IEC 10646 character including tab, carriage ;; return, and line feed, but excluding the other C0 control ;; characters, the surrogate blocks, and the noncharacters. yang-char = %x09 / %x0A / %x0D / %x20-D7FF / ; exclude surrogate blocks %xD800-DFFF %xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF %xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF %x10000-1FFFD / ; exclude noncharacters %x1FFFE-1FFFF %x20000-2FFFD / ; exclude noncharacters %x2FFFE-2FFFF %x30000-3FFFD / ; exclude noncharacters %x3FFFE-3FFFF %x40000-4FFFD / ; exclude noncharacters %x4FFFE-4FFFF %x50000-5FFFD / ; exclude noncharacters %x5FFFE-5FFFF %x60000-6FFFD / ; exclude noncharacters %x6FFFE-6FFFF %x70000-7FFFD / ; exclude noncharacters %x7FFFE-7FFFF %x80000-8FFFD / ; exclude noncharacters %x8FFFE-8FFFF %x90000-9FFFD / ; exclude noncharacters %x9FFFE-9FFFF %xA0000-AFFFD / ; exclude noncharacters %xAFFFE-AFFFF %xB0000-BFFFD / ; exclude noncharacters %xBFFFE-BFFFF %xC0000-CFFFD / ; exclude noncharacters %xCFFFE-CFFFF %xD0000-DFFFD / ; exclude noncharacters %xDFFFE-DFFFF %xE0000-EFFFD / ; exclude noncharacters %xEFFFE-EFFFF %xF0000-FFFFD / ; exclude noncharacters %xFFFFE-FFFFF %x100000-10FFFD ; exclude noncharacters %x10FFFE-10FFFF But if that's taken at face value, you can lex as single "string"s not only "hello" and "he" + "llo" but also "The MTU of the interface."; myext:c-define "MY_MTU" Doing that would allow the incorrect lexing of leaf mtu { type uint32; description "The MTU of the interface."; myext:c-define "MY_MTU"; } as having a long description (starting with 'The MTU' and ending with 'MY_MTU') and no myext:c-define statement. What we need is a production that matches "strings possibly combined with +" and nothing else. That is, including '"he" + "llo"' but not the last example. Dale From nobody Tue Jun 7 01:36:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1962D12B017; Tue, 7 Jun 2016 01:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 nzkl4x6RCru1; Tue, 7 Jun 2016 01:36:32 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4014812D0E8; Tue, 7 Jun 2016 01:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12191; q=dns/txt; s=iport; t=1465288587; x=1466498187; h=references:subject:to:from:message-id:date:mime-version: in-reply-to; bh=AwZitKZJMUBwffn1QtowSvjJP7oNCvDXU+IU0llvFCU=; b=ZieqllbURsB9TKRrrIXv5yosOC/1YkaN9O7LUGC1X3Ihk0c0Aen4dB4i 6XnXMGG5t2lvDu4CqeWaKfyC/+XAXeQfTnDWF0VgEBPQ2lr7HjrWQLbjd TblYZu2L8geIGONGNP0SpH1bq3nxa0i3SDDV3v6uY89DOuehNGcZFuHFi s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgDShlZX/4MNJK1cgzxWK1K1aYR+g?= =?us-ascii?q?XkihXECgTo4FAEBAQEBAQFlJ4RGAgQjVBIPPgICTQoGAQwIAQGIKw6qEpEwAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARAOiB6CVodBglkFiAqFXIplgy6BaW2II4FqToQEg?= =?us-ascii?q?wmFW49eHjaDcDoyAYoOAQEB?= X-IronPort-AV: E=Sophos;i="5.26,432,1459814400"; d="asc'?eml'208?scan'208,208,217";a="110585874" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Jun 2016 08:36:26 +0000 Received: from [10.86.254.13] ([10.86.254.13]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u578aOrJ002949; Tue, 7 Jun 2016 08:36:25 GMT References: <20160607082500.13784.77653.idtracker@ietfa.amsl.com> To: netmod WG , "opsawg@ietf.org" From: Eliot Lear X-Forwarded-Message-Id: <20160607082500.13784.77653.idtracker@ietfa.amsl.com> Message-ID: <8ef1edcc-0d56-ea5f-90a9-4a64a025ba41@cisco.com> Date: Tue, 7 Jun 2016 10:36:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160607082500.13784.77653.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eHgbguJeXkfRa9DRPLKHtEN1rFWHJIe5x" Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 08:36:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eHgbguJeXkfRa9DRPLKHtEN1rFWHJIe5x Content-Type: multipart/mixed; boundary="W1smT3pqkxnG1m9osc4g1GF7o1k92aeBw" From: Eliot Lear To: netmod WG , "opsawg@ietf.org" Message-ID: <8ef1edcc-0d56-ea5f-90a9-4a64a025ba41@cisco.com> Subject: Fwd: New Version Notification for draft-lear-ietf-netmod-mud-02.txt References: <20160607082500.13784.77653.idtracker@ietfa.amsl.com> In-Reply-To: <20160607082500.13784.77653.idtracker@ietfa.amsl.com> --W1smT3pqkxnG1m9osc4g1GF7o1k92aeBw Content-Type: multipart/mixed; boundary="------------5EBFE7404AE1744AC27EB01F" This is a multi-part message in MIME format. --------------5EBFE7404AE1744AC27EB01F Content-Type: multipart/alternative; boundary="------------94993475368E4B75B21C81BF" --------------94993475368E4B75B21C81BF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, There is a new version of draft-ietf-lear-netmod-mud out there. In discussions with various WG chairs it seems like the best approach is to (a) consolidate the drafts a bit and (b) proceed in opsawg with this work. That is what this draft does. Both the PKIX constraint and the DHCP options are rolled in here. In addition, several other changes have been made, a full list of which can be found in the appendix. Here are few of the bigger ones (apart from the merge): * This version changes the serialization from XML to JSON. Tooling is definitely going in the direction of JSON. The initial reason for XML is that it is commonly used by routers. We're pretty sure that on the whole, this stuff won't be directly consumed by routers, and those who do consume it can learn JSON ;-). Thanks to Cullen Jennings for nudging in this direction. * We now include a signature mechanism for the MUD files. It was always the plan to do this. There were two choices: CMS/PKCS#7 or JWS. Again for tooling's sake, so that people don't need to roll their own, especially for anything security related, we've gone with CMS and a detached signature at that. Thanks to John Bashinsky and others for their advice on this. This area in particular could stand close scrutiny. * Per a suggestion from Mark Nottingham, we are now registering a MIME application type. That registration is included in the IANA considerations. * The constraint X.509 specification specification has changed somewhat based on advice from Tom Gindin. * We've included a small number of additional elements in the model, mostly around flow/packet directionality. Comments and edits are very welcome! Eliot --------------94993475368E4B75B21C81BF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi everyone,

There is a new version of draft-ietf-lear-netmod-mud out there.=C2= =A0 In discussions with various WG chairs it seems like the best approach is to (a) consolidate the drafts a bit and (b) proceed in opsawg with this work.=C2=A0 That is what this draft does.=C2=A0 Bo= th the PKIX constraint and the DHCP options are rolled in here.=C2=A0 In addition, several other changes have been made, a full list of which can be found in the appendix.=C2=A0 Here are few of the bigge= r ones (apart from the merge):

  • This version changes the serialization from XML to JSON.=C2=A0 Tooling is definitely going in the direction of JSON.=C2=A0 The initial reason for XML is that it is commonly used by routers.=C2= =A0 We're pretty sure that on the whole, this stuff won't be directly consumed by routers, and those who do consume it can learn JSON ;-).=C2=A0 Thanks to Cullen Jennings for nudging in th= is direction.
  • We now include a signature mechanism for the MUD files.=C2=A0 I= t was always the plan to do this.=C2=A0 There were two choices: CMS/PKCS#7 or JWS.=C2=A0 Again for tooling's sake, so that people= don't need to roll their own, especially for anything security related, we've gone with CMS and a detached signature at that.=C2= =A0 Thanks to John Bashinsky and others for their advice on this.=C2=A0= This area in particular could stand close scrutiny.
  • Per a suggestion from Mark Nottingham, we are now registering a MIME application type.=C2=A0 That registration is included in t= he IANA considerations.
  • The constraint X.509 specification specification has changed somewhat based on advice from Tom Gindin.
  • We've included a small number of additional elements in the model, mostly around flow/packet directionality.

Comments and edits are very welcome!

Eliot

--------------94993475368E4B75B21C81BF-- --------------5EBFE7404AE1744AC27EB01F Content-Type: message/rfc822; name="New Version Notification for draft-lear-ietf-netmod-mud-02_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="New Version Notification for draft-lear-ietf-netmod-mud-02_t"; filename*1="xt.eml" X-Mozilla-Keys: Received: from xch-rtp-001.cisco.com (64.101.220.141) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Mailbox Transport; Tue, 7 Jun 2016 03:25:02 -0500 Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 7 Jun 2016 04:25:01 -0400 Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 7 Jun 2016 04:25:01 -0400 Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2016 08:25:01 +0000 Received: from alln-inbound-h.cisco.com (alln-inbound-h.cisco.com [173.37.147.238]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u578Ogik024823 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK); Tue, 7 Jun 2016 08:25:01 GMT Authentication-Results: alln-inbound-h.cisco.com; dkim=none (message not signed) header.i=none; spf=Pass smtp.mailfrom=internet-drafts@ietf.org; spf=Pass smtp.helo=postmaster@mail.ietf.org Received-SPF: Pass (alln-inbound-h.cisco.com: domain of internet-drafts@ietf.org designates 4.31.198.44 as permitted sender) identity=mailfrom; client-ip=4.31.198.44; receiver=alln-inbound-h.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="internet-drafts@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: Pass (alln-inbound-h.cisco.com: domain of postmaster@mail.ietf.org designates 4.31.198.44 as permitted sender) identity=helo; client-ip=4.31.198.44; receiver=alln-inbound-h.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" X-from-outside-Cisco: 4.31.198.44 IronPort-PHdr: =?us-ascii?q?9a23=3A4MVDDBVUMYsDIE6IEPt0U3l1vAHV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZh2Et8tkgFKBZ4jH8fUM07OQ6PCxHzNZqs7b+Fk5M7VyFDY9wf?= =?us-ascii?q?0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5?= =?us-ascii?q?K6zPF5LIiIzvjqbpq8yVPFwD3GD1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd?= =?us-ascii?q?5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGC?= =?us-ascii?q?HkOz4S5Wf2EXlQYAJwXM9luyCpP8uzHSvetm0y7cNsrzG/R8Ew6r679rADPyjy?= =?us-ascii?q?IcfXZt6m3NjclrpKlauxmm4Rd4xtiHTpuSMa9/eL/QZ9UXWS9NRM9fSzdpA46g?= =?us-ascii?q?Yc0IFeVSbq5js4Dhqg5W/lOFDg62Cbaqk2cQiw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0G0AwCAg1ZXdyzGHwRcHAEBgnGBA32NJ?= =?us-ascii?q?q1BgW4LFwuFcYE8OBQBAQEBAQEBAQIPAQwJCwkfMYIwCiIXEAEBAQEBASYBAQE?= =?us-ascii?q?BAQEjAj41AiBUESYCJgICA0QWAReIKwICCaoRhimLAwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARyBAYlzhF2CZIJZBYgKhVx0iXGGBIgZCoFqToQEiGSPXh6ERE4Big4?= =?us-ascii?q?BAQE?= X-IPAS-Result: =?us-ascii?q?A0G0AwCAg1ZXdyzGHwRcHAEBgnGBA32NJq1BgW4LFwuFcYE?= =?us-ascii?q?8OBQBAQEBAQEBAQIPAQwJCwkfMYIwCiIXEAEBAQEBASYBAQEBAQEjAj41AiBUE?= =?us-ascii?q?SYCJgICA0QWAReIKwICCaoRhimLAwEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYl?= =?us-ascii?q?zhF2CZIJZBYgKhVx0iXGGBIgZCoFqToQEiGSPXh6ERE4Big4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,432,1459814400"; d="scan'208";a="213323707" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([4.31.198.44]) by alln-inbound-h.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2016 08:25:00 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 748BA12D192; Tue, 7 Jun 2016 01:25:00 -0700 (PDT) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: To: Eliot Lear , Ralph Droms Subject: New Version Notification for draft-lear-ietf-netmod-mud-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160607082500.13784.77653.idtracker@ietfa.amsl.com> Date: Tue, 7 Jun 2016 01:25:00 -0700 Return-Path: internet-drafts@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-RTP-012.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: 996a90be-6981-4166-dd3b-08d38ead3884 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 A new version of I-D, draft-lear-ietf-netmod-mud-02.txt has been successfully submitted by Eliot Lear and posted to the IETF repository. Name: draft-lear-ietf-netmod-mud Revision: 02 Title: Manufacturer Usage Description Specification Document date: 2016-06-07 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-lear-ietf-netmod-mud-02.txt Status: https://datatracker.ietf.org/doc/draft-lear-ietf-netmod-mud/ Htmlized: https://tools.ietf.org/html/draft-lear-ietf-netmod-mud-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-lear-ietf-netmod-mud-02 Abstract: This memo specifies the necessary components to implement manufacturer usage descriptions (MUD). This includes a YANG model, IPv4 and IPv6 DHCP options, a URL suffix specification, an X.509 certificate extension and a means to sign and verify the descriptions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------5EBFE7404AE1744AC27EB01F-- --W1smT3pqkxnG1m9osc4g1GF7o1k92aeBw-- --eHgbguJeXkfRa9DRPLKHtEN1rFWHJIe5x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXVoeIAAoJEIe2a0bZ0nozT6AH/2Kq/4WBouVxjsbxGa/roxNV vw42e8vwQ1W1X6ZgNs9Sq/JL2m91InvuffulS/aMhCIiEqNmyL/lD/vCJOQSlvzf p9B6ITdFaVk69WRKhqbwQJGLO6HjSezP6jVbr0Zf1LhKeoOtHtpyAxwTlQHydcnm hSRuyeCv+q1MKIPem003DhFcV6udxsR4htefIianl0/qsOaO8c7sII/BphqEbnUU FFG2e9X2G45r919noqubY0aIPmytZzL4rwak+lMAmaMSL8aXhDB+7X7eLrmTLKdv jsSNHUd/GSJfROXgT/b2bzdoeUynRgE5XQGirwmFnyrUGnWf+CxXUXq9UW2xxDQ= =y6Lf -----END PGP SIGNATURE----- --eHgbguJeXkfRa9DRPLKHtEN1rFWHJIe5x-- From nobody Tue Jun 7 02:25:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD2212B02E for ; Tue, 7 Jun 2016 02:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blP12PsFXM9Y for ; Tue, 7 Jun 2016 02:25:30 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6443012D1C8 for ; Tue, 7 Jun 2016 02:25:29 -0700 (PDT) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 24E4B1CC00FD; Tue, 7 Jun 2016 11:25:28 +0200 (CEST) From: Ladislav Lhotka To: "Dale R. Worley" , netmod@ietf.org In-Reply-To: <87mvmyb39a.fsf@hobgoblin.ariadne.com> References: <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz> <87twhbfiv3.fsf@hobgoblin.ariadne.com> <20160606170848.GA7405@elstar.local> <87mvmyb39a.fsf@hobgoblin.ariadne.com> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 07 Jun 2016 11:25:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 09:25:32 -0000 "Dale R. Worley" writes: > A difficulty I have with the current wording is that it doesn't point > out the crucial fact about leafref that the XPath expression can only > select elements that are instantiations of one particular data node. I > don't know XPath, but it seems that that is not a general property of > XPath expressions, you seem to be able to write XPath expressions that > select heterogenous groups of elements. So it's worth pointing out that > the allowed XPath expressions can't do that, and that is because of the > restriction that the expression must match path-arg. Right, this is the slightly hand-waving part that I also objected to. An XPath expression in a leafref's "path" statement indeed selects a node set from an instance data tree. The node seet can be empty, but if it is non-empty, all its members necessarily have the same type, which is defined in a certain "leaf" schema node. The relationship is relatively straightforward but difficult to explain concisely. One basically has to follow the steps in the XPath expression, ignore all path-predicates, and skip all schema nodes that aren't data nodes (i.e., "choice" and "case" nodes). > > Perhaps my problem is that XPath is almost always used in this style, > and so the limitations in leafref aren't anything unusual. Actually, no, XPath expressions always have to be evaluated in the context of a specific instance XML document, they cannot directly address schema nodes. XPath 1.0 spec says: "XPath is a language for addressing parts of an XML document, ...". Lada > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 7 05:39:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C81212D1AE for ; Tue, 7 Jun 2016 05:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 a6Ku5zu-adND for ; Tue, 7 Jun 2016 05:39:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7B412D16F for ; Tue, 7 Jun 2016 05:39:14 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id A48D91AE0404; Tue, 7 Jun 2016 14:39:11 +0200 (CEST) Date: Tue, 07 Jun 2016 14:39:33 +0200 (CEST) Message-Id: <20160607.143933.1561598315043950802.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160606170848.GA7405@elstar.local> References: <419C08EB-7591-4D0F-A19B-C258FC6A155B@nic.cz> <87twhbfiv3.fsf@hobgoblin.ariadne.com> <20160606170848.GA7405@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 12:39:17 -0000 Juergen Schoenwaelder wrote: > Martin, how close are we to have a final version addressing all the > review comments we received during the journey through the IESG? We're shrinking the list of open issues with every iteration of emails. I will go through the latest comments from the Gen-ART and ops-dir reviews and reply to the list. Maybe we can be done by the end of this week. /martin From nobody Tue Jun 7 05:45:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBECB128E19 for ; Tue, 7 Jun 2016 05:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 KmttugBRtHK3 for ; Tue, 7 Jun 2016 05:45:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6884C12D512 for ; Tue, 7 Jun 2016 05:45:22 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 802721AE0404; Tue, 7 Jun 2016 14:45:21 +0200 (CEST) Date: Tue, 07 Jun 2016 14:45:43 +0200 (CEST) Message-Id: <20160607.144543.1696408907886273193.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20160606130953.GA6900@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] keys in instance-identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 12:45:25 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDYgSnVu IDIwMTYsIGF0IDE1OjA5LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPiA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPiANCj4gPiBPbiBNb24sIEp1biAw NiwgMjAxNiBhdCAxMDoxMzo0N0FNICswMjAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4+ IEhpLA0KPiA+PiANCj4gPj4gc2VjdGlvbiA5LjEzIGluIHJmYzYwMjAtYmlzIHNheXM6DQo+ID4+ IA0KPiA+PiAgIFRoZSBzeW50YXggZm9yIGFuIGluc3RhbmNlLWlkZW50aWZpZXIgaXMgYSBzdWJz ZXQgb2YgdGhlIFhQYXRoDQo+ID4+ICAgYWJicmV2aWF0ZWQgc3ludGF4LCBmb3JtYWxseSBkZWZp bmVkIGJ5IHRoZSBydWxlDQo+ID4+ICAgImluc3RhbmNlLWlkZW50aWZpZXIiIGluIFNlY3Rpb24g MTQuDQo+ID4+IA0KPiA+PiBIb3dldmVyLCB0aGUgQUJORiBvbmx5IGFsbG93cyBzdHJpbmcgbGl0 ZXJhbHMgaW4ga2V5IHByZWRpY2F0ZXM6DQo+ID4+IA0KPiA+PiAgIGtleS1wcmVkaWNhdGUgICAg ICAgPSAiWyIgKldTUCBrZXktcHJlZGljYXRlLWV4cHIgKldTUCAiXSINCj4gPj4gDQo+ID4+ICAg a2V5LXByZWRpY2F0ZS1leHByICA9IG5vZGUtaWRlbnRpZmllciAqV1NQICI9IiAqV1NQIHF1b3Rl ZC1zdHJpbmcNCj4gPj4gDQo+ID4+IEkgdGhpbmsgdGhpcyBsZWFkcyB0byBwcm9ibGVtcyB3aXRo IGtleXMgdGhhdCBoYXZlIGEgbnVtZXJpYw0KPiA+PiB0eXBlLiBDb25zaWRlciB0aGlzIG1vZHVs ZToNCj4gPj4gDQo+ID4+IG1vZHVsZSBpaS1rZXkgew0KPiA+PiAgeWFuZy12ZXJzaW9uIDEuMTsN Cj4gPj4gIG5hbWVzcGFjZSAiaHR0cDovL2V4YW1wbGUuY29tL2lpLWtleSI7DQo+ID4+ICBwcmVm aXggaWs7DQo+ID4+IA0KPiA+PiAgbGlzdCBhcnIgew0KPiA+PiAgICBrZXkgImsxIjsNCj4gPj4g ICAgbGVhZiBrMSB7DQo+ID4+ICAgICAgdHlwZSB1aW50ODsNCj4gPj4gICAgfQ0KPiA+PiAgICBs ZWFmIGsyIHsNCj4gPj4gICAgICB0eXBlIHN0cmluZzsNCj4gPj4gICAgfQ0KPiA+PiAgfQ0KPiA+ PiAgbGVhZiBpaSB7DQo+ID4+ICAgIHR5cGUgaW5zdGFuY2UtaWRlbnRpZmllciB7DQo+ID4+ICAg ICAgcmVxdWlyZS1pbnN0YW5jZSB0cnVlOw0KPiA+PiAgICB9DQo+ID4+ICB9DQo+ID4+IH0NCj4g Pj4gDQo+ID4+IE5vdywgaXMgdGhlIGZvbGxvd2luZyBpbnN0YW5jZSBkYXRhIHZhbGlkPw0KPiA+ PiANCj4gPj4gPGRhdGEgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNl OjEuMCINCj4gPj4gCSB4bWxuczppaz0iaHR0cDovL2V4YW1wbGUuY29tL2lpLWtleSI+DQo+ID4+ ICA8aWs6YXJyPg0KPiA+PiAgICA8aWs6azE+MzwvaWs6azE+DQo+ID4+ICAgIDxpazprMj5mb288 L2lrOmsyPg0KPiA+PiAgPC9pazphcnI+DQo+ID4+ICA8aWs6aWk+L2lrOmFycltpazprMT0nMDMn XS9pazprMjwvaWs6aWk+DQo+ID4+IDwvZGF0YT4NCj4gPj4gDQo+ID4+IERTREwgdmFsaWRhdGlv biBzYXlzIGl0IGlzbid0Og0KPiA+PiANCj4gPj4gPT0gVmFsaWRhdGluZyBzZW1hbnRpYyBjb25z dHJhaW50cyAuLi4NCj4gPj4gLS0tIEZhaWxlZCBhc3NlcnQgYXQgIi9uYzpkYXRhL2lrOmlpIjoN Cj4gPj4gICAgVGhlIGluc3RhbmNlICIvbmM6ZGF0YS9pazphcnJbaWs6azE9JzAzJ10vaWs6azIi IG11c3QgZXhpc3QuDQo+ID4+IA0KPiA+PiBUaGlzIGlzIGJlY2F1c2UgWFBhdGggMS4wIHNwZWMg bWFuZGF0ZXMgdGhlICpzdHJpbmcqIGVxdWFsaXR5DQo+ID4+IGNvbXBhcmlzb24NCj4gPj4gZm9y IHRoZSAiazEiIGtleSwgYW5kICczJyAhPSAnMDMnLiBJZiB3ZSB1c2VkIGEgbnVtYmVyIGluIHRo ZQ0KPiA+PiBrZXktcHJlZGljYXRlLCB0aGVuIFNjaGVtYXRyb24gdmFsaWRhdGlvbiB3b3VsZCBz dWNjZWVkOg0KPiA+PiANCj4gPj4gIDxpazppaT4vaWs6YXJyW2lrOmsxPTAzXS9pazprMjwvaWs6 aWk+DQo+ID4+IA0KPiA+PiBUaGlzIGlzIGhvd2V2ZXIgbm90IGEgdmFsaWQgaW5zdGFuY2UtaWRl bnRpZmllci4NCj4gPj4gDQo+ID4+IFRoZXJlIGFyZSBJTU8gdHdvIHBvc3NpYmxlIHNvbHV0aW9u cyB0byB0aGlzIGlzc3VlOg0KPiA+PiANCj4gPj4gMS4gQXZvaWQgcmVmZXJlbmNlIHRvIFhQYXRo LCBqdXN0IHVzZSB0aGUgQUJORiBmb3INCj4gPj4gaW5zdGFuY2UtaW5kZW50aWZpZXINCj4gPj4g ICBzeW50YXgsIGFuZCBzYXkgdGhhdCB0aGUgZXF1YWxpdHkgY29tcGFyaXNvbiBpcyBwZXJmb3Jt ZWQgb24NCj4gPj4gICBjYW5vbmljYWwgdmFsdWVzIG9mIGtleXMgYW5kIHN0cmluZyBsaXRlcmFs cyBpbiBrZXktcHJlZGljYXRlcy4NCj4gPj4gDQo+ID4+IDIuIFBlcm1pdCBudW1lcmljIGxpdGVy YWxzIGluIGtleS1wcmVkaWNhdGUgYW5kIGxlYWYtbGlzdC1wcmVkaWNhdGUuDQo+ID4+IA0KPiA+ IA0KPiA+IFNlY3Rpb24gNy42Og0KPiA+IA0KPiA+ICAgQSBsZWFmIG5vZGUgaGFzIGEgdmFsdWUs IGJ1dCBubyBjaGlsZCBub2RlcyBpbiB0aGUgZGF0YSB0cmVlLg0KPiA+ICAgQ29uY2VwdHVhbGx5 LCB0aGUgdmFsdWUgaW4gdGhlIGRhdGEgdHJlZSBpcyBhbHdheXMgaW4gdGhlIGNhbm9uaWNhbA0K PiA+ICAgZm9ybSAoc2VlIFNlY3Rpb24gOS4xKS4NCj4gPiANCj4gPiBTZWN0aW9uIDcuNzoNCj4g PiANCj4gPiAgIENvbmNlcHR1YWxseSwgdGhlIHZhbHVlcyBpbiB0aGUgZGF0YSB0cmVlIGFyZSBh bHdheXMgaW4gdGhlIGNhbm9uaWNhbA0KPiA+ICAgZm9ybSAoc2VlIFNlY3Rpb24gOS4xKS4NCj4g PiANCj4gPiBTZWN0aW9uIDcuNS4zOg0KPiA+IA0KPiA+ICAgTm90ZSB0aGF0IHNpbmNlIGFsbCBs ZWFmIHZhbHVlcyBpbiB0aGUgZGF0YSB0cmVlIGFyZSBjb25jZXB0dWFsbHkNCj4gPiAgIHN0b3Jl ZCBpbiB0aGVpciBjYW5vbmljYWwgZm9ybSAoc2VlIFNlY3Rpb24gOS4xKSwgYW55IFhQYXRoDQo+ ID4gICBjb21wYXJpc29ucyBhcmUgZG9uZSBvbiB0aGUgY2Fub25pY2FsIHZhbHVlLg0KPiANCj4g Rm9yIHRoZSBsZWFmIHRoYXQncyBpbiB0aGUgZGF0YSB0cmVlIOKAkyA8aWs6azE+MzwvaWs6azE+ IOKAkyB0aGUNCj4gY2Fub25pY2FsIHZhbHVlIGlzIGluZGVlZCB1c2VkLg0KDQouLi4gd2hpY2gg bWVhbnMgdGhhdCB0aGUgaS1pIHZhbHVlIG11c3QgdXNlICIzIiwgbm90ICIwMyIuDQoNCj4gQW5k IGluc3RhbmNlLWlkZW50aWZpZXIgaGFzIG5vDQo+IGNhbm9uaWNhbCB2YWx1ZS4NCj4gDQo+ID4g DQo+ID4gRG8geW91IHN1Z2dlc3QgdGhhdCB0aGVyZSBzaG91bGQgYmUgYWRkaXRpb25hbCBub3Rl cyBpbnNlcnRlZCBhdA0KPiA+IHZhcmlvdXMgcGxhY2VzPyBUaGUgZ2VuZXJhbCBzcGlyaXQgSSB0 aGluayBoYXMgYWx3YXlzIGJlZW4gdG8gdXNlDQo+ID4gY2Fub25pY2FsIGZvcm1zIG9mIHRoZSB2 YWx1ZXMuDQo+IA0KPiBXZSBjYW4gYXNzdW1lIHRoYXQgdGhlIGRhdGEgdHJlZSBoYXMgYWxsIGxl YWYgdmFsdWVzIGluIHRoZWlyDQo+IGNhbm9uaWNhbCBmb3JtLCBidXQgYWZ0ZXIgdGhhdCB3ZSBt dXN0IElNTyBleGFjdGx5IGZvbGxvdyB0aGUgWFBhdGgNCj4gc2VtYW50aWNzIGJlY2F1c2Ugb3Ro ZXJ3aXNlIHdlIGNvdWxkIGVhc2lseSBydW4gaW50byB0cm91Ymxlcy4gRm9yDQo+IGV4YW1wbGUs IHNvbWV0aW1lcyB0aGUgY2Fub25pY2FsIGZvcm0gb2YgY29tcGFyaXNvbiBvcGVyYW5kcyBjYW5u b3QgYmUNCj4gZGV0ZXJtaW5lZDoNCj4gDQo+IGNvbnRhaW5lciB0b3Agew0KPiAgIG11c3QgImZv byArIGJhciA8ICczJyI7DQo+ICAgbGVhZiBmb28gew0KPiAgICAgdHlwZSB1aW50ODsNCj4gICB9 DQo+ICAgbGVhZiBiYXIgew0KPiAgICAgdHlwZSBkZWNpbWFsNjQgew0KPiAgICAgICBmcmFjdGlv bi1kaWdpdHMgMjsNCj4gICAgIH0NCj4gICB9DQo+IH0NCj4gDQo+IFRoZSBjYW5vbmljYWwgZm9y bSBvZiB0aGUgc3VtIGZvbyArIGJhciBpcyB1bmRlZmluZWQuDQoNCkkgZG9uJ3QgdW5kZXJzdGFu ZCB3aGF0IHRoaXMgaGFzIHRvIGRvIHdpdGggdGhlIGktaSBpc3N1ZS4NCg0KDQovbWFydGluDQo= From nobody Tue Jun 7 05:46:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E6112B04A for ; Tue, 7 Jun 2016 05:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 8m8YxlrFjUpY for ; Tue, 7 Jun 2016 05:46:43 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F0E4912D1D2 for ; Tue, 7 Jun 2016 05:46:42 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 193581AE0404; Tue, 7 Jun 2016 14:46:42 +0200 (CEST) Date: Tue, 07 Jun 2016 14:47:04 +0200 (CEST) Message-Id: <20160607.144704.142557620456465354.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <75A8B2DB-7D6D-4D65-BCCD-3B747A0BFC26@nic.cz> References: <20160606140206.GA7125@elstar.local> <75A8B2DB-7D6D-4D65-BCCD-3B747A0BFC26@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] keys in instance-identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 12:46:44 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDYgSnVu IDIwMTYsIGF0IDE2OjAyLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4gDQo+ID4gT24gTW9uLCBKdW4gMDYsIDIw MTYgYXQgMDM6NDM6MjNQTSArMDIwMCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPiA+PiANCj4g Pj4+IE9uIDA2IEp1biAyMDE2LCBhdCAxNTowOSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNj aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+Pj4gDQo+ID4+PiBP biBNb24sIEp1biAwNiwgMjAxNiBhdCAxMDoxMzo0N0FNICswMjAwLCBMYWRpc2xhdiBMaG90a2Eg d3JvdGU6DQo+ID4+Pj4gSGksDQo+ID4+Pj4gDQo+ID4+Pj4gc2VjdGlvbiA5LjEzIGluIHJmYzYw MjAtYmlzIHNheXM6DQo+ID4+Pj4gDQo+ID4+Pj4gIFRoZSBzeW50YXggZm9yIGFuIGluc3RhbmNl LWlkZW50aWZpZXIgaXMgYSBzdWJzZXQgb2YgdGhlIFhQYXRoDQo+ID4+Pj4gIGFiYnJldmlhdGVk IHN5bnRheCwgZm9ybWFsbHkgZGVmaW5lZCBieSB0aGUgcnVsZQ0KPiA+Pj4+ICAiaW5zdGFuY2Ut aWRlbnRpZmllciIgaW4gU2VjdGlvbiAxNC4NCj4gPj4+PiANCj4gPj4+PiBIb3dldmVyLCB0aGUg QUJORiBvbmx5IGFsbG93cyBzdHJpbmcgbGl0ZXJhbHMgaW4ga2V5IHByZWRpY2F0ZXM6DQo+ID4+ Pj4gDQo+ID4+Pj4gIGtleS1wcmVkaWNhdGUgICAgICAgPSAiWyIgKldTUCBrZXktcHJlZGljYXRl LWV4cHIgKldTUCAiXSINCj4gPj4+PiANCj4gPj4+PiAga2V5LXByZWRpY2F0ZS1leHByICA9IG5v ZGUtaWRlbnRpZmllciAqV1NQICI9IiAqV1NQIHF1b3RlZC1zdHJpbmcNCj4gPj4+PiANCj4gPj4+ PiBJIHRoaW5rIHRoaXMgbGVhZHMgdG8gcHJvYmxlbXMgd2l0aCBrZXlzIHRoYXQgaGF2ZSBhIG51 bWVyaWMNCj4gPj4+PiB0eXBlLiBDb25zaWRlciB0aGlzIG1vZHVsZToNCj4gPj4+PiANCj4gPj4+ PiBtb2R1bGUgaWkta2V5IHsNCj4gPj4+PiB5YW5nLXZlcnNpb24gMS4xOw0KPiA+Pj4+IG5hbWVz cGFjZSAiaHR0cDovL2V4YW1wbGUuY29tL2lpLWtleSI7DQo+ID4+Pj4gcHJlZml4IGlrOw0KPiA+ Pj4+IA0KPiA+Pj4+IGxpc3QgYXJyIHsNCj4gPj4+PiAgIGtleSAiazEiOw0KPiA+Pj4+ICAgbGVh ZiBrMSB7DQo+ID4+Pj4gICAgIHR5cGUgdWludDg7DQo+ID4+Pj4gICB9DQo+ID4+Pj4gICBsZWFm IGsyIHsNCj4gPj4+PiAgICAgdHlwZSBzdHJpbmc7DQo+ID4+Pj4gICB9DQo+ID4+Pj4gfQ0KPiA+ Pj4+IGxlYWYgaWkgew0KPiA+Pj4+ICAgdHlwZSBpbnN0YW5jZS1pZGVudGlmaWVyIHsNCj4gPj4+ PiAgICAgcmVxdWlyZS1pbnN0YW5jZSB0cnVlOw0KPiA+Pj4+ICAgfQ0KPiA+Pj4+IH0NCj4gPj4+ PiB9DQo+ID4+Pj4gDQo+ID4+Pj4gTm93LCBpcyB0aGUgZm9sbG93aW5nIGluc3RhbmNlIGRhdGEg dmFsaWQ/DQo+ID4+Pj4gDQo+ID4+Pj4gPGRhdGEgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6 bnM6bmV0Y29uZjpiYXNlOjEuMCINCj4gPj4+PiAJIHhtbG5zOmlrPSJodHRwOi8vZXhhbXBsZS5j b20vaWkta2V5Ij4NCj4gPj4+PiA8aWs6YXJyPg0KPiA+Pj4+ICAgPGlrOmsxPjM8L2lrOmsxPg0K PiA+Pj4+ICAgPGlrOmsyPmZvbzwvaWs6azI+DQo+ID4+Pj4gPC9pazphcnI+DQo+ID4+Pj4gPGlr OmlpPi9pazphcnJbaWs6azE9JzAzJ10vaWs6azI8L2lrOmlpPg0KPiA+Pj4+IDwvZGF0YT4NCj4g Pj4+PiANCj4gPj4+PiBEU0RMIHZhbGlkYXRpb24gc2F5cyBpdCBpc24ndDoNCj4gPj4+PiANCj4g Pj4+PiA9PSBWYWxpZGF0aW5nIHNlbWFudGljIGNvbnN0cmFpbnRzIC4uLg0KPiA+Pj4+IC0tLSBG YWlsZWQgYXNzZXJ0IGF0ICIvbmM6ZGF0YS9pazppaSI6DQo+ID4+Pj4gICBUaGUgaW5zdGFuY2Ug Ii9uYzpkYXRhL2lrOmFycltpazprMT0nMDMnXS9pazprMiIgbXVzdCBleGlzdC4NCj4gPj4+PiAN Cj4gPj4+PiBUaGlzIGlzIGJlY2F1c2UgWFBhdGggMS4wIHNwZWMgbWFuZGF0ZXMgdGhlICpzdHJp bmcqIGVxdWFsaXR5IGNvbXBhcmlzb24NCj4gPj4+PiBmb3IgdGhlICJrMSIga2V5LCBhbmQgJzMn ICE9ICcwMycuIElmIHdlIHVzZWQgYSBudW1iZXIgaW4gdGhlDQo+ID4+Pj4ga2V5LXByZWRpY2F0 ZSwgdGhlbiBTY2hlbWF0cm9uIHZhbGlkYXRpb24gd291bGQgc3VjY2VlZDoNCj4gPj4+PiANCj4g Pj4+PiA8aWs6aWk+L2lrOmFycltpazprMT0wM10vaWs6azI8L2lrOmlpPg0KPiA+Pj4+IA0KPiA+ Pj4+IFRoaXMgaXMgaG93ZXZlciBub3QgYSB2YWxpZCBpbnN0YW5jZS1pZGVudGlmaWVyLg0KPiA+ Pj4+IA0KPiA+Pj4+IFRoZXJlIGFyZSBJTU8gdHdvIHBvc3NpYmxlIHNvbHV0aW9ucyB0byB0aGlz IGlzc3VlOg0KPiA+Pj4+IA0KPiA+Pj4+IDEuIEF2b2lkIHJlZmVyZW5jZSB0byBYUGF0aCwganVz dCB1c2UgdGhlIEFCTkYgZm9yIGluc3RhbmNlLWluZGVudGlmaWVyDQo+ID4+Pj4gIHN5bnRheCwg YW5kIHNheSB0aGF0IHRoZSBlcXVhbGl0eSBjb21wYXJpc29uIGlzIHBlcmZvcm1lZCBvbg0KPiA+ Pj4+ICBjYW5vbmljYWwgdmFsdWVzIG9mIGtleXMgYW5kIHN0cmluZyBsaXRlcmFscyBpbiBrZXkt cHJlZGljYXRlcy4NCj4gPj4+PiANCj4gPj4+PiAyLiBQZXJtaXQgbnVtZXJpYyBsaXRlcmFscyBp biBrZXktcHJlZGljYXRlIGFuZCBsZWFmLWxpc3QtcHJlZGljYXRlLg0KPiA+Pj4+IA0KPiA+Pj4g DQo+ID4+PiBTZWN0aW9uIDcuNjoNCj4gPj4+IA0KPiA+Pj4gIEEgbGVhZiBub2RlIGhhcyBhIHZh bHVlLCBidXQgbm8gY2hpbGQgbm9kZXMgaW4gdGhlIGRhdGEgdHJlZS4NCj4gPj4+ICBDb25jZXB0 dWFsbHksIHRoZSB2YWx1ZSBpbiB0aGUgZGF0YSB0cmVlIGlzIGFsd2F5cyBpbiB0aGUgY2Fub25p Y2FsDQo+ID4+PiAgZm9ybSAoc2VlIFNlY3Rpb24gOS4xKS4NCj4gPj4+IA0KPiA+Pj4gU2VjdGlv biA3Ljc6DQo+ID4+PiANCj4gPj4+ICBDb25jZXB0dWFsbHksIHRoZSB2YWx1ZXMgaW4gdGhlIGRh dGEgdHJlZSBhcmUgYWx3YXlzIGluIHRoZSBjYW5vbmljYWwNCj4gPj4+ICBmb3JtIChzZWUgU2Vj dGlvbiA5LjEpLg0KPiA+Pj4gDQo+ID4+PiBTZWN0aW9uIDcuNS4zOg0KPiA+Pj4gDQo+ID4+PiAg Tm90ZSB0aGF0IHNpbmNlIGFsbCBsZWFmIHZhbHVlcyBpbiB0aGUgZGF0YSB0cmVlIGFyZSBjb25j ZXB0dWFsbHkNCj4gPj4+ICBzdG9yZWQgaW4gdGhlaXIgY2Fub25pY2FsIGZvcm0gKHNlZSBTZWN0 aW9uIDkuMSksIGFueSBYUGF0aA0KPiA+Pj4gIGNvbXBhcmlzb25zIGFyZSBkb25lIG9uIHRoZSBj YW5vbmljYWwgdmFsdWUuDQo+ID4+IA0KPiA+PiBGb3IgdGhlIGxlYWYgdGhhdCdzIGluIHRoZSBk YXRhIHRyZWUg4oCTIDxpazprMT4zPC9pazprMT4g4oCTIHRoZSBjYW5vbmljYWwgdmFsdWUgaXMg aW5kZWVkIHVzZWQuIEFuZCBpbnN0YW5jZS1pZGVudGlmaWVyIGhhcyBubyBjYW5vbmljYWwgdmFs dWUuDQo+ID4+IA0KPiA+Pj4gDQo+ID4+PiBEbyB5b3Ugc3VnZ2VzdCB0aGF0IHRoZXJlIHNob3Vs ZCBiZSBhZGRpdGlvbmFsIG5vdGVzIGluc2VydGVkIGF0DQo+ID4+PiB2YXJpb3VzIHBsYWNlcz8g VGhlIGdlbmVyYWwgc3Bpcml0IEkgdGhpbmsgaGFzIGFsd2F5cyBiZWVuIHRvIHVzZQ0KPiA+Pj4g Y2Fub25pY2FsIGZvcm1zIG9mIHRoZSB2YWx1ZXMuDQo+ID4+IA0KPiA+PiBXZSBjYW4gYXNzdW1l IHRoYXQgdGhlIGRhdGEgdHJlZSBoYXMgYWxsIGxlYWYgdmFsdWVzIGluIHRoZWlyIGNhbm9uaWNh bCBmb3JtLCBidXQgYWZ0ZXIgdGhhdCB3ZSBtdXN0IElNTyBleGFjdGx5IGZvbGxvdyB0aGUgWFBh dGggc2VtYW50aWNzIGJlY2F1c2Ugb3RoZXJ3aXNlIHdlIGNvdWxkIGVhc2lseSBydW4gaW50byB0 cm91Ymxlcy4gRm9yIGV4YW1wbGUsIHNvbWV0aW1lcyB0aGUgY2Fub25pY2FsIGZvcm0gb2YgY29t cGFyaXNvbiBvcGVyYW5kcyBjYW5ub3QgYmUgZGV0ZXJtaW5lZDoNCj4gPj4gDQo+ID4+IGNvbnRh aW5lciB0b3Agew0KPiA+PiAgbXVzdCAiZm9vICsgYmFyIDwgJzMnIjsNCj4gPj4gIGxlYWYgZm9v IHsNCj4gPj4gICAgdHlwZSB1aW50ODsNCj4gPj4gIH0NCj4gPj4gIGxlYWYgYmFyIHsNCj4gPj4g ICAgdHlwZSBkZWNpbWFsNjQgew0KPiA+PiAgICAgIGZyYWN0aW9uLWRpZ2l0cyAyOw0KPiA+PiAg ICB9DQo+ID4+ICB9DQo+ID4+IH0NCj4gPj4gDQo+ID4+IFRoZSBjYW5vbmljYWwgZm9ybSBvZiB0 aGUgc3VtIGZvbyArIGJhciBpcyB1bmRlZmluZWQuDQo+ID4gDQo+ID4gVGhpcyBleGFtcGxlIGRv ZXMgbm90IHNlZW0gdG8gcmVsYXRlIHRvIGluc3RhbmNlIGlkZW50aWZpZXJzLg0KPiANCj4gSXQg ZG9lc24ndCwgYnV0IHlvdSByZWZlcnJlZCB0byBnZW5lcmljIHJ1bGVzIGZvciBYUGF0aCB1c2Fn ZSBpbiBZQU5HLiBNeSBwb2ludCBpcyB0aGF0IGNhbm9uaWNhbCBmb3JtIGNhbm5vdCBiZSBhcHBs aWVkIHRvIGxpdGVyYWwgdmFsdWVzIGFwcGVhcmluZyBpbiBYUGF0aCBleHByZXNzaW9ucy4NCj4g DQo+ID4gSSBhbSBub3QNCj4gPiBzdXJlIHdoYXQgeW91IGFyZSBhc2tpbmcgZm9yLiBPTEQgTkVX IHN0eWxlIG9mIHRleHQgcHJvcG9zYWxzIHdvdWxkDQo+ID4gaGVscCBtZS4NCj4gDQo+IFRoaXMg aXMgZm9yIG15IG9wdGlvbiAjMjoNCj4gDQo+IE9MRA0KPiANCj4gICAga2V5LXByZWRpY2F0ZS1l eHByICA9IG5vZGUtaWRlbnRpZmllciAqV1NQICI9IiAqV1NQIHF1b3RlZC1zdHJpbmcNCj4gDQo+ IE5FVw0KPiANCj4gICAga2V5LXByZWRpY2F0ZS1leHByICA9IG5vZGUtaWRlbnRpZmllciAqV1NQ ICI9IiAqV1NQICggcXVvdGVkLXN0cmluZyAvIGRlY2ltYWwtdmFsdWUgKQ0KDQoNCg0KSSBkb24n dCB0aGluayB0aGlzIGlzIG5lY2Vzc2FyeS4gIFdoZW4gaS1pcyBhcmUgY29uc3RydWN0ZWQsIHRo ZQ0KY2Fub25pY2FsIHZhbHVlIG11c3QgYmUgdXNlZC4NCg0KDQoNCi9tYXJ0aW4NCg== From nobody Tue Jun 7 07:04:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF84F12D685 for ; Tue, 7 Jun 2016 07:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 PnuxN7ZKiD2j for ; Tue, 7 Jun 2016 07:04:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785AF12D62D for ; Tue, 7 Jun 2016 07:04:50 -0700 (PDT) Received: from [192.168.43.183] (cst-prg-252-8.cust.vodafone.cz [46.135.252.8]) by mail.nic.cz (Postfix) with ESMTPSA id C919D607DD; Tue, 7 Jun 2016 16:04:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465308289; bh=x6P3J5oRgBLvUsyIJTCa+L93lRtf1kXo6Uf0Ve6482k=; h=From:Date:To; b=f4ixH1XdnY5LcdrUXfloP6yzBZHOMHFuH2v2J6hrlpigjc/g0O/NWwowdhflcAq5D D4IoK9Ce14OiK6RFH2U0IS+Xw6s9LYUGU5rIcOMPqkeryFYESh4q0+Vdp/HUNIaFsC tYKKw+3D/qAg92ngJua+Kv3RRti/n9+WzbstSo/Y= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160607.144704.142557620456465354.mbj@tail-f.com> Date: Tue, 7 Jun 2016 16:03:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <32CFED95-7D43-4F80-B59A-5EBDC037D96C@nic.cz> References: <20160606140206.GA7125@elstar.local> <75A8B2DB-7D6D-4D65-BCCD-3B747A0BFC26@nic.cz> <20160607.144704.142557620456465354.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] keys in instance-identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 14:04:55 -0000 > On 07 Jun 2016, at 14:47, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 06 Jun 2016, at 16:02, Juergen Schoenwaelder = wrote: >>>=20 >>> On Mon, Jun 06, 2016 at 03:43:23PM +0200, Ladislav Lhotka wrote: >>>>=20 >>>>> On 06 Jun 2016, at 15:09, Juergen Schoenwaelder = wrote: >>>>>=20 >>>>> On Mon, Jun 06, 2016 at 10:13:47AM +0200, Ladislav Lhotka wrote: >>>>>> Hi, >>>>>>=20 >>>>>> section 9.13 in rfc6020-bis says: >>>>>>=20 >>>>>> The syntax for an instance-identifier is a subset of the XPath >>>>>> abbreviated syntax, formally defined by the rule >>>>>> "instance-identifier" in Section 14. >>>>>>=20 >>>>>> However, the ABNF only allows string literals in key predicates: >>>>>>=20 >>>>>> key-predicate =3D "[" *WSP key-predicate-expr *WSP "]" >>>>>>=20 >>>>>> key-predicate-expr =3D node-identifier *WSP "=3D" *WSP = quoted-string >>>>>>=20 >>>>>> I think this leads to problems with keys that have a numeric >>>>>> type. Consider this module: >>>>>>=20 >>>>>> module ii-key { >>>>>> yang-version 1.1; >>>>>> namespace "http://example.com/ii-key"; >>>>>> prefix ik; >>>>>>=20 >>>>>> list arr { >>>>>> key "k1"; >>>>>> leaf k1 { >>>>>> type uint8; >>>>>> } >>>>>> leaf k2 { >>>>>> type string; >>>>>> } >>>>>> } >>>>>> leaf ii { >>>>>> type instance-identifier { >>>>>> require-instance true; >>>>>> } >>>>>> } >>>>>> } >>>>>>=20 >>>>>> Now, is the following instance data valid? >>>>>>=20 >>>>>> >>>>> xmlns:ik=3D"http://example.com/ii-key"> >>>>>> >>>>>> 3 >>>>>> foo >>>>>> >>>>>> /ik:arr[ik:k1=3D'03']/ik:k2 >>>>>> >>>>>>=20 >>>>>> DSDL validation says it isn't: >>>>>>=20 >>>>>> =3D=3D Validating semantic constraints ... >>>>>> --- Failed assert at "/nc:data/ik:ii": >>>>>> The instance "/nc:data/ik:arr[ik:k1=3D'03']/ik:k2" must exist. >>>>>>=20 >>>>>> This is because XPath 1.0 spec mandates the *string* equality = comparison >>>>>> for the "k1" key, and '3' !=3D '03'. If we used a number in the >>>>>> key-predicate, then Schematron validation would succeed: >>>>>>=20 >>>>>> /ik:arr[ik:k1=3D03]/ik:k2 >>>>>>=20 >>>>>> This is however not a valid instance-identifier. >>>>>>=20 >>>>>> There are IMO two possible solutions to this issue: >>>>>>=20 >>>>>> 1. Avoid reference to XPath, just use the ABNF for = instance-indentifier >>>>>> syntax, and say that the equality comparison is performed on >>>>>> canonical values of keys and string literals in key-predicates. >>>>>>=20 >>>>>> 2. Permit numeric literals in key-predicate and = leaf-list-predicate. >>>>>>=20 >>>>>=20 >>>>> Section 7.6: >>>>>=20 >>>>> A leaf node has a value, but no child nodes in the data tree. >>>>> Conceptually, the value in the data tree is always in the = canonical >>>>> form (see Section 9.1). >>>>>=20 >>>>> Section 7.7: >>>>>=20 >>>>> Conceptually, the values in the data tree are always in the = canonical >>>>> form (see Section 9.1). >>>>>=20 >>>>> Section 7.5.3: >>>>>=20 >>>>> Note that since all leaf values in the data tree are conceptually >>>>> stored in their canonical form (see Section 9.1), any XPath >>>>> comparisons are done on the canonical value. >>>>=20 >>>> For the leaf that's in the data tree =E2=80=93 3 =E2=80= =93 the canonical value is indeed used. And instance-identifier has no = canonical value. >>>>=20 >>>>>=20 >>>>> Do you suggest that there should be additional notes inserted at >>>>> various places? The general spirit I think has always been to use >>>>> canonical forms of the values. >>>>=20 >>>> We can assume that the data tree has all leaf values in their = canonical form, but after that we must IMO exactly follow the XPath = semantics because otherwise we could easily run into troubles. For = example, sometimes the canonical form of comparison operands cannot be = determined: >>>>=20 >>>> container top { >>>> must "foo + bar < '3'"; >>>> leaf foo { >>>> type uint8; >>>> } >>>> leaf bar { >>>> type decimal64 { >>>> fraction-digits 2; >>>> } >>>> } >>>> } >>>>=20 >>>> The canonical form of the sum foo + bar is undefined. >>>=20 >>> This example does not seem to relate to instance identifiers. >>=20 >> It doesn't, but you referred to generic rules for XPath usage in = YANG. My point is that canonical form cannot be applied to literal = values appearing in XPath expressions. >>=20 >>> I am not >>> sure what you are asking for. OLD NEW style of text proposals would >>> help me. >>=20 >> This is for my option #2: >>=20 >> OLD >>=20 >> key-predicate-expr =3D node-identifier *WSP "=3D" *WSP = quoted-string >>=20 >> NEW >>=20 >> key-predicate-expr =3D node-identifier *WSP "=3D" *WSP ( = quoted-string / decimal-value ) >=20 >=20 >=20 > I don't think this is necessary. When i-is are constructed, the > canonical value must be used. OK, this works for numbers, although it would IMO be more robust to = utilise the ability of XPath to perform numeric comparisons. But what if the canonical value isn't defined, e.g. when the list key is = an identityref? It would be handy to be able to use the derived-from() = function as a key predicate. Lada >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 7 07:14:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D516612D689 for ; Tue, 7 Jun 2016 07:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 JhXjxC_Od34q for ; Tue, 7 Jun 2016 07:14:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C34E12D672 for ; Tue, 7 Jun 2016 07:14:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E3806100C; Tue, 7 Jun 2016 16:14:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xIE9BdV_Pzih; Tue, 7 Jun 2016 16:14:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 7 Jun 2016 16:14:39 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BCAC20047; Tue, 7 Jun 2016 16:14:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DdQrLiySHqmD; Tue, 7 Jun 2016 16:14:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3489620053; Tue, 7 Jun 2016 16:14:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7387D3B0AE83; Tue, 7 Jun 2016 16:14:37 +0200 (CEST) Date: Tue, 7 Jun 2016 16:14:37 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160607141437.GA9599@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , netmod@ietf.org References: <20160606140206.GA7125@elstar.local> <75A8B2DB-7D6D-4D65-BCCD-3B747A0BFC26@nic.cz> <20160607.144704.142557620456465354.mbj@tail-f.com> <32CFED95-7D43-4F80-B59A-5EBDC037D96C@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32CFED95-7D43-4F80-B59A-5EBDC037D96C@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] keys in instance-identifiers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 14:14:43 -0000 On Tue, Jun 07, 2016 at 04:03:43PM +0200, Ladislav Lhotka wrote: > > But what if the canonical value isn't defined, e.g. when the list key is an identityref? It would be handy to be able to use the derived-from() function as a key predicate. > Lada, we are at a stage where the document should already be in the RFC editor's hands. If you think you have found a _fatal flaw_, you have to explain what the flaw is and you should ideally provide a clear proposal how to fix the bug (OLD NEW style diff works best). Essentially the same level of detail as expected for RFC errata. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 7 07:19:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5124112D69C for ; Tue, 7 Jun 2016 07:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le2kOETL4jEi for ; Tue, 7 Jun 2016 07:19:50 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id B1FC812D698 for ; Tue, 7 Jun 2016 07:19:50 -0700 (PDT) Received: (qmail 5535 invoked by uid 0); 7 Jun 2016 14:19:46 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy6.mail.unifiedlayer.com with SMTP; 7 Jun 2016 14:19:46 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 3qKe1t01R2SSUrH01qKhN9; Tue, 07 Jun 2016 08:19:46 -0600 X-Authority-Analysis: v=2.1 cv=KpLehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=TL9BaDznW2IkSGiZndEA:9 a=BMDbz8cccd7KaCIs:21 a=OIXE3oXG6TRtdfpr:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:To:Cc:From; bh=+cNqLABu2P7Igm27d7nqGqM67DZzRkG8Osc5YUsrHUM=; b=RFbjfOINlvMk+FcUVpM7uy6Fe2 AoBZyyMaWx8JAK/u+7E9ngDhvmzdRcI1I6xmq3ST4udHfVdarungudkn/c+OB6VGjL1qnNjoMf0G5 mGN4ZLchmadsIwOt1u52d1AiZ; Received: from box313.bluehost.com ([69.89.31.113]:52296 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bAHr0-00041z-Po; Tue, 07 Jun 2016 08:19:38 -0600 From: Lou Berger To: netmod WG Message-ID: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> Date: Tue, 7 Jun 2016 10:19:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "netmod-chairs@ietf.org" Subject: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 14:19:52 -0000 All, We want to provide an update based on the off line discussions related to OpState Solutions that we have been having and solicit input from the WG. All authors of current solution drafts [1,2,3] together with those who helped conduct the solutions analysis* were invited to the these discussions -- with the objective of coming up with a single consolidated proposal to bring to the WG. (I/Lou acted as facilitator as Kent and Juergen were and are involved with the technical details.) The discussions have yielded some results but, unfortunately, not a single consolidated proposal as hoped, but rather two alternate directions -- and clearly we need to choose one: 1) Adopt the conventions for representing state/config based on Section 6 of [1]. From a model definition perspective, these conventions impact every model and every model writer. 2) Model OpState using a revised logical datastore definition as introduced in [4] and also covered in [5]. There is also a variant of this that we believe doesn't significantly impact this choice. With this approach, model definitions need no explicit changes to support applied configuration. >From a technology/WG standpoint, we believe an approach that doesn't impact every model written (i.e., #2) is superior. The counterpoint to this is that the conventions based approach (i.e., #1) is available today and being followed in OpenConfig defined models. We would like to hear opinions on this from the WG before declaring one of the following as the WG direction: A) models that wish to support applied configuration MUST follow conventions based on [1] -- and the WG needs to formalize these conventions. or B) no explicit support is required for models to support applied configuration -- and that the WG needs to formalize an opstate solution based on the approach discussed in [4] and [5]. We intend to close on this choice before Berlin. Thank you, Lou (and co-chairs) [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 * - Chris H. and Acee L. From nobody Tue Jun 7 08:26:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832A612D775 for ; Tue, 7 Jun 2016 08:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 6Dunt7i9xTgi for ; Tue, 7 Jun 2016 08:26:07 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 55E8412D0F4 for ; Tue, 7 Jun 2016 08:26:06 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-01v.sys.comcast.net with SMTP id AIqabzVxG13YVAItJbjI7x; Tue, 07 Jun 2016 15:26:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465313165; bh=WzNL3hGYkDmtOlIe4MQDGq0vjjIGMyQPwTbbnPO6i9o=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=wJoOR473Vxgx4vNWOIVBBqXBo5Dl+7GzlCMZBxudPV1VnY40RHwtrgjX6UkysYMIP KE+6OjUvNLh9L9vEGA0J1ZkKuPxkW6Sqe7RKz5Lc6XTHkzN+UUsLB6WsXR2SCdCGAZ jEBlI9QxmJQ8YZc5LLPd07yjkuTBHTtc7qYPHNDJQFFKiQlvzIKZZQRdwrTqMnw9nC 6BIosVAvCeQTTh51U22r4Rzyfsau8acAnACM3kmX2AGwvRdBBDgkr2ymnyxs57Ydp2 lrIasONDauXa9E51Zm+1GDFor+jrwJrxJ2II3sgJoJVVLCxuEFpS617VNTIrsw+xIC zktx9xGjW9pQQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id 3rS41t00X1nMCLR01rS54R; Tue, 07 Jun 2016 15:26:05 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u57FQ4oP015107; Tue, 7 Jun 2016 11:26:04 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u57FQ3I9015100; Tue, 7 Jun 2016 11:26:03 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ladislav Lhotka In-Reply-To: (lhotka@nic.cz) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 07 Jun 2016 11:26:03 -0400 Message-ID: <87ziqx81h0.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 15:26:08 -0000 Ladislav Lhotka writes: > "Dale R. Worley" writes: >> A difficulty I have with the current wording is that it doesn't point >> out the crucial fact about leafref that the XPath expression can only >> select elements that are instantiations of one particular data node. I >> don't know XPath, but it seems that that is not a general property of >> XPath expressions, you seem to be able to write XPath expressions that >> select heterogenous groups of elements. So it's worth pointing out that >> the allowed XPath expressions can't do that, and that is because of the >> restriction that the expression must match path-arg. > > Right, this is the slightly hand-waving part that I also objected to. An > XPath expression in a leafref's "path" statement indeed selects a node > set from an instance data tree. The node seet can be empty, but if it is > non-empty, all its members necessarily have the same type, which is > defined in a certain "leaf" schema node. > > The relationship is relatively straightforward but difficult to explain > concisely. One basically has to follow the steps in the XPath > expression, ignore all path-predicates, and skip all schema nodes that > aren't data nodes (i.e., "choice" and "case" nodes). Yes, it's difficult to explain, though once one gets the idea, it's straightforward enough. The problem I have is that it's not pointed out explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I don't see it there.) The crucial points seem to be: - The XPath expression is limited by the syntax "path-arg" and the rules in 9.9.2. - Because of those restrictions, there exists one data node in the schema such that: evalutating the expression for any leaf or leaf-list node in any data tree returns a set of nodes, all of which are instances of that one schema node. - The type of that schema node is the base type of the leafref. - Once you learn this, it's easy to see, for any particular leaf/leaf-list node and path expression in a module, which schema node is the one. But it's rather hard to describe that process. Actually, there's an ugly question: If the path expression references an element name that doesn't exist in the module. Perhaps there are rules in XPath that prevent it, but it seems to me that you could write leaf mgmt-interface { mandatory false; type leafref { path "../interface/name"; require-instance true; } } when the current module doesn't have a "name" child defined for "interface". As long as a data tree didn't contain a mgmt-interface elememt, the constraint would not be violated. But a later revision of the module, the "name" child could be added, allowing data trees to contain mgmt-interface elements, because data trees could now have "name" elements. The point being that when you're figuring out which schema node is the base type for the leafref, that schema node has to exist so the base type can be extracted. But there's no direct statement of that as a requirement for path validity. Dale From nobody Tue Jun 7 08:51:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E97512D0BE for ; Tue, 7 Jun 2016 08:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 amL_yp_pdpdO for ; Tue, 7 Jun 2016 08:51:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559C012D791 for ; Tue, 7 Jun 2016 08:51:07 -0700 (PDT) Received: from [192.168.43.183] (cst-prg-252-8.cust.vodafone.cz [46.135.252.8]) by mail.nic.cz (Postfix) with ESMTPSA id A058B607F5; Tue, 7 Jun 2016 17:50:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465314665; bh=j60067lUlK3OamTx4IJ1EBh3hYH1j1h1nBaWHC5sVAQ=; h=From:Date:To; b=S2Czd+a8lTUUjvYINBNVDBif5tEDs22j5qrGedhbZHwd0NpF1KtAnMP2phXMrSPI9 VOcfTV7HuYVJ58vZWJRar9rmL2SMI5o/SYsTtNmijKNPHwUCLG9sCXdoDgQFAck5xI 5vatcxTa6LnCLTRQluon9jgdl78Wu3FrHvgIsNVU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <87ziqx81h0.fsf@hobgoblin.ariadne.com> Date: Tue, 7 Jun 2016 17:49:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4640C627-FD4A-48C3-83CE-5398DAD43B16@nic.cz> References: <87ziqx81h0.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 15:51:09 -0000 > On 07 Jun 2016, at 17:26, Dale R. Worley wrote: >=20 > Ladislav Lhotka writes: >> "Dale R. Worley" writes: >>> A difficulty I have with the current wording is that it doesn't = point >>> out the crucial fact about leafref that the XPath expression can = only >>> select elements that are instantiations of one particular data node. = I >>> don't know XPath, but it seems that that is not a general property = of >>> XPath expressions, you seem to be able to write XPath expressions = that >>> select heterogenous groups of elements. So it's worth pointing out = that >>> the allowed XPath expressions can't do that, and that is because of = the >>> restriction that the expression must match path-arg. >>=20 >> Right, this is the slightly hand-waving part that I also objected to. = An >> XPath expression in a leafref's "path" statement indeed selects a = node >> set from an instance data tree. The node seet can be empty, but if it = is >> non-empty, all its members necessarily have the same type, which is >> defined in a certain "leaf" schema node. >>=20 >> The relationship is relatively straightforward but difficult to = explain >> concisely. One basically has to follow the steps in the XPath >> expression, ignore all path-predicates, and skip all schema nodes = that >> aren't data nodes (i.e., "choice" and "case" nodes). >=20 > Yes, it's difficult to explain, though once one gets the idea, it's > straightforward enough. The problem I have is that it's not pointed = out > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I = don't > see it there.) >=20 > The crucial points seem to be: >=20 > - The XPath expression is limited by the syntax "path-arg" and the = rules > in 9.9.2. >=20 > - Because of those restrictions, there exists one data node in the > schema such that: evalutating the expression for any leaf or > leaf-list node in any data tree returns a set of nodes, all of which > are instances of that one schema node. >=20 > - The type of that schema node is the base type of the leafref. >=20 > - Once you learn this, it's easy to see, for any particular > leaf/leaf-list node and path expression in a module, which schema = node > is the one. But it's rather hard to describe that process. Yes, this is correct. >=20 > Actually, there's an ugly question: If the path expression references > an element name that doesn't exist in the module. Perhaps there are > rules in XPath that prevent it, but it seems to me that you could = write Actually, no, such an XPath is perfectly okay, it will just evaluate to = an empty node set, exactly as if the schema node exists but there is no = instance in the data tree - XPath just doesn't care about schemas. >=20 > leaf mgmt-interface { > mandatory false; > type leafref { > path "../interface/name"; > require-instance true; > } > } >=20 > when the current module doesn't have a "name" child defined for > "interface". As long as a data tree didn't contain a mgmt-interface > elememt, the constraint would not be violated. Hmm, I think you are right. Practically speaking, I would expect all = YANG module compilers to complain about nonexistent schema node, but it = follows neither from the old nor the new text. >=20 > But a later revision of the module, the "name" child could be added, > allowing data trees to contain mgmt-interface elements, because data > trees could now have "name" elements. >=20 > The point being that when you're figuring out which schema node is the > base type for the leafref, that schema node has to exist so the base > type can be extracted. But there's no direct statement of that as a > requirement for path validity. I guess a honest way out of this problem would be to describe how to get = the corresponding schema node from the path expression, and state that = it must always exist. This can't be done in one line or two though. Lada > Dale -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 7 08:53:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BBD12D791 for ; Tue, 7 Jun 2016 08:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 EGW3IxYfOFVx for ; Tue, 7 Jun 2016 08:53:04 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B24512D79E for ; Tue, 7 Jun 2016 08:53:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 09B82940; Tue, 7 Jun 2016 17:53:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ep4yLmv9GhCA; Tue, 7 Jun 2016 17:52:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 7 Jun 2016 17:53:01 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5741A2004E; Tue, 7 Jun 2016 17:53:01 +0200 (CEST) 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 Df-QmbDapLIQ; Tue, 7 Jun 2016 17:53:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1A1520047; Tue, 7 Jun 2016 17:52:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A3B153B0B2DE; Tue, 7 Jun 2016 17:52:58 +0200 (CEST) Date: Tue, 7 Jun 2016 17:52:58 +0200 From: Juergen Schoenwaelder To: "Dale R. Worley" Message-ID: <20160607155258.GA9796@elstar.local> Mail-Followup-To: "Dale R. Worley" , Ladislav Lhotka , netmod@ietf.org References: <87ziqx81h0.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ziqx81h0.fsf@hobgoblin.ariadne.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 15:53:10 -0000 On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: > Ladislav Lhotka writes: > > "Dale R. Worley" writes: > >> A difficulty I have with the current wording is that it doesn't point > >> out the crucial fact about leafref that the XPath expression can only > >> select elements that are instantiations of one particular data node. I > >> don't know XPath, but it seems that that is not a general property of > >> XPath expressions, you seem to be able to write XPath expressions that > >> select heterogenous groups of elements. So it's worth pointing out that > >> the allowed XPath expressions can't do that, and that is because of the > >> restriction that the expression must match path-arg. > > > > Right, this is the slightly hand-waving part that I also objected to. An > > XPath expression in a leafref's "path" statement indeed selects a node > > set from an instance data tree. The node seet can be empty, but if it is > > non-empty, all its members necessarily have the same type, which is > > defined in a certain "leaf" schema node. > > > > The relationship is relatively straightforward but difficult to explain > > concisely. One basically has to follow the steps in the XPath > > expression, ignore all path-predicates, and skip all schema nodes that > > aren't data nodes (i.e., "choice" and "case" nodes). > > Yes, it's difficult to explain, though once one gets the idea, it's > straightforward enough. The problem I have is that it's not pointed out > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I don't > see it there.) > > The crucial points seem to be: > > - The XPath expression is limited by the syntax "path-arg" and the rules > in 9.9.2. > > - Because of those restrictions, there exists one data node in the > schema such that: evalutating the expression for any leaf or > leaf-list node in any data tree returns a set of nodes, all of which > are instances of that one schema node. > > - The type of that schema node is the base type of the leafref. > > - Once you learn this, it's easy to see, for any particular > leaf/leaf-list node and path expression in a module, which schema node > is the one. But it's rather hard to describe that process. > > Actually, there's an ugly question: If the path expression references > an element name that doesn't exist in the module. Perhaps there are > rules in XPath that prevent it, but it seems to me that you could write > > leaf mgmt-interface { > mandatory false; > type leafref { > path "../interface/name"; > require-instance true; > } > } > > when the current module doesn't have a "name" child defined for > "interface". As long as a data tree didn't contain a mgmt-interface > elememt, the constraint would not be violated. > > But a later revision of the module, the "name" child could be added, > allowing data trees to contain mgmt-interface elements, because data > trees could now have "name" elements. > > The point being that when you're figuring out which schema node is the > base type for the leafref, that schema node has to exist so the base > type can be extracted. But there's no direct statement of that as a > requirement for path validity. > As WG chair, I am getting a bit nervous. We have to wrap things up and we need deliver the specification - it is past WG last call, it is past IETF last call, it is past IESG approval (kind of). We can likely endlessly continue to search for possible ways to misunderstand the specification but lets remember the aphorism 'perfect is the enemy of good'. I leave it to Martin's discretion to decide whether he wants to add 'The referred leaf or leaf-list node in the schema tree MUST exist.' to the new text but I think the time has come to stop searching for new possible ways to misunderstand the specification. I like to see all issues closed by the end of the week a new revision with all changes posted. People can then check the edits to be sure nothing broke and then the document should move via Benoit into the RFC editor queue by the end of the following week or Monday June 20th. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 7 09:09:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FCD12D0BE for ; Tue, 7 Jun 2016 09:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAl20OXbTwVw for ; Tue, 7 Jun 2016 09:08:57 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 6A39912D095 for ; Tue, 7 Jun 2016 09:08:57 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id h19so174325997ywc.0 for ; Tue, 07 Jun 2016 09:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=CSSpbUqUKefjmJeEr6z7N4rEt9Htf+1fwYviKNqdRiY=; b=uz7C4YSBV9EXGDTPDgPem9AKRsdpsuibobYdOs/UOdG3nf8ThofaiV40ru2Z7oiWWk iUoJr3RiWnrL+XibShzJIslt1uGinXk1QoxSaU26pHfhRjWx0b+wBObdIJRXEqxSJsZC LNJWeT2B7x6uDjo+N2hCAAA4EVdPuNph68FQ5SBbhtwqCU2Muo9oVJzyXcIgk41XhMDZ K8Vl8O/tZTgyzqMSPowj7rJO8AAj5aT/aiWIJEHdWU7/tpLr9OiMETxs26LuOOiItAQD o2reEHqeGOQD3qYKoCN54hdGJs6gpaQIV2fRsFIxArRDkGNUdKFCDB8uTqXpyfDsKyCS u68Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=CSSpbUqUKefjmJeEr6z7N4rEt9Htf+1fwYviKNqdRiY=; b=FMSt8Lk8C2s48rjSoJYaMZZep55PAYtE8suZRAYt/KAWrqrAK54lgo8TMFwpqTQ+SE tmilMMbqQkCPy5GL2Og1lk70khud0kp3TcNIkrcCS8g221RiObTWihUU8bRloiuYpnDy gws9pqAtllDwrz+TiOz1OCvDjXFD96JaXRVrUoR2FaMxvjLm8EZP2KedLc6ukfPx2Xbk Kta3dWF633yZGEhoT3eNYW5sNX/zcCNFCzy1VVC0HWPIsrNLM4SofsKdnzITCJ1kdLnv 69krBBoIuQQPzNxR1M3mebwFLUTEBnuDeblZdVf2CvExqxTPh3FeLyAdH/GZvBwVI36E Ar7g== X-Gm-Message-State: ALyK8tILlI2xEoGGeF/rtLI0BXPaup+xD1BIwNqNyuofnpq70Rl9mAVinuGYGfZoi+TxNTrFs4A/wWqde8xrlQ== MIME-Version: 1.0 X-Received: by 10.37.4.200 with SMTP id 191mr108971ybe.17.1465315736452; Tue, 07 Jun 2016 09:08:56 -0700 (PDT) Received: by 10.37.115.68 with HTTP; Tue, 7 Jun 2016 09:08:56 -0700 (PDT) In-Reply-To: <20160607155258.GA9796@elstar.local> References: <87ziqx81h0.fsf@hobgoblin.ariadne.com> <20160607155258.GA9796@elstar.local> Date: Tue, 7 Jun 2016 09:08:56 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Dale R. Worley" , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c01202f4c1cf0534b26795 Archived-At: Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 16:08:59 -0000 --001a11c01202f4c1cf0534b26795 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: > > Ladislav Lhotka writes: > > > "Dale R. Worley" writes: > > >> A difficulty I have with the current wording is that it doesn't point > > >> out the crucial fact about leafref that the XPath expression can only > > >> select elements that are instantiations of one particular data node. > I > > >> don't know XPath, but it seems that that is not a general property of > > >> XPath expressions, you seem to be able to write XPath expressions that > > >> select heterogenous groups of elements. So it's worth pointing out > that > > >> the allowed XPath expressions can't do that, and that is because of > the > > >> restriction that the expression must match path-arg. > > > > > > Right, this is the slightly hand-waving part that I also objected to. > An > > > XPath expression in a leafref's "path" statement indeed selects a node > > > set from an instance data tree. The node seet can be empty, but if it > is > > > non-empty, all its members necessarily have the same type, which is > > > defined in a certain "leaf" schema node. > > > > > > The relationship is relatively straightforward but difficult to explain > > > concisely. One basically has to follow the steps in the XPath > > > expression, ignore all path-predicates, and skip all schema nodes that > > > aren't data nodes (i.e., "choice" and "case" nodes). > > > > Yes, it's difficult to explain, though once one gets the idea, it's > > straightforward enough. The problem I have is that it's not pointed out > > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I don't > > see it there.) > > > > The crucial points seem to be: > > > > - The XPath expression is limited by the syntax "path-arg" and the rules > > in 9.9.2. > > > > - Because of those restrictions, there exists one data node in the > > schema such that: evalutating the expression for any leaf or > > leaf-list node in any data tree returns a set of nodes, all of which > > are instances of that one schema node. > > > > - The type of that schema node is the base type of the leafref. > > > > - Once you learn this, it's easy to see, for any particular > > leaf/leaf-list node and path expression in a module, which schema node > > is the one. But it's rather hard to describe that process. > > > > Actually, there's an ugly question: If the path expression references > > an element name that doesn't exist in the module. Perhaps there are > > rules in XPath that prevent it, but it seems to me that you could write > > > > leaf mgmt-interface { > > mandatory false; > > type leafref { > > path "../interface/name"; > > require-instance true; > > } > > } > > > > when the current module doesn't have a "name" child defined for > > "interface". As long as a data tree didn't contain a mgmt-interface > > elememt, the constraint would not be violated. > > > > But a later revision of the module, the "name" child could be added, > > allowing data trees to contain mgmt-interface elements, because data > > trees could now have "name" elements. > > > > The point being that when you're figuring out which schema node is the > > base type for the leafref, that schema node has to exist so the base > > type can be extracted. But there's no direct statement of that as a > > requirement for path validity. > > > > As WG chair, I am getting a bit nervous. We have to wrap things up and > we need deliver the specification - it is past WG last call, it is > past IETF last call, it is past IESG approval (kind of). We can likely > endlessly continue to search for possible ways to misunderstand the > specification but lets remember the aphorism 'perfect is the enemy of > good'. > > I leave it to Martin's discretion to decide whether he wants to add > 'The referred leaf or leaf-list node in the schema tree MUST exist.' > to the new text but I think the time has come to stop searching for > new possible ways to misunderstand the specification. > > Doesn't the text above exclude a default leaf or leaf-list from the value space? That would be incorrect. I like to see all issues closed by the end of the week a new revision > with all changes posted. People can then check the edits to be sure > nothing broke and then the document should move via Benoit into the > RFC editor queue by the end of the following week or Monday June 20th. > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c01202f4c1cf0534b26795 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Wor= ley wrote:
> Ladislav Lhotka <lhotka@nic.cz= > writes:
> > "Dale R. Worley" <worley@ariadne.com> writes:
> >> A difficulty I have with the current wording is that it doesn= 't point
> >> out the crucial fact about leafref that the XPath expression = can only
> >> select elements that are instantiations of one particular dat= a node.=C2=A0 I
> >> don't know XPath, but it seems that that is not a general= property of
> >> XPath expressions, you seem to be able to write XPath express= ions that
> >> select heterogenous groups of elements.=C2=A0 So it's wor= th pointing out that
> >> the allowed XPath expressions can't do that, and that is = because of the
> >> restriction that the expression must match path-arg.
> >
> > Right, this is the slightly hand-waving part that I also objected= to. An
> > XPath expression in a leafref's "path" statement in= deed selects a node
> > set from an instance data tree. The node seet can be empty, but i= f it is
> > non-empty, all its members necessarily have the same type, which = is
> > defined in a certain "leaf" schema node.
> >
> > The relationship is relatively straightforward but difficult to e= xplain
> > concisely. One basically has to follow the steps in the XPath
> > expression, ignore all path-predicates, and skip all schema nodes= that
> > aren't data nodes (i.e., "choice" and "case&qu= ot; nodes).
>
> Yes, it's difficult to explain, though once one gets the idea, it&= #39;s
> straightforward enough.=C2=A0 The problem I have is that it's not = pointed out
> explicitly anywhere.=C2=A0 (E.g., Juergen suggests section 9.9.2, but = I don't
> see it there.)
>
> The crucial points seem to be:
>
> - The XPath expression is limited by the syntax "path-arg" a= nd the rules
>=C2=A0 =C2=A0in 9.9.2.
>
> - Because of those restrictions, there exists one data node in the
>=C2=A0 =C2=A0schema such that:=C2=A0 evalutating the expression for any= leaf or
>=C2=A0 =C2=A0leaf-list node in any data tree returns a set of nodes, al= l of which
>=C2=A0 =C2=A0are instances of that one schema node.
>
> - The type of that schema node is the base type of the leafref.
>
> - Once you learn this, it's easy to see, for any particular
>=C2=A0 =C2=A0leaf/leaf-list node and path expression in a module, which= schema node
>=C2=A0 =C2=A0is the one.=C2=A0 But it's rather hard to describe tha= t process.
>
> Actually, there's an ugly question:=C2=A0 If the path expression r= eferences
> an element name that doesn't exist in the module.=C2=A0 Perhaps th= ere are
> rules in XPath that prevent it, but it seems to me that you could writ= e
>
>=C2=A0 =C2=A0 =C2=A0 leaf mgmt-interface {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory false;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path "../interface/name";<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 require-instance true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 }
>
> when the current module doesn't have a "name" child defi= ned for
> "interface".=C2=A0 As long as a data tree didn't contain= a mgmt-interface
> elememt, the constraint would not be violated.
>
> But a later revision of the module, the "name" child could b= e added,
> allowing data trees to contain mgmt-interface elements, because data > trees could now have "name" elements.
>
> The point being that when you're figuring out which schema node is= the
> base type for the leafref, that schema node has to exist so the base > type can be extracted.=C2=A0 But there's no direct statement of th= at as a
> requirement for path validity.
>

As WG chair, I am getting a bit nervous. We have to wrap things up and
we need deliver the specification - it is past WG last call, it is
past IETF last call, it is past IESG approval (kind of). We can likely
endlessly continue to search for possible ways to misunderstand the
specification but lets remember the aphorism 'perfect is the enemy of good'.

I leave it to Martin's discretion to decide whether he wants to add
'The referred leaf or leaf-list node in the schema tree MUST exist.'= ;
to the new text but I think the time has come to stop searching for
new possible ways to misunderstand the specification.



Doesn't the text ab= ove exclude a default leaf or leaf-list from the
value space?=C2= =A0 That would be incorrect.
=C2=A0

I like to see all issues closed by the end of the week a new revision
with all changes posted. People can then check the edits to be sure
nothing broke and then the document should move via Benoit into the
RFC editor queue by the end of the following week or Monday June 20th.

/js


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

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

--001a11c01202f4c1cf0534b26795-- From nobody Tue Jun 7 09:23:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B103B12D7B4 for ; Tue, 7 Jun 2016 09:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 hlXhjeo5yL0n for ; Tue, 7 Jun 2016 09:23:45 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 28D0312D7B1 for ; Tue, 7 Jun 2016 09:23:44 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id c127so174585475ywb.1 for ; Tue, 07 Jun 2016 09:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GsL9ONHvDkPZ1f+bPrk9GfGrXw/vVrC/PXirvnr/opQ=; b=mmVUWPH1fZYvKi066kpPjizb60YiEYvSFRQZzfV3rEg6Hqvaic5sAVunTDKmntWAHT qAroiCZmcI4V7RpXt8zADSK9XwjvkYfKmOzZSmIcvCcxGOhPHSEi0y+Gb/0ZLhPPhcoM 63HAs/VnyQJJLdZh3zkRGIZtkxYGJuI5LCIQpM/fVF7U51fKOq/M2NdbKVFgFaSyWUdW Ya2rsvIQKiwCSmQzfBIcBCX2TLVOQpFBwYpGyDMNIAc5reY+2nYToZH/7PDdkWOZ7RrT EqfuF4XbyIY/uP1JoE6iJSvT2w9Od8gmBsssGgYuJ3WFJm57CbXB82SRvtKlc21p5wBs Ws0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GsL9ONHvDkPZ1f+bPrk9GfGrXw/vVrC/PXirvnr/opQ=; b=fURpVmFOdxJ0TDm3LAgqLiITmr069huPg2++3cGEa2Hqn+Mr+nR9B2d8yIIIlaVDpW lNTvUr/ZyHcQpVGXAH+Ycp8lE6w1iiR/yWzAOIcNNUdICl7ehW2AbYWIC6hMisyqGhQq E1OkU7fbCXgj3T/7Oq3jR5wEp+m/Ja0Ipa0eIyC9jaWLu1UVGqEncwJwTIRmZxfw5FPv YcVeQH305MZqr1k5Afb2Sy3Psj9ZXYBfca9c9TZsMSLzY/Mkj+ugxdsGEvVBwaGi6A15 z+S7Qws03fCIvtxIp3kWo5pvERshmefP5rRlQ1uhq/x4XOEKNG5DVElpIV6pngukm89u 6yBg== X-Gm-Message-State: ALyK8tJcfE6XkDv/jUuLkv+EXseh1jI3hzX4PcitvEwmJ6kFQ8vEZ8/W7gnMfMYb1coRkxNSZikgIUppne7FXw== MIME-Version: 1.0 X-Received: by 10.37.80.131 with SMTP id e125mr160191ybb.162.1465316623379; Tue, 07 Jun 2016 09:23:43 -0700 (PDT) Received: by 10.37.115.68 with HTTP; Tue, 7 Jun 2016 09:23:43 -0700 (PDT) In-Reply-To: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> Date: Tue, 7 Jun 2016 09:23:43 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a1145c908d224270534b29ceb Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 16:23:48 -0000 --001a1145c908d224270534b29ceb Content-Type: text/plain; charset=UTF-8 Hi, I prefer (B). I do not think it is realistic that vendors will rewrite their IETF modules and vendor modules and all the associated client/server instrumentation. This is expensive at many levels. Stability is important for an API. So if we do (A), there will be some modules following the convention and the rest using proprietary RPC-based solutions. But if we do (B), vendors can integrate the standard RPC-based solution into their existing running code with zero disturbance. Andy On Tue, Jun 7, 2016 at 7:19 AM, Lou Berger wrote: > All, > > We want to provide an update based on the off line discussions > related to OpState Solutions that we have been having and solicit > input from the WG. > > All authors of current solution drafts [1,2,3] together with those > who helped conduct the solutions analysis* were invited to the these > discussions -- with the objective of coming up with a single > consolidated proposal to bring to the WG. (I/Lou acted as facilitator > as Kent and Juergen were and are involved with the technical details.) > > The discussions have yielded some results but, unfortunately, > not a single consolidated proposal as hoped, but rather two > alternate directions -- and clearly we need to choose one: > > 1) Adopt the conventions for representing state/config > based on Section 6 of [1]. > > From a model definition perspective, these conventions > impact every model and every model writer. > > 2) Model OpState using a revised logical datastore definition > as introduced in [4] and also covered in [5]. There is > also a variant of this that we believe doesn't significantly > impact this choice. > > With this approach, model definitions need no explicit > changes to support applied configuration. > > >From a technology/WG standpoint, we believe an approach > that doesn't impact every model written (i.e., #2) is superior. > The counterpoint to this is that the conventions based > approach (i.e., #1) is available today and being followed in > OpenConfig defined models. > > We would like to hear opinions on this from the WG before > declaring one of the following as the WG direction: > > A) models that wish to support applied configuration MUST > follow conventions based on [1] -- and the WG needs to > formalize these conventions. > or > B) no explicit support is required for models to support > applied configuration -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. > > We intend to close on this choice before Berlin. > > Thank you, > Lou (and co-chairs) > > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > * - Chris H. and Acee L. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1145c908d224270534b29ceb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I prefer (B).
I do not th= ink it is realistic that vendors will rewrite their IETF
modules = and vendor modules and all the associated client/server instrumentation.
This is expensive at many levels. Stability is important for an API= .

So if we do (A), there will be some modules foll= owing the convention
and the rest using proprietary RPC-based sol= utions.
But if we do (B), vendors can integrate the standard RPC-= based solution
into their existing running code with zero disturb= ance.


Andy



= On Tue, Jun 7, 2016 at 7:19 AM, Lou Berger <lberger@labn.net>= wrote:
All,

We want to provide an update based on the off line discussions
related to OpState Solutions that we have been having and solicit
input from the WG.

All authors of current solution drafts [1,2,3] together with those
who helped conduct the solutions analysis* were invited to the these
discussions -- with the objective of coming up with a single
consolidated proposal to bring to the WG. (I/Lou acted as facilitator
as Kent and Juergen were and are involved with the technical details.)

The discussions have yielded some results but, unfortunately,
not a single consolidated proposal as hoped, but rather two
alternate directions -- and clearly we need to choose one:

=C2=A0 =C2=A0 1) Adopt the conventions for representing state/config
=C2=A0 =C2=A0 =C2=A0 =C2=A0based on Section 6 of [1].

=C2=A0 =C2=A0 =C2=A0 =C2=A0From a model definition perspective, these conve= ntions
=C2=A0 =C2=A0 =C2=A0 =C2=A0impact every model and every model writer.

=C2=A0 =C2=A0 2) Model OpState using a revised logical datastore definition=
=C2=A0 =C2=A0 =C2=A0 =C2=A0as introduced in [4] and also covered in [5]. Th= ere is
=C2=A0 =C2=A0 =C2=A0 =C2=A0also a variant of this that we believe doesn'= ;t significantly
=C2=A0 =C2=A0 =C2=A0 =C2=A0impact this choice.

=C2=A0 =C2=A0 =C2=A0 =C2=A0With this approach, model definitions need no ex= plicit
=C2=A0 =C2=A0 =C2=A0 =C2=A0changes to support applied configuration.

>From a technology/WG standpoint, we believe an approach
that doesn't impact every model written (i.e., #2) is superior.
The counterpoint to this is that the conventions based
approach (i.e., #1) is available today and being followed in
OpenConfig defined models.

We would like to hear opinions on this from the WG before
declaring one of the following as the WG direction:

=C2=A0 =C2=A0 A) models that wish to support applied configuration MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0follow conventions based on [1] -- and the WG ne= eds to
=C2=A0 =C2=A0 =C2=A0 =C2=A0formalize these conventions.
or
=C2=A0 =C2=A0 B) no explicit support is required for models to support
=C2=A0 =C2=A0 =C2=A0 =C2=A0applied configuration -- and that the WG needs t= o
=C2=A0 =C2=A0 =C2=A0 =C2=A0formalize an opstate solution based on the appro= ach
=C2=A0 =C2=A0 =C2=A0 =C2=A0discussed in [4] and [5].

We intend to close on this choice before Berlin.

Thank you,
Lou (and co-chairs)

[1] https://tools.ietf.org/html/draft-= openconfig-netmod-opstate-01
[2] https://tools.ietf.org/html/draft-kwa= tsen-netmod-opstate-02
[3] https://tools.ietf.org/html/draft= -wilton-netmod-opstate-yang-02
[4] https://tools.ietf.org/htm= l/draft-schoenw-netmod-revised-datastores-00
[5] https://tools.ietf.org/html= /draft-wilton-netmod-refined-datastores-00
* - Chris H. and Acee L.


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

--001a1145c908d224270534b29ceb-- From nobody Tue Jun 7 09:38:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE4E12D7C8 for ; Tue, 7 Jun 2016 09:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 seKkQNMOI3po for ; Tue, 7 Jun 2016 09:38:39 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4EE12D7C3 for ; Tue, 7 Jun 2016 09:38:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1974573D; Tue, 7 Jun 2016 18:38:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id IIfEZAUlpueg; Tue, 7 Jun 2016 18:38:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 7 Jun 2016 18:38:36 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F81D20054; Tue, 7 Jun 2016 18:38:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id r0Kbomt-NbMk; Tue, 7 Jun 2016 18:38:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AEF9320047; Tue, 7 Jun 2016 18:38:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8141A3B0B51C; Tue, 7 Jun 2016 18:38:32 +0200 (CEST) Date: Tue, 7 Jun 2016 18:38:31 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160607163831.GB9870@elstar.local> Mail-Followup-To: Andy Bierman , "Dale R. Worley" , Ladislav Lhotka , "netmod@ietf.org" References: <87ziqx81h0.fsf@hobgoblin.ariadne.com> <20160607155258.GA9796@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: "netmod@ietf.org" Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 16:38:56 -0000 On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierman wrote: > On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: > > > Ladislav Lhotka writes: > > > > "Dale R. Worley" writes: > > > >> A difficulty I have with the current wording is that it doesn't point > > > >> out the crucial fact about leafref that the XPath expression can only > > > >> select elements that are instantiations of one particular data node. > > I > > > >> don't know XPath, but it seems that that is not a general property of > > > >> XPath expressions, you seem to be able to write XPath expressions that > > > >> select heterogenous groups of elements. So it's worth pointing out > > that > > > >> the allowed XPath expressions can't do that, and that is because of > > the > > > >> restriction that the expression must match path-arg. > > > > > > > > Right, this is the slightly hand-waving part that I also objected to. > > An > > > > XPath expression in a leafref's "path" statement indeed selects a node > > > > set from an instance data tree. The node seet can be empty, but if it > > is > > > > non-empty, all its members necessarily have the same type, which is > > > > defined in a certain "leaf" schema node. > > > > > > > > The relationship is relatively straightforward but difficult to explain > > > > concisely. One basically has to follow the steps in the XPath > > > > expression, ignore all path-predicates, and skip all schema nodes that > > > > aren't data nodes (i.e., "choice" and "case" nodes). > > > > > > Yes, it's difficult to explain, though once one gets the idea, it's > > > straightforward enough. The problem I have is that it's not pointed out > > > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I don't > > > see it there.) > > > > > > The crucial points seem to be: > > > > > > - The XPath expression is limited by the syntax "path-arg" and the rules > > > in 9.9.2. > > > > > > - Because of those restrictions, there exists one data node in the > > > schema such that: evalutating the expression for any leaf or > > > leaf-list node in any data tree returns a set of nodes, all of which > > > are instances of that one schema node. > > > > > > - The type of that schema node is the base type of the leafref. > > > > > > - Once you learn this, it's easy to see, for any particular > > > leaf/leaf-list node and path expression in a module, which schema node > > > is the one. But it's rather hard to describe that process. > > > > > > Actually, there's an ugly question: If the path expression references > > > an element name that doesn't exist in the module. Perhaps there are > > > rules in XPath that prevent it, but it seems to me that you could write > > > > > > leaf mgmt-interface { > > > mandatory false; > > > type leafref { > > > path "../interface/name"; > > > require-instance true; > > > } > > > } > > > > > > when the current module doesn't have a "name" child defined for > > > "interface". As long as a data tree didn't contain a mgmt-interface > > > elememt, the constraint would not be violated. > > > > > > But a later revision of the module, the "name" child could be added, > > > allowing data trees to contain mgmt-interface elements, because data > > > trees could now have "name" elements. > > > > > > The point being that when you're figuring out which schema node is the > > > base type for the leafref, that schema node has to exist so the base > > > type can be extracted. But there's no direct statement of that as a > > > requirement for path validity. > > > > > > > As WG chair, I am getting a bit nervous. We have to wrap things up and > > we need deliver the specification - it is past WG last call, it is > > past IETF last call, it is past IESG approval (kind of). We can likely > > endlessly continue to search for possible ways to misunderstand the > > specification but lets remember the aphorism 'perfect is the enemy of > > good'. > > > > I leave it to Martin's discretion to decide whether he wants to add > > 'The referred leaf or leaf-list node in the schema tree MUST exist.' > > to the new text but I think the time has come to stop searching for > > new possible ways to misunderstand the specification. > > > > > > Doesn't the text above exclude a default leaf or leaf-list from the > value space? That would be incorrect. > It says 'in the schema tree' so I think there is no problem. We were discussing the corner case where the path argument does not point to a schema node at all. Pyang already reports this as an error (bar in the path of foo [...] is not found). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 7 09:45:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B33C12D7CB for ; Tue, 7 Jun 2016 09:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xntcJMCi7LZU for ; Tue, 7 Jun 2016 09:45:37 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 0B56A12D1CB for ; Tue, 7 Jun 2016 09:45:37 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id o16so175388703ywd.2 for ; Tue, 07 Jun 2016 09:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=CUmDcLsIHPfqDw2rhcF3aEb6BHJopxwbLXVs8FV3p6Q=; b=O1+bRj1yJci+Z8gJ0vdOoNcJO3NaRzUe0fzAdiAA/Gx9JfimELARvi2hWaFeL+t940 RLwYnZ+/iDfVXkxMIV3Ds8xx0drKUE27zZmbpLvnQYUVLafr5V/bEUXdLdD56NLO4/du gvkRiTsLfL9uasKIT/tFACXMXjiUGFjHl6FyBVKK18y3EJyY4z6LOiljTPuVazWlKvqb os+FXZip9s9rC6wVwaAJu7nf1HFAXO5av5MESmtGwGGBOEp76Nhthfg3D3bTTB8Z32tv WOQaYSJp8PjzBaoSFdFu0xn1s19Bk/KP9gWgn5IQEfQ1tzAHn6KDBEcZRNzc5Dk5+G8O hCmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=CUmDcLsIHPfqDw2rhcF3aEb6BHJopxwbLXVs8FV3p6Q=; b=GoxGxDliC+EpzEVoQ9sE+g+KnvbLf6m7MV6/mmk0Je8R6DasssJCIDhY4wJEPvAPxI fQba+IXy7liRGYzdA0frxHys8pyoXlszPnnYhU9UCTMGxWcHKRSLvuTIpIJRrEBGxv0w /n+0/lmolH4JhYG4sGcOjuoIeHvv3Gwq4GXGUR4OC7oOe8CgAE7ApfaHM79KX//2Pa9r xei4DgbDv1VZr73BKqpg90LG6O7xdkp1VY4SHM7hCumv9d1WIBcpF7/LxtJYn9FMbb8V y7p7L789XKu1Ffi+za0g6LsMf6twccEZhFIsYZtxuH4U17/jDcyll1baerr468FuivpN eywA== X-Gm-Message-State: ALyK8tLW6sXJNdDPzIXyw1qmhoF7s095q6RbtDX2ZTBIwwKst7d/nu6UFFdpcjrkBmkKpWs9r9G7GLfTNGyAyQ== MIME-Version: 1.0 X-Received: by 10.37.125.65 with SMTP id y62mr228833ybc.168.1465317936246; Tue, 07 Jun 2016 09:45:36 -0700 (PDT) Received: by 10.37.115.68 with HTTP; Tue, 7 Jun 2016 09:45:36 -0700 (PDT) In-Reply-To: <20160607163831.GB9870@elstar.local> References: <87ziqx81h0.fsf@hobgoblin.ariadne.com> <20160607155258.GA9796@elstar.local> <20160607163831.GB9870@elstar.local> Date: Tue, 7 Jun 2016 09:45:36 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Dale R. Worley" , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114e5ca212ec440534b2eb59 Archived-At: Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 16:45:40 -0000 --001a114e5ca212ec440534b2eb59 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierman wrote: > > On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: > > > > Ladislav Lhotka writes: > > > > > "Dale R. Worley" writes: > > > > >> A difficulty I have with the current wording is that it doesn't > point > > > > >> out the crucial fact about leafref that the XPath expression can > only > > > > >> select elements that are instantiations of one particular data > node. > > > I > > > > >> don't know XPath, but it seems that that is not a general > property of > > > > >> XPath expressions, you seem to be able to write XPath expressions > that > > > > >> select heterogenous groups of elements. So it's worth pointing > out > > > that > > > > >> the allowed XPath expressions can't do that, and that is because > of > > > the > > > > >> restriction that the expression must match path-arg. > > > > > > > > > > Right, this is the slightly hand-waving part that I also objected > to. > > > An > > > > > XPath expression in a leafref's "path" statement indeed selects a > node > > > > > set from an instance data tree. The node seet can be empty, but if > it > > > is > > > > > non-empty, all its members necessarily have the same type, which is > > > > > defined in a certain "leaf" schema node. > > > > > > > > > > The relationship is relatively straightforward but difficult to > explain > > > > > concisely. One basically has to follow the steps in the XPath > > > > > expression, ignore all path-predicates, and skip all schema nodes > that > > > > > aren't data nodes (i.e., "choice" and "case" nodes). > > > > > > > > Yes, it's difficult to explain, though once one gets the idea, it's > > > > straightforward enough. The problem I have is that it's not pointed > out > > > > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I > don't > > > > see it there.) > > > > > > > > The crucial points seem to be: > > > > > > > > - The XPath expression is limited by the syntax "path-arg" and the > rules > > > > in 9.9.2. > > > > > > > > - Because of those restrictions, there exists one data node in the > > > > schema such that: evalutating the expression for any leaf or > > > > leaf-list node in any data tree returns a set of nodes, all of > which > > > > are instances of that one schema node. > > > > > > > > - The type of that schema node is the base type of the leafref. > > > > > > > > - Once you learn this, it's easy to see, for any particular > > > > leaf/leaf-list node and path expression in a module, which schema > node > > > > is the one. But it's rather hard to describe that process. > > > > > > > > Actually, there's an ugly question: If the path expression > references > > > > an element name that doesn't exist in the module. Perhaps there are > > > > rules in XPath that prevent it, but it seems to me that you could > write > > > > > > > > leaf mgmt-interface { > > > > mandatory false; > > > > type leafref { > > > > path "../interface/name"; > > > > require-instance true; > > > > } > > > > } > > > > > > > > when the current module doesn't have a "name" child defined for > > > > "interface". As long as a data tree didn't contain a mgmt-interface > > > > elememt, the constraint would not be violated. > > > > > > > > But a later revision of the module, the "name" child could be added, > > > > allowing data trees to contain mgmt-interface elements, because data > > > > trees could now have "name" elements. > > > > > > > > The point being that when you're figuring out which schema node is > the > > > > base type for the leafref, that schema node has to exist so the base > > > > type can be extracted. But there's no direct statement of that as a > > > > requirement for path validity. > > > > > > > > > > As WG chair, I am getting a bit nervous. We have to wrap things up and > > > we need deliver the specification - it is past WG last call, it is > > > past IETF last call, it is past IESG approval (kind of). We can likely > > > endlessly continue to search for possible ways to misunderstand the > > > specification but lets remember the aphorism 'perfect is the enemy of > > > good'. > > > > > > I leave it to Martin's discretion to decide whether he wants to add > > > 'The referred leaf or leaf-list node in the schema tree MUST exist.' > > > to the new text but I think the time has come to stop searching for > > > new possible ways to misunderstand the specification. > > > > > > > > > > Doesn't the text above exclude a default leaf or leaf-list from the > > value space? That would be incorrect. > > > > It says 'in the schema tree' so I think there is no problem. We were > discussing the corner case where the path argument does not point to a > schema node at all. Pyang already reports this as an error (bar in the > path of foo [...] is not found). > > I thought the original issue was that the ABNF does not support position-based instance identifiers. In the rare event that the i-i pointed to a config=false list entry (with no keys defined) then its position needs to be used. I thought it was clear that the path-stmt has to point at a schema node that can be resolved in the module context using the import-stmts. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114e5ca212ec440534b2eb59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierma= n wrote:
> On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: > > > Ladislav Lhotka <lhotka@= nic.cz> writes:
> > > > "Dale R. Worley" <worley@ariadne.com> writes:
> > > >> A difficulty I have with the current wording is tha= t it doesn't point
> > > >> out the crucial fact about leafref that the XPath e= xpression can only
> > > >> select elements that are instantiations of one part= icular data node.
> > I
> > > >> don't know XPath, but it seems that that is not= a general property of
> > > >> XPath expressions, you seem to be able to write XPa= th expressions that
> > > >> select heterogenous groups of elements.=C2=A0 So it= 's worth pointing out
> > that
> > > >> the allowed XPath expressions can't do that, an= d that is because of
> > the
> > > >> restriction that the expression must match path-arg= .
> > > >
> > > > Right, this is the slightly hand-waving part that I als= o objected to.
> > An
> > > > XPath expression in a leafref's "path" st= atement indeed selects a node
> > > > set from an instance data tree. The node seet can be em= pty, but if it
> > is
> > > > non-empty, all its members necessarily have the same ty= pe, which is
> > > > defined in a certain "leaf" schema node.
> > > >
> > > > The relationship is relatively straightforward but diff= icult to explain
> > > > concisely. One basically has to follow the steps in the= XPath
> > > > expression, ignore all path-predicates, and skip all sc= hema nodes that
> > > > aren't data nodes (i.e., "choice" and &qu= ot;case" nodes).
> > >
> > > Yes, it's difficult to explain, though once one gets the= idea, it's
> > > straightforward enough.=C2=A0 The problem I have is that it&= #39;s not pointed out
> > > explicitly anywhere.=C2=A0 (E.g., Juergen suggests section 9= .9.2, but I don't
> > > see it there.)
> > >
> > > The crucial points seem to be:
> > >
> > > - The XPath expression is limited by the syntax "path-a= rg" and the rules
> > >=C2=A0 =C2=A0in 9.9.2.
> > >
> > > - Because of those restrictions, there exists one data node = in the
> > >=C2=A0 =C2=A0schema such that:=C2=A0 evalutating the expressi= on for any leaf or
> > >=C2=A0 =C2=A0leaf-list node in any data tree returns a set of= nodes, all of which
> > >=C2=A0 =C2=A0are instances of that one schema node.
> > >
> > > - The type of that schema node is the base type of the leafr= ef.
> > >
> > > - Once you learn this, it's easy to see, for any particu= lar
> > >=C2=A0 =C2=A0leaf/leaf-list node and path expression in a mod= ule, which schema node
> > >=C2=A0 =C2=A0is the one.=C2=A0 But it's rather hard to de= scribe that process.
> > >
> > > Actually, there's an ugly question:=C2=A0 If the path ex= pression references
> > > an element name that doesn't exist in the module.=C2=A0 = Perhaps there are
> > > rules in XPath that prevent it, but it seems to me that you = could write
> > >
> > >=C2=A0 =C2=A0 =C2=A0 leaf mgmt-interface {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 mandatory false;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 type leafref {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path "../interface/na= me";
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 require-instance true;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >
> > > when the current module doesn't have a "name" = child defined for
> > > "interface".=C2=A0 As long as a data tree didn'= ;t contain a mgmt-interface
> > > elememt, the constraint would not be violated.
> > >
> > > But a later revision of the module, the "name" chi= ld could be added,
> > > allowing data trees to contain mgmt-interface elements, beca= use data
> > > trees could now have "name" elements.
> > >
> > > The point being that when you're figuring out which sche= ma node is the
> > > base type for the leafref, that schema node has to exist so = the base
> > > type can be extracted.=C2=A0 But there's no direct state= ment of that as a
> > > requirement for path validity.
> > >
> >
> > As WG chair, I am getting a bit nervous. We have to wrap things u= p and
> > we need deliver the specification - it is past WG last call, it i= s
> > past IETF last call, it is past IESG approval (kind of). We can l= ikely
> > endlessly continue to search for possible ways to misunderstand t= he
> > specification but lets remember the aphorism 'perfect is the = enemy of
> > good'.
> >
> > I leave it to Martin's discretion to decide whether he wants = to add
> > 'The referred leaf or leaf-list node in the schema tree MUST = exist.'
> > to the new text but I think the time has come to stop searching f= or
> > new possible ways to misunderstand the specification.
> >
> >
>
> Doesn't the text above exclude a default leaf or leaf-list from th= e
> value space?=C2=A0 That would be incorrect.
>

It says 'in the schema tree' so I think there is no problem. We wer= e
discussing the corner case where the path argument does not point to a
schema node at all. Pyang already reports this as an error (bar in the
path of foo [...] is not found).


I thought the original issue was that the ABNF does = not support position-based
instance identifiers.=C2=A0 In the rar= e event that the i-i pointed to a config=3Dfalse
list entry (with= no keys defined) then its position needs to be used.

<= div>I thought it was clear that the path-stmt has to point at a schema node=
that can be resolved in the module context using the import-stmt= s.

=C2=A0
/js


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

--001a114e5ca212ec440534b2eb59-- From nobody Tue Jun 7 10:32:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE19D12D5CE; Tue, 7 Jun 2016 10:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.623 X-Spam-Level: X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, UNPARSEABLE_RELAY=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 vvfVHxU65rPp; Tue, 7 Jun 2016 10:32:28 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6F12B00B; Tue, 7 Jun 2016 10:32:28 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u57HUCAc047800; Tue, 7 Jun 2016 13:30:12 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Eliot Lear , netmod WG , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-02.txt Thread-Index: AQHRwOKK2wnUnxhWe02b1IGklYPrnA== Date: Tue, 7 Jun 2016 17:32:18 +0000 Message-ID: References: <20160607082500.13784.77653.idtracker@ietfa.amsl.com> <8ef1edcc-0d56-ea5f-90a9-4a64a025ba41@cisco.com> In-Reply-To: <8ef1edcc-0d56-ea5f-90a9-4a64a025ba41@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-originating-ip: [172.25.177.156] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3548151131_546195" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606070196 Archived-At: Subject: Re: [netmod] [OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 17:32:31 -0000 --B_3548151131_546195 Content-type: multipart/alternative; boundary="B_3548151131_539198" --B_3548151131_539198 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > * We now include a signature mechanism for the MUD files. It was always = the > plan to do this. There were two choices: CMS/PKCS#7 or JWS. Again for > tooling's sake, so that people don't need to roll their own, especially f= or > anything security related, we've gone with CMS and a detached signature a= t > that. Thanks to John Bashinsky and others for their advice on this. Thi= s > area in particular could stand close scrutiny. Wouldn=E2=80=99t CMS still require serialization/canonicalization? Tooling-wise, OpenSSL is indeed prevalent (and seems to do CMS quite well) = =E2=80=93 but JWS tools are around, so you wouldn=E2=80=99t need to roll your own if you decided to go that way. Do I need the ability to tell whether a MUD file was not signed or its signature was deleted? > Comments and edits are very welcome! Have to settle for questions for now. :-) --B_3548151131_539198 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
  • We now include a signature mechanism for the MUD files.&= nbsp; It was always the plan to do this.  There were two choices: CMS/P= KCS#7 or JWS.  Again for tooling's sake, so that people don't need to r= oll their own, especially for anything security related, we've gone with CMS and a detached signature at that.  Thanks to John Bashi= nsky and others for their advice on this.  This area in particular coul= d stand close scrutiny.
Wouldn= ’t CMS still require serialization/canonicalization? 
<= br>
Tooling-wise, OpenSSL is indeed prevalent (and seems to do CMS= quite well) – but  JWS tools are around, so you wouldn’t n= eed to roll your own if you decided to go that way.

Do I need the ability to tell whether a MUD file was not signed or its sign= ature was deleted?  

Comments and edits are very welcome!

Have to settle for questions for now. :-)
<= /body> --B_3548151131_539198-- --B_3548151131_546195 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQwUhioSOpqRLurNjrt6KqtVOjoZmjKqQnkePPz/fi1/zmM7vSRDVxdk2YVgFcEFTzSMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDYwNzE3MzIxMVow DQYJKoZIhvcNAQEBBQAEggEA0C1J8L+EWlZDdGU0nSCqkHrGozYUwVOqllhebgGWjbfjecIn /dgipzyG5eyDHLI60GCx9L6/V89opQ8CXgPUqiIz0yasm6GFD5f4DG6Bf4o9im7nnkmwPEP5 UhTmjWkWXYhp7TjgnxYdIjwOZotuGFDTJZX2X97WAp2NzRVgX6WfsUKBd99qpqfl5QrLVxXF i27tNdIiIpnH6YGmfbJ9OHy8gGv5Qqn6QKph7lEC+caxivS58INU7BaW5eax+lLG4gzxqFUy HvvVTWFGkGnI+0t0sp4e1V2/JVjLxh49Hibw8bXZ6U/L5V+J89y36bJQ+xLXvkT1rI1fDtc1 Jx2BPA== --B_3548151131_546195-- From nobody Tue Jun 7 10:42:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25C712D5D1; Tue, 7 Jun 2016 10:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 ldzCFw0cud5t; Tue, 7 Jun 2016 10:42:42 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F7E12B00B; Tue, 7 Jun 2016 10:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6684; q=dns/txt; s=iport; t=1465321362; x=1466530962; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=eBwjVaMmc/bnZiwj+orpnFuV4mJxnPrApqvaQqjr9fI=; b=cut9u/UDu64UZ9UlrVNQMFz9Z9b42f7cVKvHsZ7cx9aV3tspSxnoOpm/ TG9KcbYNhPHSbyGfmV1kh3IxTzuLyDW+2XkRXzI/n8OwHznYLBmb/NeLl BBJ5XzuE5w5QIAYP7TRWToyQNIsEirlpIXCWU9bT3k30O6XTucrDlWiSI 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJBwAJB1dX/5xdJa1dDoMwViu2P4Jvg?= =?us-ascii?q?g+BeYYTAoFBOhIBAQEBAQEBZSeERQEBAQMBI1QSCwQUKgICVwYBDAgBAYgjCKt?= =?us-ascii?q?NkSEBAQEBAQEBAQIBAQEBAQEBAQEQDogeCIJOh0GCWQEEmEuDLoFpiRCJRYVbj?= =?us-ascii?q?18lAi2COXo9OopBAQEB?= X-IronPort-AV: E=Sophos;i="5.26,434,1459814400"; d="asc'?scan'208,217";a="282141125" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2016 17:42:41 +0000 Received: from [10.86.254.13] ([10.86.254.13]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u57Hgd2B029266; Tue, 7 Jun 2016 17:42:40 GMT To: "Blumenthal, Uri - 0553 - MITLL" , netmod WG , "opsawg@ietf.org" References: <20160607082500.13784.77653.idtracker@ietfa.amsl.com> <8ef1edcc-0d56-ea5f-90a9-4a64a025ba41@cisco.com> From: Eliot Lear Message-ID: Date: Tue, 7 Jun 2016 19:42:38 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I05X4XcdMPuEOUo6Vj90nKlKiSS8cXdEg" Archived-At: Subject: Re: [netmod] [OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 17:42:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I05X4XcdMPuEOUo6Vj90nKlKiSS8cXdEg Content-Type: multipart/mixed; boundary="WwASx6GEB5lN9RaiJFcts2tMk6HcFKo4j" From: Eliot Lear To: "Blumenthal, Uri - 0553 - MITLL" , netmod WG , "opsawg@ietf.org" Message-ID: Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-lear-ietf-netmod-mud-02.txt References: <20160607082500.13784.77653.idtracker@ietfa.amsl.com> <8ef1edcc-0d56-ea5f-90a9-4a64a025ba41@cisco.com> In-Reply-To: --WwASx6GEB5lN9RaiJFcts2tMk6HcFKo4j Content-Type: multipart/alternative; boundary="------------BA00C00E24779EBD47A72DD1" This is a multi-part message in MIME format. --------------BA00C00E24779EBD47A72DD1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Uri, On 6/7/16 7:32 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > * We now include a signature mechanism for the MUD files. It > was always the plan to do this. There were two choices: > CMS/PKCS#7 or JWS. Again for tooling's sake, so that people > don't need to roll their own, especially for anything security > related, we've gone with CMS and a detached signature at > that. Thanks to John Bashinsky and others for their advice on > this. This area in particular could stand close scrutiny. > > Wouldn=E2=80=99t CMS still require serialization/canonicalization? Yes/No, depending on what you mean. Currently we're treating the MUD file as binary precisely to avoid canonicalization. The transport for all of this is HTTPS and UTF-8. > > Tooling-wise, OpenSSL is indeed prevalent (and seems to do CMS quite > well) =E2=80=93 but JWS tools are around, so you wouldn=E2=80=99t need= to roll your > own if you decided to go that way. I'm not saying there are no tools around, but I personally found slim pickings in the form of various libraries. If people think we should go in a different direction... The key here though is not whether I would want to roll my own but whether others would be able to do the same.=20 This is a pretty large uplift for some, and one goal is to make that as painless as possible. > > Do I need the ability to tell whether a MUD file was not signed or its > signature was deleted?=20 The spec requires that all files be signed and that the signatures be verified prior to processing. And thanks for again for the comments. Eliot --------------BA00C00E24779EBD47A72DD1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Uri,


On 6/7/16 7:32 PM, Blumenthal, Uri - 0553 - MITLL wrote:
  • We now include a signature mechanism for the MUD files.=C2=A0 It was always the plan to do this.=C2=A0 T= here were two choices: CMS/PKCS#7 or JWS.=C2=A0 Again for tooling= 's sake, so that people don't need to roll their own, especially for anything security related, we've gone with CMS and a detached signature at that.=C2=A0 Thanks= to John Bashinsky and others for their advice on this.=C2=A0= This area in particular could stand close scrutiny.
Wouldn=E2=80=99t CMS still require serialization/canonicalizat= ion?
Yes/No, depending on what you mean.=C2=A0 Currently we're treating th= e MUD file as binary precisely to avoid canonicalization.=C2=A0 The transport for all of this is HTTPS and UTF-8.

Tooling-wise, OpenSSL is indeed prevalent (and seems to do CMS quite well) =E2=80=93 but =C2=A0JWS tools are around, so you = wouldn=E2=80=99t need to roll your own if you decided to go that way.

I'm not saying there are no tools around, but I personally found slim pickings in the form of various libraries.=C2=A0 If people think= we should go in a different direction...=C2=A0 The key here though is no= t whether I would want to roll my own but whether others would be able to do the same.=C2=A0 This is a pretty large uplift for some, and one= goal is to make that as painless as possible.


Do I need the ability to tell whether a MUD file was not signed or its signature was deleted?=C2=A0

The spec requires that all files be signed and that the signatures be verified prior to processing.

And thanks for again for the comments.

Eliot

--------------BA00C00E24779EBD47A72DD1-- --WwASx6GEB5lN9RaiJFcts2tMk6HcFKo4j-- --I05X4XcdMPuEOUo6Vj90nKlKiSS8cXdEg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXVwePAAoJEIe2a0bZ0nozJ9IIANgc5MFGZFxENpKkCsoBfdJJ a+zqZcZqE0Ma7H8cHY0ibPcjduAsiN66cRCRMNoMEbZ0h3bgzDCONlsmDiup2tvs box3nG0AagLDHbaE35ZteSD7NOsCpjaRnCR/NFNbvGw3ObJiLPjuQ8YSpWbd2T2w iixfaDrfCRceud+9VJKgxFVgAgBRZ3xTN7ne4VYwJI8uf0/VR4Ujj2R35rn3Wq6x gKAMMT2wtEcpcsZukgfXql9uj7dovAEV3SdmGd3nhutVLlsK2AM8TxKsN+UyFN+O ktHSx5Tm8Ya4h03phzloYBI4/z2zEI5V5JEOxCaTY2KkjFecV2tWaBbQmFawKjE= =sPao -----END PGP SIGNATURE----- --I05X4XcdMPuEOUo6Vj90nKlKiSS8cXdEg-- From nobody Tue Jun 7 14:57:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ECB12D0EE for ; Tue, 7 Jun 2016 14:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 wPPFI22VoqjY for ; Tue, 7 Jun 2016 14:57:47 -0700 (PDT) Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A470D12B04F for ; Tue, 7 Jun 2016 14:57:47 -0700 (PDT) Received: from smtp21.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B76B5180786; Tue, 7 Jun 2016 17:57:46 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp21.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0B0A5180A92; Tue, 7 Jun 2016 17:57:45 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 07 Jun 2016 17:57:46 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 7 Jun 2016 15:57:47 -0600 To: opsawg@ietf.org, netmod@ietf.org, Eliot Lear Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [netmod] Comments on draft-lear-ietf-netmod-mud-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 21:57:49 -0000 I like how this is evolving ... few things=20 Few small things .... If you use CMS, I think you need to deal with how the JSON in = canonicalized before being signed. I will suggest that the standards the = IETF created for signing JSON would be a better choice for signing JSON = than CMS - that's how most other JSON based stuff does it.=20 Putting the last updated and cache validity in the file may not be a = good plan. More importantly putting it inside the stuff that is singed = seems problematic.=20 The "ietf-mud:direction" stuff seems a bit under specified. Does = from-device mean that if the device imitates the flow, responses to the = flow also need to flow to the device? It seems like the = ietf-netmod-acl-model draft might be a better place to specify this.=20 Use of "ietf-mud" as prefix in the JSON for "ietf-mud:direction" is not = how JSON typically does this. You don't need a namespace because we know = this is a mud file thus know the namespace. A big reason some people = moved from XML to JSON was exactly to get rid of namespace.=20 It's not a great practice to put ":" in the names of json attributes = because the way people use them in some languages often have them = unquoted which you can't do if there is a : in the name. You can do it, = but "-" or "_" might be better than ":" here.=20 It would be great to have an simple example JSON file in the = introduction instead of (as well as a complete example in section 6) PS=20 this as a PS because I view the odds of anything changing here to be = about zero but from the peanut gallery ... The JSON for the MUD file is = hideous. It's crap like this from the IETF that causes people to go no, = thanks, I'll just made a standard on github with some open source. It as = awful as Cisco's IOS CLI. Wait, it is the IOS CLI moved to have lots of = angles brackets then translated to be JSON. If you were designing a JSON = representation to describe the network flows of a device, this is not = what it would be.=20= From nobody Wed Jun 8 00:45:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DD112D86E; Wed, 8 Jun 2016 00:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 fevvZ9HahlfA; Wed, 8 Jun 2016 00:44:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A9ABA12D1AA; Wed, 8 Jun 2016 00:44:57 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 424CF1AE0389; Wed, 8 Jun 2016 09:44:56 +0200 (CEST) Date: Wed, 08 Jun 2016 09:45:18 +0200 (CEST) Message-Id: <20160608.094518.235671744205955797.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:44:59 -0000 Andy Bierman wrote: > Hi, > > I prefer (B). For the record, I also prefer B. B is a more robust solution, since it can handle not only intended and applied, but also other existing (e.g. startup) and future (e.g. ephemeral) datastores. /martin > I do not think it is realistic that vendors will rewrite their IETF > modules and vendor modules and all the associated client/server > instrumentation. > This is expensive at many levels. Stability is important for an API. > > So if we do (A), there will be some modules following the convention > and the rest using proprietary RPC-based solutions. > But if we do (B), vendors can integrate the standard RPC-based solution > into their existing running code with zero disturbance. > > > Andy > > > > On Tue, Jun 7, 2016 at 7:19 AM, Lou Berger wrote: > > > All, > > > > We want to provide an update based on the off line discussions > > related to OpState Solutions that we have been having and solicit > > input from the WG. > > > > All authors of current solution drafts [1,2,3] together with those > > who helped conduct the solutions analysis* were invited to the these > > discussions -- with the objective of coming up with a single > > consolidated proposal to bring to the WG. (I/Lou acted as facilitator > > as Kent and Juergen were and are involved with the technical details.) > > > > The discussions have yielded some results but, unfortunately, > > not a single consolidated proposal as hoped, but rather two > > alternate directions -- and clearly we need to choose one: > > > > 1) Adopt the conventions for representing state/config > > based on Section 6 of [1]. > > > > From a model definition perspective, these conventions > > impact every model and every model writer. > > > > 2) Model OpState using a revised logical datastore definition > > as introduced in [4] and also covered in [5]. There is > > also a variant of this that we believe doesn't significantly > > impact this choice. > > > > With this approach, model definitions need no explicit > > changes to support applied configuration. > > > > >From a technology/WG standpoint, we believe an approach > > that doesn't impact every model written (i.e., #2) is superior. > > The counterpoint to this is that the conventions based > > approach (i.e., #1) is available today and being followed in > > OpenConfig defined models. > > > > We would like to hear opinions on this from the WG before > > declaring one of the following as the WG direction: > > > > A) models that wish to support applied configuration MUST > > follow conventions based on [1] -- and the WG needs to > > formalize these conventions. > > or > > B) no explicit support is required for models to support > > applied configuration -- and that the WG needs to > > formalize an opstate solution based on the approach > > discussed in [4] and [5]. > > > > We intend to close on this choice before Berlin. > > > > Thank you, > > Lou (and co-chairs) > > > > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > > [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > > [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > > * - Chris H. and Acee L. > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Wed Jun 8 00:47:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AD012D871 for ; Wed, 8 Jun 2016 00:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 wnHI5PzyysS2 for ; Wed, 8 Jun 2016 00:47:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01912D188 for ; Wed, 8 Jun 2016 00:47:51 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 2C2D21AE0389; Wed, 8 Jun 2016 09:47:50 +0200 (CEST) Date: Wed, 08 Jun 2016 09:48:12 +0200 (CEST) Message-Id: <20160608.094812.841880251515737783.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20160607163831.GB9870@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:47:57 -0000 Andy Bierman wrote: > On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierman wrote: > > > On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: > > > > > Ladislav Lhotka writes: > > > > > > "Dale R. Worley" writes: > > > > > >> A difficulty I have with the current wording is that it doesn't > > point > > > > > >> out the crucial fact about leafref that the XPath expression can > > only > > > > > >> select elements that are instantiations of one particular data > > node. > > > > I > > > > > >> don't know XPath, but it seems that that is not a general > > property of > > > > > >> XPath expressions, you seem to be able to write XPath expressions > > that > > > > > >> select heterogenous groups of elements. So it's worth pointing > > out > > > > that > > > > > >> the allowed XPath expressions can't do that, and that is because > > of > > > > the > > > > > >> restriction that the expression must match path-arg. > > > > > > > > > > > > Right, this is the slightly hand-waving part that I also objected > > to. > > > > An > > > > > > XPath expression in a leafref's "path" statement indeed selects a > > node > > > > > > set from an instance data tree. The node seet can be empty, but if > > it > > > > is > > > > > > non-empty, all its members necessarily have the same type, which is > > > > > > defined in a certain "leaf" schema node. > > > > > > > > > > > > The relationship is relatively straightforward but difficult to > > explain > > > > > > concisely. One basically has to follow the steps in the XPath > > > > > > expression, ignore all path-predicates, and skip all schema nodes > > that > > > > > > aren't data nodes (i.e., "choice" and "case" nodes). > > > > > > > > > > Yes, it's difficult to explain, though once one gets the idea, it's > > > > > straightforward enough. The problem I have is that it's not pointed > > out > > > > > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I > > don't > > > > > see it there.) > > > > > > > > > > The crucial points seem to be: > > > > > > > > > > - The XPath expression is limited by the syntax "path-arg" and the > > rules > > > > > in 9.9.2. > > > > > > > > > > - Because of those restrictions, there exists one data node in the > > > > > schema such that: evalutating the expression for any leaf or > > > > > leaf-list node in any data tree returns a set of nodes, all of > > which > > > > > are instances of that one schema node. > > > > > > > > > > - The type of that schema node is the base type of the leafref. > > > > > > > > > > - Once you learn this, it's easy to see, for any particular > > > > > leaf/leaf-list node and path expression in a module, which schema > > node > > > > > is the one. But it's rather hard to describe that process. > > > > > > > > > > Actually, there's an ugly question: If the path expression > > references > > > > > an element name that doesn't exist in the module. Perhaps there are > > > > > rules in XPath that prevent it, but it seems to me that you could > > write > > > > > > > > > > leaf mgmt-interface { > > > > > mandatory false; > > > > > type leafref { > > > > > path "../interface/name"; > > > > > require-instance true; > > > > > } > > > > > } > > > > > > > > > > when the current module doesn't have a "name" child defined for > > > > > "interface". As long as a data tree didn't contain a mgmt-interface > > > > > elememt, the constraint would not be violated. > > > > > > > > > > But a later revision of the module, the "name" child could be added, > > > > > allowing data trees to contain mgmt-interface elements, because data > > > > > trees could now have "name" elements. > > > > > > > > > > The point being that when you're figuring out which schema node is > > the > > > > > base type for the leafref, that schema node has to exist so the base > > > > > type can be extracted. But there's no direct statement of that as a > > > > > requirement for path validity. > > > > > > > > > > > > > As WG chair, I am getting a bit nervous. We have to wrap things up and > > > > we need deliver the specification - it is past WG last call, it is > > > > past IETF last call, it is past IESG approval (kind of). We can likely > > > > endlessly continue to search for possible ways to misunderstand the > > > > specification but lets remember the aphorism 'perfect is the enemy of > > > > good'. > > > > > > > > I leave it to Martin's discretion to decide whether he wants to add > > > > 'The referred leaf or leaf-list node in the schema tree MUST exist.' > > > > to the new text but I think the time has come to stop searching for > > > > new possible ways to misunderstand the specification. > > > > > > > > > > > > > > Doesn't the text above exclude a default leaf or leaf-list from the > > > value space? That would be incorrect. > > > > > > > It says 'in the schema tree' so I think there is no problem. We were > > discussing the corner case where the path argument does not point to a > > schema node at all. Pyang already reports this as an error (bar in the > > path of foo [...] is not found). > > > > > I thought the original issue was that the ABNF does not support > position-based > instance identifiers. This is supported even in RFC 6020. /martin > In the rare event that the i-i pointed to a > config=false > list entry (with no keys defined) then its position needs to be used. > > I thought it was clear that the path-stmt has to point at a schema node > that can be resolved in the module context using the import-stmts. > > > > > /js > > > > > Andy > > > > -- > > 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 Jun 8 00:50:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA6912D1BC for ; Wed, 8 Jun 2016 00:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 1_ZVyLnhQ6aF for ; Wed, 8 Jun 2016 00:50:54 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2CFB12D1AA for ; Wed, 8 Jun 2016 00:50:53 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id CC1111AE0389; Wed, 8 Jun 2016 09:50:52 +0200 (CEST) Date: Wed, 08 Jun 2016 09:51:15 +0200 (CEST) Message-Id: <20160608.095115.1337034559082416025.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160607155258.GA9796@elstar.local> References: <87ziqx81h0.fsf@hobgoblin.ariadne.com> <20160607155258.GA9796@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 07:50:56 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: > > Ladislav Lhotka writes: > > > "Dale R. Worley" writes: > > >> A difficulty I have with the current wording is that it doesn't point > > >> out the crucial fact about leafref that the XPath expression can only > > >> select elements that are instantiations of one particular data node. I > > >> don't know XPath, but it seems that that is not a general property of > > >> XPath expressions, you seem to be able to write XPath expressions that > > >> select heterogenous groups of elements. So it's worth pointing out that > > >> the allowed XPath expressions can't do that, and that is because of the > > >> restriction that the expression must match path-arg. > > > > > > Right, this is the slightly hand-waving part that I also objected to. An > > > XPath expression in a leafref's "path" statement indeed selects a node > > > set from an instance data tree. The node seet can be empty, but if it is > > > non-empty, all its members necessarily have the same type, which is > > > defined in a certain "leaf" schema node. > > > > > > The relationship is relatively straightforward but difficult to explain > > > concisely. One basically has to follow the steps in the XPath > > > expression, ignore all path-predicates, and skip all schema nodes that > > > aren't data nodes (i.e., "choice" and "case" nodes). > > > > Yes, it's difficult to explain, though once one gets the idea, it's > > straightforward enough. The problem I have is that it's not pointed out > > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I don't > > see it there.) > > > > The crucial points seem to be: > > > > - The XPath expression is limited by the syntax "path-arg" and the rules > > in 9.9.2. > > > > - Because of those restrictions, there exists one data node in the > > schema such that: evalutating the expression for any leaf or > > leaf-list node in any data tree returns a set of nodes, all of which > > are instances of that one schema node. > > > > - The type of that schema node is the base type of the leafref. > > > > - Once you learn this, it's easy to see, for any particular > > leaf/leaf-list node and path expression in a module, which schema node > > is the one. But it's rather hard to describe that process. > > > > Actually, there's an ugly question: If the path expression references > > an element name that doesn't exist in the module. Perhaps there are > > rules in XPath that prevent it, but it seems to me that you could write > > > > leaf mgmt-interface { > > mandatory false; > > type leafref { > > path "../interface/name"; > > require-instance true; > > } > > } > > > > when the current module doesn't have a "name" child defined for > > "interface". As long as a data tree didn't contain a mgmt-interface > > elememt, the constraint would not be violated. > > > > But a later revision of the module, the "name" child could be added, > > allowing data trees to contain mgmt-interface elements, because data > > trees could now have "name" elements. > > > > The point being that when you're figuring out which schema node is the > > base type for the leafref, that schema node has to exist so the base > > type can be extracted. But there's no direct statement of that as a > > requirement for path validity. > > > > As WG chair, I am getting a bit nervous. We have to wrap things up and > we need deliver the specification - it is past WG last call, it is > past IETF last call, it is past IESG approval (kind of). We can likely > endlessly continue to search for possible ways to misunderstand the > specification but lets remember the aphorism 'perfect is the enemy of > good'. > > I leave it to Martin's discretion to decide whether he wants to add > 'The referred leaf or leaf-list node in the schema tree MUST exist.' The text for "path" already says: It takes as an argument a string that MUST refer to a leaf or leaf-list node. > to the new text but I think the time has come to stop searching for > new possible ways to misunderstand the specification. /martin > > I like to see all issues closed by the end of the week a new revision > with all changes posted. People can then check the edits to be sure > nothing broke and then the document should move via Benoit into the > RFC editor queue by the end of the following week or Monday June 20th. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Jun 8 01:10:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61E912D1E3 for ; Wed, 8 Jun 2016 01:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 Vv0jzZMT-t_W for ; Wed, 8 Jun 2016 01:10:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219DF12D10B for ; Wed, 8 Jun 2016 01:10:28 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:d005:a3e6:9df9:5d17] (unknown [IPv6:2001:718:1a02:1:d005:a3e6:9df9:5d17]) by mail.nic.cz (Postfix) with ESMTPSA id 8285B61D2F; Wed, 8 Jun 2016 10:10:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465373426; bh=B63B1S3Gd90Obn7SmqdMov1gHkP2Ja5YE3HPUbFygVM=; h=From:Date:To; b=R/sLZ9UEk7vqiOKpkrIdijJHHDDnzQF8m3qYBDnq2saMrziEt8hD7UVl+QhpplKZ5 78eY8jf4aiHzRJ2Yy+RM/6c31t3JLloai6hyFy14eJkuAN4tonbh8NrUtrstcj3VFu h1mXhFY7SJ1GQgCHP5ja9lQPNgMzKUjA8QAoTNx4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160608.095115.1337034559082416025.mbj@tail-f.com> Date: Wed, 8 Jun 2016 10:10:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <316BB5B6-0977-40FF-987C-FBEB92BC5E62@nic.cz> References: <87ziqx81h0.fsf@hobgoblin.ariadne.com> <20160607155258.GA9796@elstar.local> <20160608.095115.1337034559082416025.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 08:10:31 -0000 > On 08 Jun 2016, at 09:51, Martin Bjorklund wrote: >=20 > Juergen Schoenwaelder wrote: >> On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: >>> Ladislav Lhotka writes: >>>> "Dale R. Worley" writes: >>>>> A difficulty I have with the current wording is that it doesn't = point >>>>> out the crucial fact about leafref that the XPath expression can = only >>>>> select elements that are instantiations of one particular data = node. I >>>>> don't know XPath, but it seems that that is not a general property = of >>>>> XPath expressions, you seem to be able to write XPath expressions = that >>>>> select heterogenous groups of elements. So it's worth pointing = out that >>>>> the allowed XPath expressions can't do that, and that is because = of the >>>>> restriction that the expression must match path-arg. >>>>=20 >>>> Right, this is the slightly hand-waving part that I also objected = to. An >>>> XPath expression in a leafref's "path" statement indeed selects a = node >>>> set from an instance data tree. The node seet can be empty, but if = it is >>>> non-empty, all its members necessarily have the same type, which is >>>> defined in a certain "leaf" schema node. >>>>=20 >>>> The relationship is relatively straightforward but difficult to = explain >>>> concisely. One basically has to follow the steps in the XPath >>>> expression, ignore all path-predicates, and skip all schema nodes = that >>>> aren't data nodes (i.e., "choice" and "case" nodes). >>>=20 >>> Yes, it's difficult to explain, though once one gets the idea, it's >>> straightforward enough. The problem I have is that it's not pointed = out >>> explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I = don't >>> see it there.) >>>=20 >>> The crucial points seem to be: >>>=20 >>> - The XPath expression is limited by the syntax "path-arg" and the = rules >>> in 9.9.2. >>>=20 >>> - Because of those restrictions, there exists one data node in the >>> schema such that: evalutating the expression for any leaf or >>> leaf-list node in any data tree returns a set of nodes, all of = which >>> are instances of that one schema node. >>>=20 >>> - The type of that schema node is the base type of the leafref. >>>=20 >>> - Once you learn this, it's easy to see, for any particular >>> leaf/leaf-list node and path expression in a module, which schema = node >>> is the one. But it's rather hard to describe that process. >>>=20 >>> Actually, there's an ugly question: If the path expression = references >>> an element name that doesn't exist in the module. Perhaps there are >>> rules in XPath that prevent it, but it seems to me that you could = write >>>=20 >>> leaf mgmt-interface { >>> mandatory false; >>> type leafref { >>> path "../interface/name"; >>> require-instance true; >>> } >>> } >>>=20 >>> when the current module doesn't have a "name" child defined for >>> "interface". As long as a data tree didn't contain a mgmt-interface >>> elememt, the constraint would not be violated. >>>=20 >>> But a later revision of the module, the "name" child could be added, >>> allowing data trees to contain mgmt-interface elements, because data >>> trees could now have "name" elements. >>>=20 >>> The point being that when you're figuring out which schema node is = the >>> base type for the leafref, that schema node has to exist so the base >>> type can be extracted. But there's no direct statement of that as a >>> requirement for path validity. >>>=20 >>=20 >> As WG chair, I am getting a bit nervous. We have to wrap things up = and >> we need deliver the specification - it is past WG last call, it is >> past IETF last call, it is past IESG approval (kind of). We can = likely >> endlessly continue to search for possible ways to misunderstand the >> specification but lets remember the aphorism 'perfect is the enemy of >> good'. >>=20 >> I leave it to Martin's discretion to decide whether he wants to add >> 'The referred leaf or leaf-list node in the schema tree MUST exist.' >=20 > The text for "path" already says: >=20 > It takes as an argument a > string that MUST refer to a leaf or leaf-list node. It's unclear what "refer" means. If it's XPath, it can only refer to an = instance in a data tree, not in the schema. Lada >=20 >=20 >> to the new text but I think the time has come to stop searching for >> new possible ways to misunderstand the specification. >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> I like to see all issues closed by the end of the week a new revision >> with all changes posted. People can then check the edits to be sure >> nothing broke and then the document should move via Benoit into the >> RFC editor queue by the end of the following week or Monday June = 20th. >>=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 8 01:15:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B9812D0AC for ; Wed, 8 Jun 2016 01:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 OjOFukUgHLUW for ; Wed, 8 Jun 2016 01:15:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 96E0612B049 for ; Wed, 8 Jun 2016 01:15:03 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id DEC411AE046B; Wed, 8 Jun 2016 10:15:01 +0200 (CEST) Date: Wed, 08 Jun 2016 10:15:24 +0200 (CEST) Message-Id: <20160608.101524.2250147567599766323.mbj@tail-f.com> To: worley@ariadne.com From: Martin Bjorklund In-Reply-To: <87vb1m9f36.fsf@hobgoblin.ariadne.com> References: <20160523.154309.848500367505009627.mbj@tail-f.com> <20160523.154309.848500367505009627.mbj@tail-f.com> <87vb1m9f36.fsf@hobgoblin.ariadne.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 08:15:07 -0000 Hi, worley@ariadne.com (Dale R. Worley) wrote: > (This is the first part of my response, which I am sending seperately to > speed things up.) > > Martin Bjorklund wrote: > > worley@ariadne.com (Dale R. Worley) wrote: > > > Martin Bjorklund wrote on Mon, 23 May 2016 15:43:09 +0200 (CEST): > > > > worley@ariadne.com (Dale R. Worley) wrote: > > > > > > Almost all of these points I'm happy with the authors fixing in the > > > manner they suggest. The points where I have further comment are: > > > > > > > > The incompatibilities should be marked whether the old, incompatible > > > > > usage always causes an error "at compile time", "at run time", or > > > > > changed behavior. > > > > > > > > Ok, but I'd like to avoid the term "compile-time" here. > > > > > > True... The distinction I'm looking for is "Incompatible usage will > > > cause an error report before the software is put into operation." > > > vs. "Incompatible usage will cause an error report when the software is > > > in operation." vs. "Incompatible usage will cause a difference in > > > behavior without an error report." > > > > The spec defines what is legal YANG. How this is enforced by tools > > must be up to the tools, right? > > It depends. When reading about incompatibilities, it's really nice to > be informed what will happen. E.g., if the compiler will catch it, > you just recompile the code and watch for error messages. If it will > cause incompatible run-time behavior, you have to inspect the code, > which is a lot of work. > > > > > How about: > > > > > > > > The following changes are not backwards compatible with YANG version > > > > 1: > > > > > > > > o Changed the rules for the interpretation of escaped characters in > > > > double quoted strings. This is an backwards incompatible change > > > > from YANG version 1. A module that uses a character sequence that > > > > is now illegal must change the string to match the new rules. See > > > > Section 6.1.3 for details. > > > > > > > > o An unquoted string cannot contain any single or double quote > > > > characters. This is an backwards incompatible change from YANG > > > > version 1. A module that uses such quote characters must change > > > > the string to match the new rules. See Section 6.1.3 for details. > > > > > > I assume that the first two situations will cause an error report before > > > the module is put into production. > > > > > > > o Made noncharacters illegal in the built-in type "string". This > > > > change affects the run-time behavior of YANG-based protocols. > > > > > > What happens if you attempt to use a noncharacter in a string? > > > > This depends on the protocol. noncharacters are illegal. Maybe in > > protocol A you can't even encode noncharacters, but in protocol B > > you'll get a protocol error from the other side if you send > > noncharacters. > > Really, the question is "What does 'illegal' mean?" Of course, it > means that you shouldn't do it, but does it also contain assertions > that some particular stage of processing will explicitly flag it? > > > > It might be worth inserting a definition of "node" as shorthand for > > > "data node", as there seems to be no definition of "node" alone, but it > > > is commonly used to mean "data node". In particular, the reader needs > > > to be fully aware that "node" is a node in the schema tree, not an > > > instantiation thereof. > > > > But saying that "node" means "data node" is not correct. Sometimes > > the text talk about "schema nodes" etc. I think it is better to > > qualify the usage of "node" where necessary to avoid the ambiguity. > > OK, I see. But since I was getting confused, it suggests that there > are various places where "node" is used where it wasn't clear from > context whether it was a data node or a schema node. > > > > > > It would be useful to insert a note somewhere that all data is either > > > > > "configuration" or "state" data. It's hard to learn that now, because > > > > > the terms "configuration data" and "state data" are defined only by > > > > > reference to RFC 6241. > > > > > > > > But this is not strictly correct. For example RPC input is neither > > > > config nor state. Section 3 has: > > > > > > > > o data tree: An instantiated tree of any data modeled with YANG, > > > > e.g., configuration data, state data, combined configuration and > > > > state data, RPC or action input, RPC or action output, or > > > > notification. > > > > > > Section 4.1 contains a similar statement. > > > > > > I think the problem I'm having is with the first sentences of 4.2.3: > > > > > > YANG can model state data, as well as configuration data, based on > > > the "config" statement. > > > > > > At first read, this suggests that data is partitioned into > > > "configuration data" and "state data". What's really happening is that > > > there are various sorts of data, but some contexts admit a mixture of > > > configuration and state data, so the data model definitions of those > > > contexts requires that individual data items can be flagged as > > > configuration vs. data. Maybe starting 4.2.3 like this would work: > > > > > > In some contexts, data modeled by YANG can contain mixtures of state > > > data and configuration data, based on the "config" statement. When a > > > node is tagged with "config false", its subhierarchy is flagged as > > > state data. > > > > I think that this might be a bit confusing (which contexts? what > > exacyly is this mixture?) and too detailed for this introductory > > section. I would perfer to keep the original text. > > That leaves the problem that there are forms that are neither state > data nor configuration data. > > Also, the phrasing is odd in that it seems to assume that > configuration data is sort of a default condition and state data is an > exception. I think what was intended is > > YANG can differentiate state data and configuration data within > one instantiated tree, based on the "config" statement. > > > > > > - section 5.1.2 > > > > > > > > > > YANG allows modeling of data in multiple hierarchies, where data may > > > > > have more than one top-level node. Models that have multiple top- > > > > > level nodes are sometimes convenient, and are supported by YANG. > > > > > > > > > > Any single module seems to define only one data structure, the one > > > > > whose elements are the items listed in the module, and Yang doesn't > > > > > seem to provide for any sort of "model" definition other than a > > > > > module. Or are the nodes at the top level within the module all > > > > > usable as independent data structures? > > > > > > > > The term "data structure" isn't used in the document. YANG allows > > > > a module to define more than one subtree. > > > > > > OK, I think I see where I was confused. I think that would have been > > > avoided if the 5.1.2 started: > > > > > > YANG allows modeling of data in multiple hierarchies. Each top-level > > > data node in a module defines an independent hierarchy. Models that > > > have ... > > > > What does "independent" imply? They are not necessarily semantically > > independent. Maybe s/independent/separate/ ? > > Yes, "separate" would work well. Ok, I'll add this. > Here, I'll mention again this point from another e-mail: The second > sentence of section 4.1 suggests that a Yang module defines *one* > hierarchy of data, whereas it seems like any top-level data node in a > module has meaning separately and can be instantiated seperately. I'll s/hierarchy/hierarchies/. > > > > > - section 5.5 > > > > > > > > > > This section talks a great deal about why scoping is done, but isn't > > > > > specifically clear what the rules are. (Traditionally, the rule is > > > > > stated as either what range of source text a particular definition is > > > > > visible in, or given an identifier use, how the matching definition is > > > > > found.) > > > > > > > > > > Scoped definitions MUST NOT shadow definitions at a higher scope. A > > > > > type or grouping cannot be defined if a higher level in the schema > > > > > hierarchy has a definition with a matching identifier. > > > > > > > > > > I think the second sentence is confusing, because (to me) the term > > > > > "schema hierarchy" implies the data tree structure, whereas the > > > > > scoping rule seems to be intended to be entirely lexical. In either > > > > > case, this needs to be clarified. > > > > > > > > The first sentence says: > > > > > > > > Typedefs and groupings may appear nested under many YANG statements, > > > > allowing these to be lexically scoped by the hierarchy under which > > > > they appear. > > > > > > > > Maybe it would help to move paragraph 2 and 3 to the end, so that the > > > > motivational text is at the end of the section? > > > > > > It looks like current paragraphs 1, 4, and 5 are prescriptive, and 2 and > > > 3 are motivational. Putting 1, 4, and 5 together should make them > > > clearer. But since paragraph 2 starts with "Scoping...", it really > > > needs to be after 1. So, yes, moving 2 and 3 to the end seems like the > > > clearest order. Does it make sense to you to put all of the motivation > > > at the end of this section? > > > > I prefer to have motivational text before the rules ("why" before > > "how"). Hmm. The preferred order is "what", "why", "how", and that > > is really the order we currently have (1 is "what", 2 + 3 is "why" and > > 4 +5 is "how"). > > > > But obviously this was confusing to you, so we probably need to make > > some clarification. > > > > Since the problem was with the term "schema hierarchy", maybe we could > > change this to "statement hierarchy" instead, to stress the fact that > > it is lexical scoping? > > > > [sorry for missing your original point] > > Yes, I think that will do it. There are two instances of "hierarchy" > in para. 1, and at least the first one would be clearer if it was > "statement hierarchy". And in para. 4, it seems like "schema > hierarchy" is actually incorrect, and should be "statement hierarchy". Fixed. > > > > > - section 5.6.5 > > > > > > > > > > I suspect that if a server implements module A, and A imports B, the > > > > > server is not required to implement B. (Even if A references > > > > > groupings in B.) The answer to that should probably be stated > > > > > explicitly. > > > > > > > > It is not so simple. The rest of the text defines the rules for when > > > > the server is required to implement B. > > > > > > Yes, I was wrong there. (I can't see why I made that mistake.) > > > > > > > > Is this the correct way to specify multiple revisions of this module? > > > > > Or is this an informal notation for the two module definitions: > > > > > > > > > > module b { > > > > > yang-version 1.1; > > > > > namespace "urn:example:b"; > > > > > prefix "b"; > > > > > > > > > > revision 2015-04-04; > > > > > revision 2015-01-01; > > > > > > > > > > typedef myenum { > > > > > type enumeration { > > > > > enum zero; // added in 2015-01-01 > > > > > enum one; // added in 2015-04-04 > > > > > } > > > > > } > > > > > > > > > > container x { // added in 2015-01-01 > > > > > container y; // added in 2015-04-04 > > > > > } > > > > > } > > > > > > > > > > module b { > > > > > yang-version 1.1; > > > > > namespace "urn:example:b"; > > > > > prefix "b"; > > > > > > > > > > revision 2015-01-01; > > > > > > > > > > typedef myenum { > > > > > type enumeration { > > > > > enum zero; // added in 2015-01-01 > > > > > } > > > > > } > > > > > > > > > > container x { // added in 2015-01-01 > > > > > } > > > > > } > > > > > > > > > > If it is the latter, it would help the new reader to explain the > > > > > convention (as no example of a multi-revision module is given in the > > > > > document). > > > > > > > > The comments are not required. There is no correct (mandated) way to > > > > specify which changes are done in a new revision. > > > > > > What I was concerned with is what does the above module statement do? > > > If I understand correctly, it defines the 2015-04-04 revision of b, and > > > also tells us that a 2015-01-01 revision exists, but does not define > > > that revision. Implicitly, there must be a .yang file somewhere > > > containing the module statement that defines the 2015-01-01 revision of > > > b. > > > > > > But despite that the text talks about the 2015-01-01 revision ('can > > > implement revision "2015-01-01" or "2015-04-04" of module "b"'), that > > > file is not included in the example, which is not what I expected, which > > > led me to wonder if the 2015-01-01 revision was somehow also defined by > > > the presented "module b" statement. I would have had less trouble with > > > the example if the definition of the earlier revision of b was also > > > given. > > > > Ok, I see what you mean. This makes sense. I'll add > > > > module b { > > yang-version 1.1; > > namespace "urn:example:b"; > > prefix "b"; > > > > revision 2015-01-01; > > > > typedef myenum { > > type enumeration { > > enum zero; > > } > > } > > > > container x { > > } > > } > > > > and > > > > module c { > > yang-version 1.1; > > namespace "urn:example:c"; > > prefix "c"; > > > > revision 2015-02-02; > > > > typedef bar { > > ... > > } > > } > > > > > > to the example. > > Yes, I think that will make it all clear. > > > > > > It is worth noting (either here or in 6.1.3) how line-breaks inside > > > > > quoted strings are transcribed into the string's value. As now > > > > > written, it seems that the line-break is transcribed identically to > > > > > how it is represented in the source. That means (1) If the source is > > > > > recoded with the other type of line break, the semantics of the Yang > > > > > code change; and (2) if the source uses line-breaks of one type (CRLF > > > > > or LF), only that type can be directly transcribed into string values. > > > > > (But regardless of the source line-breaks, an LF can be transcribed > > > > > into a double-quoted string with "\n". But a CRLF cannot be > > > > > transcribed into a double-quoted string with escape sequences. Was > > > > > that intended, or was "\r" intended to be legal?) > > > > > > Don't forget this. > > I was wondering that (as the text is written) the value of a quoted > string that includes a line end will change if the line ends are > changed (say, by moving the Yang file to a different host). Normally > computer languages are defined so that changing how the program is > "represented", e.g., by transforming it into a form with different > line-ends, won't change the semantics of the program. > > But if it's true, I seems desirable to provide an explicit warning > about it. > > > Adding "\r" would be backwards incompatible with YANG 1. > > I don't see why that is. As far as I can tell from RFC 6020, "\r" is > not a defined escape in Yang 1, so existing Yang 1 code can't use it. > True, the new draft explicitly states "It is an error if any other > character follows the backslash character.", but RFC 6020 doesn't seem > to allow "\r" to mean anything. Or is it that in practice, Yang 1 > allows people to write "\r", which is interpreted as backslash-r? I think there are implementations that reject \r, and I know that there are implementations that allow \r. > > You can always get the same effect by using single quoted strings. > > I don't see how you can get a single CR using single-quoted strings, > because line ends are only allowed to be LF and CR-LF; writing a CR > without an LF following it isn't allowed. Or is it that in practice, > Yang 1 allows people to use CR alone, and it is not interpreted as a > line-end? If the module has a string like this: 0x27 0x0d 0x27 it is a string with a single CR. /martin From nobody Wed Jun 8 01:31:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7B712D874 for ; Wed, 8 Jun 2016 01:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 Nue6-JvUfegg for ; Wed, 8 Jun 2016 01:31:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4114412D871 for ; Wed, 8 Jun 2016 01:31:10 -0700 (PDT) Received: from mars.tail-f.com (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 7BD8B1AE046B for ; Wed, 8 Jun 2016 10:31:09 +0200 (CEST) To: netmod@ietf.org References: <20160607163831.GB9870@elstar.local> <20160608.094812.841880251515737783.mbj@tail-f.com> From: Per Hedeland Message-ID: <5757D7CD.8030707@tail-f.com> Date: Wed, 8 Jun 2016 10:31:09 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160608.094812.841880251515737783.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 08:31:13 -0000 On 2016-06-08 09:48, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierman wrote: >>>> On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder < >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>> >>>>> On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: >>>>>> Ladislav Lhotka writes: >>>>>>> "Dale R. Worley" writes: >>>>>>>> A difficulty I have with the current wording is that it doesn't >>> point >>>>>>>> out the crucial fact about leafref that the XPath expression can >>> only >>>>>>>> select elements that are instantiations of one particular data >>> node. >>>>> I >>>>>>>> don't know XPath, but it seems that that is not a general >>> property of >>>>>>>> XPath expressions, you seem to be able to write XPath expressions >>> that >>>>>>>> select heterogenous groups of elements. So it's worth pointing >>> out >>>>> that >>>>>>>> the allowed XPath expressions can't do that, and that is because >>> of >>>>> the >>>>>>>> restriction that the expression must match path-arg. >>>>>>> >>>>>>> Right, this is the slightly hand-waving part that I also objected >>> to. >>>>> An >>>>>>> XPath expression in a leafref's "path" statement indeed selects a >>> node >>>>>>> set from an instance data tree. The node seet can be empty, but if >>> it >>>>> is >>>>>>> non-empty, all its members necessarily have the same type, which is >>>>>>> defined in a certain "leaf" schema node. >>>>>>> >>>>>>> The relationship is relatively straightforward but difficult to >>> explain >>>>>>> concisely. One basically has to follow the steps in the XPath >>>>>>> expression, ignore all path-predicates, and skip all schema nodes >>> that >>>>>>> aren't data nodes (i.e., "choice" and "case" nodes). >>>>>> >>>>>> Yes, it's difficult to explain, though once one gets the idea, it's >>>>>> straightforward enough. The problem I have is that it's not pointed >>> out >>>>>> explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I >>> don't >>>>>> see it there.) >>>>>> >>>>>> The crucial points seem to be: >>>>>> >>>>>> - The XPath expression is limited by the syntax "path-arg" and the >>> rules >>>>>> in 9.9.2. >>>>>> >>>>>> - Because of those restrictions, there exists one data node in the >>>>>> schema such that: evalutating the expression for any leaf or >>>>>> leaf-list node in any data tree returns a set of nodes, all of >>> which >>>>>> are instances of that one schema node. >>>>>> >>>>>> - The type of that schema node is the base type of the leafref. >>>>>> >>>>>> - Once you learn this, it's easy to see, for any particular >>>>>> leaf/leaf-list node and path expression in a module, which schema >>> node >>>>>> is the one. But it's rather hard to describe that process. >>>>>> >>>>>> Actually, there's an ugly question: If the path expression >>> references >>>>>> an element name that doesn't exist in the module. Perhaps there are >>>>>> rules in XPath that prevent it, but it seems to me that you could >>> write >>>>>> >>>>>> leaf mgmt-interface { >>>>>> mandatory false; >>>>>> type leafref { >>>>>> path "../interface/name"; >>>>>> require-instance true; >>>>>> } >>>>>> } >>>>>> >>>>>> when the current module doesn't have a "name" child defined for >>>>>> "interface". As long as a data tree didn't contain a mgmt-interface >>>>>> elememt, the constraint would not be violated. >>>>>> >>>>>> But a later revision of the module, the "name" child could be added, >>>>>> allowing data trees to contain mgmt-interface elements, because data >>>>>> trees could now have "name" elements. >>>>>> >>>>>> The point being that when you're figuring out which schema node is >>> the >>>>>> base type for the leafref, that schema node has to exist so the base >>>>>> type can be extracted. But there's no direct statement of that as a >>>>>> requirement for path validity. >>>>>> >>>>> >>>>> As WG chair, I am getting a bit nervous. We have to wrap things up and >>>>> we need deliver the specification - it is past WG last call, it is >>>>> past IETF last call, it is past IESG approval (kind of). We can likely >>>>> endlessly continue to search for possible ways to misunderstand the >>>>> specification but lets remember the aphorism 'perfect is the enemy of >>>>> good'. >>>>> >>>>> I leave it to Martin's discretion to decide whether he wants to add >>>>> 'The referred leaf or leaf-list node in the schema tree MUST exist.' >>>>> to the new text but I think the time has come to stop searching for >>>>> new possible ways to misunderstand the specification. >>>>> >>>>> >>>> >>>> Doesn't the text above exclude a default leaf or leaf-list from the >>>> value space? That would be incorrect. >>>> >>> >>> It says 'in the schema tree' so I think there is no problem. We were >>> discussing the corner case where the path argument does not point to a >>> schema node at all. Pyang already reports this as an error (bar in the >>> path of foo [...] is not found). >>> >>> >> I thought the original issue was that the ABNF does not support >> position-based >> instance identifiers. > > This is supported even in RFC 6020. But not for the leafref 'path' argument, right? I'm not sure how instance-identifier values are relevant in this particular discussion... --Per > /martin > > >> In the rare event that the i-i pointed to a >> config=false >> list entry (with no keys defined) then its position needs to be used. >> >> I thought it was clear that the path-stmt has to point at a schema node >> that can be resolved in the module context using the import-stmts. >> >> >> >>> /js >>> >>> >> Andy >> >> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Jun 8 02:13:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A5B12B008 for ; Wed, 8 Jun 2016 02:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 di0b3VFy4y0q for ; Wed, 8 Jun 2016 02:13:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31A812D86F for ; Wed, 8 Jun 2016 02:13:33 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:d005:a3e6:9df9:5d17] (unknown [IPv6:2001:718:1a02:1:d005:a3e6:9df9:5d17]) by mail.nic.cz (Postfix) with ESMTPSA id 676E360846; Wed, 8 Jun 2016 11:13:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465377210; bh=0SKOD5Wfr4rXDwBea5vwj/p+64vBJKaN6S45tX7iHGU=; h=From:Date:To; b=HE5zByODyVuxC4T90Nz3KoAPSQLgbsgZEu8sWCuFxkoCtH3MgKLSCokaYoHUo3SGu TtvMSNn7K0XWx7gLBQ6vl+MTgjD5iTCWsBJ1nd6tnrIbUuDgdkhzkKUqK69gEnga91 0h8jLTmQ2eHaoWSHzvy3QQlgrzRBsFjnMVBaztpk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 8 Jun 2016 11:13:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87ziqx81h0.fsf@hobgoblin.ariadne.com> <20160607155258.GA9796@elstar.local> <20160607163831.GB9870@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 09:13:36 -0000 > On 07 Jun 2016, at 18:45, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Jun 7, 2016 at 9:38 AM, Juergen Schoenwaelder = wrote: > On Tue, Jun 07, 2016 at 09:08:56AM -0700, Andy Bierman wrote: > > On Tue, Jun 7, 2016 at 8:52 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Tue, Jun 07, 2016 at 11:26:03AM -0400, Dale R. Worley wrote: > > > > Ladislav Lhotka writes: > > > > > "Dale R. Worley" writes: > > > > >> A difficulty I have with the current wording is that it = doesn't point > > > > >> out the crucial fact about leafref that the XPath expression = can only > > > > >> select elements that are instantiations of one particular = data node. > > > I > > > > >> don't know XPath, but it seems that that is not a general = property of > > > > >> XPath expressions, you seem to be able to write XPath = expressions that > > > > >> select heterogenous groups of elements. So it's worth = pointing out > > > that > > > > >> the allowed XPath expressions can't do that, and that is = because of > > > the > > > > >> restriction that the expression must match path-arg. > > > > > > > > > > Right, this is the slightly hand-waving part that I also = objected to. > > > An > > > > > XPath expression in a leafref's "path" statement indeed = selects a node > > > > > set from an instance data tree. The node seet can be empty, = but if it > > > is > > > > > non-empty, all its members necessarily have the same type, = which is > > > > > defined in a certain "leaf" schema node. > > > > > > > > > > The relationship is relatively straightforward but difficult = to explain > > > > > concisely. One basically has to follow the steps in the XPath > > > > > expression, ignore all path-predicates, and skip all schema = nodes that > > > > > aren't data nodes (i.e., "choice" and "case" nodes). > > > > > > > > Yes, it's difficult to explain, though once one gets the idea, = it's > > > > straightforward enough. The problem I have is that it's not = pointed out > > > > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but = I don't > > > > see it there.) > > > > > > > > The crucial points seem to be: > > > > > > > > - The XPath expression is limited by the syntax "path-arg" and = the rules > > > > in 9.9.2. > > > > > > > > - Because of those restrictions, there exists one data node in = the > > > > schema such that: evalutating the expression for any leaf or > > > > leaf-list node in any data tree returns a set of nodes, all of = which > > > > are instances of that one schema node. > > > > > > > > - The type of that schema node is the base type of the leafref. > > > > > > > > - Once you learn this, it's easy to see, for any particular > > > > leaf/leaf-list node and path expression in a module, which = schema node > > > > is the one. But it's rather hard to describe that process. > > > > > > > > Actually, there's an ugly question: If the path expression = references > > > > an element name that doesn't exist in the module. Perhaps there = are > > > > rules in XPath that prevent it, but it seems to me that you = could write > > > > > > > > leaf mgmt-interface { > > > > mandatory false; > > > > type leafref { > > > > path "../interface/name"; > > > > require-instance true; > > > > } > > > > } > > > > > > > > when the current module doesn't have a "name" child defined for > > > > "interface". As long as a data tree didn't contain a = mgmt-interface > > > > elememt, the constraint would not be violated. > > > > > > > > But a later revision of the module, the "name" child could be = added, > > > > allowing data trees to contain mgmt-interface elements, because = data > > > > trees could now have "name" elements. > > > > > > > > The point being that when you're figuring out which schema node = is the > > > > base type for the leafref, that schema node has to exist so the = base > > > > type can be extracted. But there's no direct statement of that = as a > > > > requirement for path validity. > > > > > > > > > > As WG chair, I am getting a bit nervous. We have to wrap things up = and > > > we need deliver the specification - it is past WG last call, it is > > > past IETF last call, it is past IESG approval (kind of). We can = likely > > > endlessly continue to search for possible ways to misunderstand = the > > > specification but lets remember the aphorism 'perfect is the enemy = of > > > good'. > > > > > > I leave it to Martin's discretion to decide whether he wants to = add > > > 'The referred leaf or leaf-list node in the schema tree MUST = exist.' > > > to the new text but I think the time has come to stop searching = for > > > new possible ways to misunderstand the specification. > > > > > > > > > > Doesn't the text above exclude a default leaf or leaf-list from the > > value space? That would be incorrect. > > >=20 > It says 'in the schema tree' so I think there is no problem. We were > discussing the corner case where the path argument does not point to a > schema node at all. Pyang already reports this as an error (bar in the > path of foo [...] is not found). >=20 >=20 > I thought the original issue was that the ABNF does not support = position-based > instance identifiers. In the rare event that the i-i pointed to a = config=3Dfalse > list entry (with no keys defined) then its position needs to be used. A more significant change was the addition of the "require-instance" = substatement to the leafref type. >=20 > I thought it was clear that the path-stmt has to point at a schema = node > that can be resolved in the module context using the import-stmts. An example: container top { leaf foo { type string; } container subtop { choice choi { leaf foo { type uint8; } case barcase { leaf bar { type leafref { path "../../foo"; } } } } } } Which of the two "foo" leaf nodes does the path argument point at? If = the path is interpreted in the schema tree, it may appear it is the one = inside the choice. Yes, we all know it points at the other one, but will = all readers of the spec come to the same conclusion? Lada >=20 > =20 > /js >=20 >=20 > Andy > =20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 8 03:29:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9B312B02F for ; Wed, 8 Jun 2016 03:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 vr4CtWetrPAW for ; Wed, 8 Jun 2016 03:29:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6618012D0E6 for ; Wed, 8 Jun 2016 03:29:41 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id B6C771AE0389; Wed, 8 Jun 2016 12:29:37 +0200 (CEST) Date: Wed, 08 Jun 2016 12:29:59 +0200 (CEST) Message-Id: <20160608.122959.190928208866332031.mbj@tail-f.com> To: worley@ariadne.com From: Martin Bjorklund In-Reply-To: <87shwq9cl7.fsf@hobgoblin.ariadne.com> References: <20160523.154309.848500367505009627.mbj@tail-f.com> <20160523.154309.848500367505009627.mbj@tail-f.com> <87shwq9cl7.fsf@hobgoblin.ariadne.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 10:29:44 -0000 Hi, worley@ariadne.com (Dale R. Worley) wrote: > (This is the second part of my response.) > > > > > > - section 6.1 > > > > > > > > > > This section details the rules for recognizing tokens from an input > > > > > stream. > > > > > > > > > > Generally, language definitions intersperse the narrative text with > > > > > the relevant grammar definitions. Yang's statement grammar is simple > > > > > enough that one doesn't need to see the context-free part of the > > > > > grammar to understand the narrative for statements. But when reading > > > > > about tokenization, not having the grammar presented at the same time > > > > > is quite a burden. I'd recommend duplicating the relevant productions > > > > > from section 14 into the subsections of section 6. > > > > > > > > > > There is some sort of exposition problem. The result of > > > > > "tokenization" is that the sequence of characters of the source is > > > > > converted into a sequence of "tokens". Then some subset of the tokens > > > > > is discarded as being non-significant (e.g., whitespace and comments), > > > > > and the remainder is parsed with a context-free grammar. Here I can't > > > > > figure out what the set of tokens is. Looking at the grammar in > > > > > section 14, it seems to be a context-free grammar on characters. But > > > > > that implies that there is no separate tokenization phase. > > > > > > > > > > An example that shows the problems: > > > > > > > > > > mod:ext > > > > > > > > > > Is this one token, which is also an extension keyword, or is it a > > > > > sequence of three tokens? > > > > > > > > The text says: > > > > > > > > A token in YANG is either a keyword, a string, a semicolon (";"), or > > > > braces ("{" or "}"). > > > > > > > > and: > > > > > > > > A keyword is [...] or a prefix identifier, followed by a colon > > > > (":"), followed by a language extension keyword. > > > > > > > > So "mod:ext" is one token. > > > > > > Certainly it can be one token. My question is how do verify that it is > > > not a string? I think that may be the origin of my confusion here is > > > that I haven't spotted a clear syntax for unquoted string. In most > > > programming languages, mod:ext would be parsed as an identifier, a > > > colon, and an identifier. In YANG, identifiers are usually tokenized as > > > strings, so I ask whether YANG tokenizes it as a string, a colon, and a > > > string. > > > > > > Looking at the beginning of 6.1.3, it doesn't appear that an unquoted > > > string is forbidden from containing a colon. > > > > > > I think that the underlying problem is that I'm not clear on what gets > > > tokenized as an unquoted string. > > > > Note that this is legal YANG: > > > > leaf type { > > type string; > > } > > So keywords aren't reserved; they can also be used as identifiers. Yes. > > I think there are two ways to look at this. Either we describe the > > tokenizer as being context-dependent, or we describe the "argument" in > > a "statement" to be a "string or keyword". > > > > In the latter case maybe we can do: > > > > OLD: > > > > If a string contains any space, tab, or newline characters, a single > > or double quote character, a semicolon (";"), braces ("{" or "}"), > > or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed > > within double or single quotes. > > > > NEW: > > > > An unquoted string is any sequence of characters that does not start > > with a double or single quote character, is not a keyword, and does > > not contain any space, tab, or newline characters, a single or > > double quote character, a semicolon (";"), braces ("{" or "}"), or > > comment sequences ("//", "/*", or "*/"). > > That's a lot clearer. Though you can shorten it to: > > An unquoted string is any sequence of characters that is not a > keyword, and does not contain any space, tab, or newline > characters, a single or double quote character, a semicolon (";"), > braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"). Thanks, better. > > In section 6.3 we must also do: > > > > OLD: > > > > The argument is a string, as defined in Section 6.1.2. > > > > NEW: > > > > The argument is a string or a keyword, as defined in Section 6.1.2. > > If I understand correctly, the tokens of Yang (as the term is usually > used in programming languages) are: > > whitespace (which is ignored) > comments (which is ignored) > single-quoted strings > double-quoted strings > unquoted strings (including keywords) > ; > { > } > > >From the point of view of the tokenizer, these tokens fall into the > obvious classes: > > type unquoted string > "type" double-quoted string > abc unquoted-string > "abc" double-quoted string > '---' single-quoted string > > I'm not quite sure how they are classified from the parser's point of > view, though. > > type "type" abc "abc" '---' > > Is a string? ? Y ? Y Y > (Can it appear as the > argument of "description"?) > > Is a keyword? Y ? N N N > (Can it appear as the first > token of some statement?) > > Is an identifier? Y ? Y ? N > (Can it appear as the second > token of a type statement?) > > Usually programming languages use the particular syntax of different > types of tokens to determine where they can be used in the > context-free grammar. Yang seems to be more relaxed, but I'm not sure > whether it is so relaxed thay any of the types of string tokens can be > used anywhere. No; a keyword must be written w/o quotes, so it is special. > > > > > -- it must be an unquoted string. > > > > > > > > > > If a double-quoted string contains a line break followed by space or > > > > > tab characters that are used to indent the text according to the > > > > > layout in the YANG file, this leading whitespace is stripped from the > > > > > string, up to and including the column of the double quote character, > > > > > or to the first non-whitespace character, whichever occurs first. In > > > > > this process, a tab character is treated as 8 space characters. > > > > > > > > > > This description isn't quite careful enough. Better: > > > > > > > > > > If a double-quoted string contains a line break followed by space or > > > > > tab characters, an initial part of this whitespace is removed from the > > > > > string. The amount removed is the longest prefix whose width is no > > > > > larger than the width of the prefix of Yang source line containing > > > > > the opening double quote character of the string to and including the > > > > > opening double quote character. For this purpose, the width of a > > > > > tab character is 8 and the width of any other character is 1. > > > > > > > > > > This does assume that all tabs are considered to have width 8, that > > > > > is, tabs do not have the usual semantics of "advance to the next > > > > > column that is divisible by 8". That will sometimes cause unexpected > > > > > results, e.g., if some source lines start with SPC TAB. (Consider > > > > > that whitespace before a line break is removed, which suggests the > > > > > intention is that the value of the string should depend only on its > > > > > visual appearance.) > > > > > > > > > > Also, we're using the convention that "whitespace" does NOT include CR > > > > > or LF, which is not always how the term is used. Perhaps a definition > > > > > of "whitespace" should be put in section 3. > > > > > > > > > > There is also the special case: > > > > > > > > > > SPC " LF > > > > > TAB x " > > > > > > > > > > Is the initial TAB of the second line to be removed or not? There is > > > > > no whitespace removal in the second line that will exactly reach the > > > > > opening double quote. As I've written it, the TAB is not removed. > > > > > > Don't forget this ugly special case. > > > > So, let's follow the rules. We need to trim to the column of the > > double quote character (2). The second line starts with "space or > > tab" so we do whitespace trimming, while treating the tab as 8 > > spaces. So from 8 spaces we subtract 2, and get the resulting string > > of 6 characters: > > > > LF SPC SPC SPC SPC SPC SPC x > > OK, but that process wasn't clear to me. I take it that any tab that > appears before the starting double-quote counts as 8 spaces, and any > tab that needs to be examined for deletion is turned into 8 spaces -- > but any other tabs in the string are unconverted. > > I think it would be clearer to insert "starting" where I've indicated > it, and replace the final sentence: > > If a double-quoted string contains a line break followed by space or > tab characters that are used to indent the text according to the > layout in the YANG file, this leading whitespace is stripped from the > string, up to and including the column of the >starting< double quote character, > or to the first non-whitespace character, whichever occurs first. > In this process, any tab character before the starting double quote > character is treated as 8 spaces. Any tab character in a succeeding > line that must be examined to for stripping is first converted into 8 > spaces. Ok, fixed. > > > Actually, there is a somewhat subtle problem: If I say "the system can > > > sort them any way it wants", I am asserting that *there is a sorting > > > order*. Which means that if value A is put before value B at one time, > > > then if values A and B are in the list at some other time, A will > > > precede B. > > > > The next sentences says: > > > > An implementation SHOULD use the same order for the same data, > > regardless of how the data were created. Using a deterministic > > order will make comparisons possible using simple tools like "diff". > > OK, I'm willing to go with that. I mis-read the application of those > sentences through an even more arcane ambiguity in the term "the same > data". But I'm willing to ignore that. > > > > > > - section 7.21.4 > > > > > > > > > > The "reference" statement takes as an argument a string ... > > > > > > > > > > Perhaps s/a string/a human-readable string/. > > > > > > > > "string" refers to the YANG token "string". The same wording is used > > > > across the document for all arguments. > > > > > > I was thinking that it is a string, but in this particular case, it is > > > supposed to be human-readable, whereas strings in other contexts aren't > > > expected to be. > > > > Ok. Maybe: > > > > OLD: > > > > The "reference" statement takes as an argument a string that is used > > to specify a textual cross-reference to an external document, > > > > NEW: > > > > The "reference" statement takes as an argument a string that is used > > to specify a human-readable cross-reference to an external document, > > Or even "is a human-readable cross-reference ...", but either is OK > with me. Ok. > > > > > - section 7.21.5 > > > > > > > > > > Note that if a data definition has both an "if-feature" and a "when", > > > > > then the "if-feature" is tested first. > > > > > > > > > > If the XPath expression references any node that also has associated > > > > > "when" statements, these "when" expressions MUST be evaluated first. > > > > > There MUST NOT be any circular dependencies in these "when" > > > > > expressions. > > > > > > > > > > I think this could be better phrased: > > > > > > > > > > If the XPath expression references any node that also has > > > > > associated "when" statements, then the "when" expressions of the > > > > > referenced nodes MUST be evaluated first. There MUST NOT be any > > > > > circular dependencies among "when" expressions. > > > > > > > > Ok to the last sentence. Do you think that the word "these" in the > > > > first sentence is ambigious? > > > > > > I must have thought it was unclear when I read it, otherwise I would not > > > have suggested changing it. But reading it again, I think that there is > > > no ambiguity. Perhaps it would be a little clearer to use 'those "when" > > > expressions' rather than 'these "when" expressions'. (I can't explain > > > clearly why "those" seems less ambiguous than "these".) > > > > Ok, as a non-native english speaker I trust you that "those" is better. > > I can't tell that you're non-native. Perhaps leave it as is and let > the RFC Editor review it. > > > > By implication, the leafref's value is considered to be a pointer to a > > > particular leaf instance, the one with the matching value. But that > > > idea is not embedded in the Yang semantics of leafref types in any way > > > (other than the output of the deref function), so the fact that there > > > might be more than one matching leaf instance does not matter. > > > > > > As stated in 9.9.4 and 9.9.5, the lexical representations of its values > > > are the same as those of the referenced nodes. > > > > > > How is the leafref's value compared to the values of the referenced > > > nodes? I can see that question getting ugly for the more complex types > > > (e.g., anyxml) > > > > You can't have a leafref to an anyxml node; just to a leaf or > > leaf-list. > > > > > which do not have canonical forms. I suspect the > > > intention is that values are equal if they have the same canonical form > > > > No, the idea is that they are equal if their *value* is equal, > > regardless of the lexical representation. > > There are two types that don't have a canonical form, identityref and > instance-identifier. It seems that comparisons in XPath expressions > are inexact if the type doesn't have a canonical form (section 6.4). > But if I understand you correctly, the implicit comparisons in leafref > are done based on the abstract values involved, not the lexical > representation. Yes. > > > The current ABNF doesn't allow for "+" for joining quoted strings. > > > Also, it doesn't show that \" can be included in a double quoted string > > > to include a literal ", and allows the string contents to continue -- > > > the current ABNF "DQUOTE string DQUOTE" matches "abcd\", despite that > > > the latter is not a proper double-quoted string. > > > > Note that the prose text (within <...>) says "a string that > > matches...". That string can be any YANG token string, for example > > one of: > > > > "hello" > > "he" + "llo" > > If I haven't gotten confused, you're referring to > > string = < an unquoted string as returned by > > < the scanner, that matches the rule > > < yang-string > > > yang-string = *yang-char > > ;; any Unicode or ISO/IEC 10646 character including tab, carriage > ;; return, and line feed, but excluding the other C0 control > ;; characters, the surrogate blocks, and the noncharacters. > yang-char = %x09 / %x0A / %x0D / %x20-D7FF / > ; exclude surrogate blocks %xD800-DFFF > %xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF > %xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF > %x10000-1FFFD / ; exclude noncharacters %x1FFFE-1FFFF > %x20000-2FFFD / ; exclude noncharacters %x2FFFE-2FFFF > %x30000-3FFFD / ; exclude noncharacters %x3FFFE-3FFFF > %x40000-4FFFD / ; exclude noncharacters %x4FFFE-4FFFF > %x50000-5FFFD / ; exclude noncharacters %x5FFFE-5FFFF > %x60000-6FFFD / ; exclude noncharacters %x6FFFE-6FFFF > %x70000-7FFFD / ; exclude noncharacters %x7FFFE-7FFFF > %x80000-8FFFD / ; exclude noncharacters %x8FFFE-8FFFF > %x90000-9FFFD / ; exclude noncharacters %x9FFFE-9FFFF > %xA0000-AFFFD / ; exclude noncharacters %xAFFFE-AFFFF > %xB0000-BFFFD / ; exclude noncharacters %xBFFFE-BFFFF > %xC0000-CFFFD / ; exclude noncharacters %xCFFFE-CFFFF > %xD0000-DFFFD / ; exclude noncharacters %xDFFFE-DFFFF > %xE0000-EFFFD / ; exclude noncharacters %xEFFFE-EFFFF > %xF0000-FFFFD / ; exclude noncharacters %xFFFFE-FFFFF > %x100000-10FFFD ; exclude noncharacters %x10FFFE-10FFFF > > But if that's taken at face value, you can lex as single "string"s not only > > "hello" > > and > > "he" + "llo" > > but also > > "The MTU of the interface."; myext:c-define "MY_MTU" Why whould this be treated a single string? Note that line breaks are not special in YANG, so by the same logic, this example: description "The MTU of the interface."; reference "RFC XYZ"; would be scanned as the three tokens: description "The MTU of the interface."; reference "RFC XYZ" ; /martin > Doing that would allow the incorrect lexing of > > leaf mtu { > type uint32; > description "The MTU of the interface."; myext:c-define "MY_MTU"; > } > > as having a long description (starting with 'The MTU' and ending with > 'MY_MTU') and no myext:c-define statement. > > What we need is a production that matches "strings possibly combined > with +" and nothing else. That is, including '"he" + "llo"' but not the > last example. > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Jun 8 03:51:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A9F12D5FF for ; Wed, 8 Jun 2016 03:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 y0IJgTdiiY_V for ; Wed, 8 Jun 2016 03:51:10 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC4912B024 for ; Wed, 8 Jun 2016 03:51:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B949711CF; Wed, 8 Jun 2016 12:51:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id tic0SavXDTwq; Wed, 8 Jun 2016 12:51:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Jun 2016 12:51:07 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB22520050; Wed, 8 Jun 2016 12:51:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0LNs5S7naf9Z; Wed, 8 Jun 2016 12:51:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C66C20047; Wed, 8 Jun 2016 12:51:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1F5FC3B0CFF7; Wed, 8 Jun 2016 12:51:06 +0200 (CEST) Date: Wed, 8 Jun 2016 12:51:06 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160608105106.GB11455@elstar.local> Mail-Followup-To: Martin Bjorklund , worley@ariadne.com, netmod@ietf.org References: <20160523.154309.848500367505009627.mbj@tail-f.com> <20160523.154309.848500367505009627.mbj@tail-f.com> <87shwq9cl7.fsf@hobgoblin.ariadne.com> <20160608.122959.190928208866332031.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160608.122959.190928208866332031.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 10:51:11 -0000 On Wed, Jun 08, 2016 at 12:29:59PM +0200, Martin Bjorklund wrote: > > > Note that this is legal YANG: > > > > > > leaf type { > > > type string; > > > } > > > > So keywords aren't reserved; they can also be used as identifiers. > > Yes. > > That's a lot clearer. Though you can shorten it to: > > > > An unquoted string is any sequence of characters that is not a > > keyword, and does not contain any space, tab, or newline > > characters, a single or double quote character, a semicolon (";"), > > braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"). > > Thanks, better. The does the 'is not a keyword' not contratict the example shown above? My reading of the new suggested text would make me believe I would have to write the example as follows leaf "type" { type string; } which is different from the YANG 1.0 syntax rules I think. /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 Jun 8 04:16:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E26E12D0B1 for ; Wed, 8 Jun 2016 04:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 eymZibur3Frj for ; Wed, 8 Jun 2016 04:16:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 270B212B009 for ; Wed, 8 Jun 2016 04:16:10 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 23ED41AE0389; Wed, 8 Jun 2016 13:16:06 +0200 (CEST) Date: Wed, 08 Jun 2016 13:16:28 +0200 (CEST) Message-Id: <20160608.131628.1542286453242759050.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160608105106.GB11455@elstar.local> References: <87shwq9cl7.fsf@hobgoblin.ariadne.com> <20160608.122959.190928208866332031.mbj@tail-f.com> <20160608105106.GB11455@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 11:16:11 -0000 Juergen Schoenwaelder wrote: > On Wed, Jun 08, 2016 at 12:29:59PM +0200, Martin Bjorklund wrote: > > > > > Note that this is legal YANG: > > > > > > > > leaf type { > > > > type string; > > > > } > > > > > > So keywords aren't reserved; they can also be used as identifiers. > > > > Yes. > > > > That's a lot clearer. Though you can shorten it to: > > > > > > An unquoted string is any sequence of characters that is not a > > > keyword, and does not contain any space, tab, or newline > > > characters, a single or double quote character, a semicolon (";"), > > > braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"). > > > > Thanks, better. > > The does the 'is not a keyword' not contratict the example shown > above? My reading of the new suggested text would make me believe > I would have to write the example as follows > > leaf "type" { > type string; > } > > which is different from the YANG 1.0 syntax rules I think. Note that I also wrote: > > In section 6.3 we must also do: > > > > OLD: > > > > The argument is a string, as defined in Section 6.1.2. > > > > NEW: > > > > The argument is a string or a keyword, as defined in Section 6.1.2. The alternative is to keep the current text. But it means that the scanner is context-dependent (logically at least). IMO it doesn't really matter - this is just a conceptual explanation; an implementation is free to implement this in whatever clever way it wants. /martin From nobody Wed Jun 8 04:27:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4924D12B024 for ; Wed, 8 Jun 2016 04:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 B8TsiapqNopT for ; Wed, 8 Jun 2016 04:27:44 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF6D12B013 for ; Wed, 8 Jun 2016 04:27:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 5EF191E5D75; Wed, 8 Jun 2016 04:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bHfEoqF6rsPF; Wed, 8 Jun 2016 04:27:34 -0700 (PDT) Received: from [192.168.1.100] (host86-133-84-177.range86-133.btcentralplus.com [86.133.84.177]) by c8a.amsl.com (Postfix) with ESMTPSA id 7395D1E5D73; Wed, 8 Jun 2016 04:27:33 -0700 (PDT) From: William Lupton Content-Type: multipart/alternative; boundary="Apple-Mail=_0D9FFE06-7DB9-48EB-95AF-BBF796F6BF71" Date: Wed, 8 Jun 2016 12:27:41 +0100 To: netmod@ietf.org Message-Id: <04421D3F-E2FC-45BC-89AA-82C550706AC4@broadband-forum.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [netmod] Replacing a YANG submodule with a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 11:27:46 -0000 --Apple-Mail=_0D9FFE06-7DB9-48EB-95AF-BBF796F6BF71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Consider the YANG module, submodule and tree files shown below. Suppose = that I regret the decision to make =E2=80=9Csubmod=E2=80=9D be a = submodule and want to replace it with a module (see listings further = down). This works, the tree file is identical, and pyang = --check-update-from is happy, but strictly the interface has changed = (the util grouping has moved from the urn:bbf:yang:test namespace to the = urn:bbf:yang:mod namespace). Is this intended to be valid (I don=E2=80=99t= see it mentioned in RFC 6020bis Section 11)? Thanks, William % cat test@2016-01-01.yang submod@2016-01-01.yang test@2016-01-01.tree=20= module test { namespace "urn:bbf:yang:test"; prefix test; include submod { revision-date 2016-01-01; } revision 2016-01-01 { } uses util; } submodule submod { belongs-to test { prefix test; } revision 2016-01-01 { } grouping util { container util { } } } module: test +--rw util Replacements with submod -> mod: % cat test@2016-06-08.yang mod@2016-06-08.yang test@2016-06-08.tree=20 module test { namespace "urn:bbf:yang:test"; prefix test; import mod { prefix mod; revision-date 2016-06-08; } revision 2016-06-08 { } uses mod:util; } module mod { namespace "urn:bbf:yang:mod"; prefix mod; revision 2016-06-08 { } grouping util { container util { } } } module: test +--rw util pyang is happy: % pyang --check-update-from=3Dtest@2016-01-01.yang test@2016-06-08.yang= --Apple-Mail=_0D9FFE06-7DB9-48EB-95AF-BBF796F6BF71 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Consider the YANG module, submodule and tree files shown = below. Suppose that I regret the decision to make =E2=80=9Csubmod=E2=80=9D= be a submodule and want to replace it with a module (see listings = further down). This works, the tree file is identical, and pyang --check-update-from is = happy, but strictly the interface has changed (the util grouping has = moved from the urn:bbf:yang:test namespace to the urn:bbf:yang:mod namespace). = Is this intended to be valid (I don=E2=80=99t see it mentioned in RFC = 6020bis Section 11)?

Thanks,
William

module test {
  namespace = "urn:bbf:yang:test";
  prefix test;

  include submod = {
    = revision-date 2016-01-01;
  }

  revision 2016-01-01 {
  }

  = uses util;
}
submodule submod {
  belongs-to test {
    prefix test;
  }

  = revision 2016-01-01 {
  }

  grouping util {
    = container util {
    }
  }
}
module: test
   +--rw util

Replacements with = submod -> mod:

% cat test@2016-06-08.yang = mod@2016-06-08.yang = test@2016-06-08.tree 
module test {
  namespace = "urn:bbf:yang:test";
  prefix test;

  import mod = {
    = prefix mod;
  =   revision-date 2016-06-08;
  }

  revision = 2016-06-08 {
  }

  uses mod:util;
}
module mod {
  namespace = "urn:bbf:yang:mod";
  prefix mod;

  revision = 2016-06-08 {
  }

  grouping util {
    = container util {
    }
  }
}
module: test
   +--rw util

pyang is happy:

= --Apple-Mail=_0D9FFE06-7DB9-48EB-95AF-BBF796F6BF71-- From nobody Wed Jun 8 04:36:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B1112D1DA for ; Wed, 8 Jun 2016 04:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 4TNbf8rFYDVu for ; Wed, 8 Jun 2016 04:36:51 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B6B4412D0B5 for ; Wed, 8 Jun 2016 04:36:50 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 303641AE0389; Wed, 8 Jun 2016 13:36:49 +0200 (CEST) Date: Wed, 08 Jun 2016 13:37:11 +0200 (CEST) Message-Id: <20160608.133711.2260680881610374799.mbj@tail-f.com> To: wlupton@broadband-forum.org From: Martin Bjorklund In-Reply-To: <04421D3F-E2FC-45BC-89AA-82C550706AC4@broadband-forum.org> References: <04421D3F-E2FC-45BC-89AA-82C550706AC4@broadband-forum.org> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Replacing a YANG submodule with a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 11:36:53 -0000 V2lsbGlhbSBMdXB0b24gPHdsdXB0b25AYnJvYWRiYW5kLWZvcnVtLm9yZz4gd3JvdGU6DQo+IEhp LA0KPiANCj4gQ29uc2lkZXIgdGhlIFlBTkcgbW9kdWxlLCBzdWJtb2R1bGUgYW5kIHRyZWUgZmls ZXMgc2hvd24NCj4gYmVsb3cuIFN1cHBvc2UgdGhhdCBJIHJlZ3JldCB0aGUgZGVjaXNpb24gdG8g bWFrZSDigJxzdWJtb2TigJ0gYmUgYQ0KPiBzdWJtb2R1bGUgYW5kIHdhbnQgdG8gcmVwbGFjZSBp dCB3aXRoIGEgbW9kdWxlIChzZWUgbGlzdGluZ3MgZnVydGhlcg0KPiBkb3duKS4gVGhpcyB3b3Jr cywgdGhlIHRyZWUgZmlsZSBpcyBpZGVudGljYWwsIGFuZCBweWFuZw0KPiAtLWNoZWNrLXVwZGF0 ZS1mcm9tIGlzIGhhcHB5LCBidXQgc3RyaWN0bHkgdGhlIGludGVyZmFjZSBoYXMgY2hhbmdlZA0K PiAodGhlIHV0aWwgZ3JvdXBpbmcgaGFzIG1vdmVkIGZyb20gdGhlIHVybjpiYmY6eWFuZzp0ZXN0 IG5hbWVzcGFjZSB0bw0KPiB0aGUgdXJuOmJiZjp5YW5nOm1vZCBuYW1lc3BhY2UpLg0KDQpZb3Ug aGF2ZSByZW1vdmVkIHRoZSAidXRpbCIgZ3JvdXBpbmcgZnJvbSB0aGUgbW9kdWxlICJ0ZXN0Ii4g IFRoaXMgaXMNCm5vdCBhbGxvd2VkIGFjY29yZGluZyB0byB0aGUgdXBncmFkZSBydWxlcy4NCg0K KFNvIHllcywgdGhpcyBpcyBhIGJ1ZyBpbiBweWFuZyAtLWNoZWNrLXVwZGF0ZS1mcm9tOyBpdCBk b2Vzbid0IHdvcmsNCndlbGwgd2l0aCB0aGlzIGtpbmQgb2Ygc3RydWN0dXJhbCBjaGFuZ2UpDQoN Cg0KL21hcnRpbg0KDQoNCg0KPiBJcyB0aGlzIGludGVuZGVkIHRvIGJlIHZhbGlkIChJIGRvbuKA mXQNCj4gc2VlIGl0IG1lbnRpb25lZCBpbiBSRkMgNjAyMGJpcyBTZWN0aW9uIDExKT8NCj4gDQo+ IFRoYW5rcywNCj4gV2lsbGlhbQ0KPiANCj4gJSBjYXQgdGVzdEAyMDE2LTAxLTAxLnlhbmcgc3Vi bW9kQDIwMTYtMDEtMDEueWFuZyB0ZXN0QDIwMTYtMDEtMDEudHJlZSANCj4gbW9kdWxlIHRlc3Qg ew0KPiAgIG5hbWVzcGFjZSAidXJuOmJiZjp5YW5nOnRlc3QiOw0KPiAgIHByZWZpeCB0ZXN0Ow0K PiANCj4gICBpbmNsdWRlIHN1Ym1vZCB7DQo+ICAgICByZXZpc2lvbi1kYXRlIDIwMTYtMDEtMDE7 DQo+ICAgfQ0KPiANCj4gICByZXZpc2lvbiAyMDE2LTAxLTAxIHsNCj4gICB9DQo+IA0KPiAgIHVz ZXMgdXRpbDsNCj4gfQ0KPiBzdWJtb2R1bGUgc3VibW9kIHsNCj4gICBiZWxvbmdzLXRvIHRlc3Qg ew0KPiAgICAgcHJlZml4IHRlc3Q7DQo+ICAgfQ0KPiANCj4gICByZXZpc2lvbiAyMDE2LTAxLTAx IHsNCj4gICB9DQo+IA0KPiAgIGdyb3VwaW5nIHV0aWwgew0KPiAgICAgY29udGFpbmVyIHV0aWwg ew0KPiAgICAgfQ0KPiAgIH0NCj4gfQ0KPiBtb2R1bGU6IHRlc3QNCj4gICAgKy0tcncgdXRpbA0K PiANCj4gUmVwbGFjZW1lbnRzIHdpdGggc3VibW9kIC0+IG1vZDoNCj4gDQo+ICUgY2F0IHRlc3RA MjAxNi0wNi0wOC55YW5nIG1vZEAyMDE2LTA2LTA4LnlhbmcgdGVzdEAyMDE2LTA2LTA4LnRyZWUg DQo+IG1vZHVsZSB0ZXN0IHsNCj4gICBuYW1lc3BhY2UgInVybjpiYmY6eWFuZzp0ZXN0IjsNCj4g ICBwcmVmaXggdGVzdDsNCj4gDQo+ICAgaW1wb3J0IG1vZCB7DQo+ICAgICBwcmVmaXggbW9kOw0K PiAgICAgcmV2aXNpb24tZGF0ZSAyMDE2LTA2LTA4Ow0KPiAgIH0NCj4gDQo+ICAgcmV2aXNpb24g MjAxNi0wNi0wOCB7DQo+ICAgfQ0KPiANCj4gICB1c2VzIG1vZDp1dGlsOw0KPiB9DQo+IG1vZHVs ZSBtb2Qgew0KPiAgIG5hbWVzcGFjZSAidXJuOmJiZjp5YW5nOm1vZCI7DQo+ICAgcHJlZml4IG1v ZDsNCj4gDQo+ICAgcmV2aXNpb24gMjAxNi0wNi0wOCB7DQo+ICAgfQ0KPiANCj4gICBncm91cGlu ZyB1dGlsIHsNCj4gICAgIGNvbnRhaW5lciB1dGlsIHsNCj4gICAgIH0NCj4gICB9DQo+IH0NCj4g bW9kdWxlOiB0ZXN0DQo+ICAgICstLXJ3IHV0aWwNCj4gDQo+IHB5YW5nIGlzIGhhcHB5Og0KPiAN Cj4gJSBweWFuZyAtLWNoZWNrLXVwZGF0ZS1mcm9tPXRlc3RAMjAxNi0wMS0wMS55YW5nIHRlc3RA MjAxNi0wNi0wOC55YW5nDQo= From nobody Wed Jun 8 04:38:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF4112D54B for ; Wed, 8 Jun 2016 04:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qenD_YGUUqsC for ; Wed, 8 Jun 2016 04:38:31 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C5F5B128874 for ; Wed, 8 Jun 2016 04:38:30 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 4B32A1CC024F; Wed, 8 Jun 2016 13:38:31 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Juergen Schoenwaelder , Andy Bierman , "Dale R. Worley" , "netmod\@ietf.org" In-Reply-To: References: <87ziqx81h0.fsf@hobgoblin.ariadne.com> <20160607155258.GA9796@elstar.local> <20160607163831.GB9870@elstar.local> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 08 Jun 2016 13:38:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 11:38:34 -0000 OK, let's bite the bullet: OLD The "path" statement, which is a substatement to the "type" statement, MUST be present if the type is "leafref". It takes as an argument a string that MUST refer to a leaf or leaf-list node. The syntax for a path argument is a subset of the XPath abbreviated syntax. Predicates are used only for constraining the values for the key nodes for list entries. Each predicate consists of exactly one equality test per key, and multiple adjacent predicates MAY be present if a list has multiple keys. The syntax is formally defined by the rule "path-arg" in Section 14. NEW The "path" statement, which is a substatement to the "type" statement, MUST be present if the type is "leafref". The syntax for its argument is formally defined by the rule "path-arg" in Section=C2=A014. The "path" statement is used in two ways: 1. It refers to another "leaf" node that is obtained by treating the "path" argument as a path in the schema tree. If the argument begins with the slash character ("/"), i.e., corresponds to the ABNF rule "absolute-path", the path starts at the root of the schema tree, otherwise it starts at the current "leaf" node with the "leafref" type. The steps along this path are performed by interpreting each of the slash-separated components of the "path" argument as follows: o If the component is the double-dot string (".."), go to the closest schema tree ancestor that is a data node or schema root. o Otherwise, the component contains a data node identifier and an optional path predicate enclosed in square brackets. Go to the data child (see below) whose name is the data node identifier. A data child of data node N is a descendant node in the schema tree for which node N is the closest ancestor that is a data node. The path predicate, if present, is ignored. The "leaf" node to which the "path" argument refers MUST exist in the schema tree. 2. If the "require-instance" property (Section 9.9.3) is "true", the "path" argument is evaluated as an XPath expression once for each instance of the "leaf" with the "leafref" type. The result of every such evaluation MUST be a non-empty node set. Path predicates are used only for specifying the values for the key nodes for list entries. Each predicate consists of exactly one equality test per key, and multiple adjacent predicates MAY be present if a list has multiple keys. Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 8 04:49:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2682D12B024 for ; Wed, 8 Jun 2016 04:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 KLj1XM_Kn715 for ; Wed, 8 Jun 2016 04:49:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB1A12D1EA for ; Wed, 8 Jun 2016 04:49:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1B335FE4; Wed, 8 Jun 2016 13:49:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lnoK_VPbcKgF; Wed, 8 Jun 2016 13:48:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 8 Jun 2016 13:48:58 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A92420047; Wed, 8 Jun 2016 13:48:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XRQ-sD70otDl; Wed, 8 Jun 2016 13:48:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9BDC20050; Wed, 8 Jun 2016 13:48:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 887E63B0D2BF; Wed, 8 Jun 2016 13:48:56 +0200 (CEST) Date: Wed, 8 Jun 2016 13:48:56 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160608114856.GB11574@elstar.local> Mail-Followup-To: Martin Bjorklund , worley@ariadne.com, netmod@ietf.org References: <87shwq9cl7.fsf@hobgoblin.ariadne.com> <20160608.122959.190928208866332031.mbj@tail-f.com> <20160608105106.GB11455@elstar.local> <20160608.131628.1542286453242759050.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160608.131628.1542286453242759050.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 11:49:03 -0000 On Wed, Jun 08, 2016 at 01:16:28PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Jun 08, 2016 at 12:29:59PM +0200, Martin Bjorklund wrote: > > > > > > > Note that this is legal YANG: > > > > > > > > > > leaf type { > > > > > type string; > > > > > } > > > > > > > > So keywords aren't reserved; they can also be used as identifiers. > > > > > > Yes. > > > > > > That's a lot clearer. Though you can shorten it to: > > > > > > > > An unquoted string is any sequence of characters that is not a > > > > keyword, and does not contain any space, tab, or newline > > > > characters, a single or double quote character, a semicolon (";"), > > > > braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"). > > > > > > Thanks, better. > > > > The does the 'is not a keyword' not contratict the example shown > > above? My reading of the new suggested text would make me believe > > I would have to write the example as follows > > > > leaf "type" { > > type string; > > } > > > > which is different from the YANG 1.0 syntax rules I think. > > Note that I also wrote: > > > > In section 6.3 we must also do: > > > > > > OLD: > > > > > > The argument is a string, as defined in Section 6.1.2. > > > > > > NEW: > > > > > > The argument is a string or a keyword, as defined in Section 6.1.2. > > The alternative is to keep the current text. But it means that the > scanner is context-dependent (logically at least). > > IMO it doesn't really matter - this is just a conceptual explanation; > an implementation is free to implement this in whatever clever way it > wants. OK. So in combination with the other text we achieve the same result. But personally, I think it is much clearer for an implementor if the definition of an unquoted string does not exclude keywords, the risk of getting inconsistencies later on scares me a bit. I rather would like to see something like this: An unquoted string is any sequence of characters and does not contain any space, tab, or newline characters, a single or double quote character, a semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"). Note that any keyword can legally appear as an unquoted string. YANG is indeed a bit special here and I believe it helps implementors to point this out right here where an unquoted string is defined. And 'the argument' is really a string and not a string or a keyword, which may lead to confusion or worse wrong interpretations (despite the fact that one might implement things this way). /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 Jun 8 05:08:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C5112D6A5; Wed, 8 Jun 2016 05:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ru1jo4Xvap1; Wed, 8 Jun 2016 05:08:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 65D6E12B01F; Wed, 8 Jun 2016 05:08:28 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 5126C1CC024F; Wed, 8 Jun 2016 14:08:29 +0200 (CEST) From: Ladislav Lhotka To: Lou Berger , netmod WG In-Reply-To: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 08 Jun 2016 14:08:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod-chairs@ietf.org" Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:08:31 -0000 Lou Berger writes: > All, > > We want to provide an update based on the off line discussions > related to OpState Solutions that we have been having and solicit > input from the WG. > > All authors of current solution drafts [1,2,3] together with those > who helped conduct the solutions analysis* were invited to the these > discussions -- with the objective of coming up with a single > consolidated proposal to bring to the WG. (I/Lou acted as facilitator > as Kent and Juergen were and are involved with the technical details.) > > The discussions have yielded some results but, unfortunately, > not a single consolidated proposal as hoped, but rather two > alternate directions -- and clearly we need to choose one: > > 1) Adopt the conventions for representing state/config > based on Section 6 of [1]. > > From a model definition perspective, these conventions > impact every model and every model writer. > > 2) Model OpState using a revised logical datastore definition > as introduced in [4] and also covered in [5]. There is > also a variant of this that we believe doesn't significantly > impact this choice. > > With this approach, model definitions need no explicit > changes to support applied configuration. > > From a technology/WG standpoint, we believe an approach > that doesn't impact every model written (i.e., #2) is superior. I agree. > The counterpoint to this is that the conventions based > approach (i.e., #1) is available today and being followed in > OpenConfig defined models. > > We would like to hear opinions on this from the WG before > declaring one of the following as the WG direction: > > A) models that wish to support applied configuration MUST > follow conventions based on [1] -- and the WG needs to > formalize these conventions. > or > B) no explicit support is required for models to support > applied configuration -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. I prefer B. Lada > > We intend to close on this choice before Berlin. > > Thank you, > Lou (and co-chairs) > > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > * - Chris H. and Acee L. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 8 05:38:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B71412D0FB for ; Wed, 8 Jun 2016 05:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7V3m5sk3Wj2 for ; Wed, 8 Jun 2016 05:38:18 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [IPv6:2001:1900:3001:11::28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D472212B005 for ; Wed, 8 Jun 2016 05:38:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 55BAA1E5D75; Wed, 8 Jun 2016 05:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k5WukloswwzD; Wed, 8 Jun 2016 05:38:08 -0700 (PDT) Received: from [192.168.1.100] (host86-133-84-177.range86-133.btcentralplus.com [86.133.84.177]) by c8a.amsl.com (Postfix) with ESMTPSA id 4133A1E5D73; Wed, 8 Jun 2016 05:38:07 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_2C8F7E56-C0B7-4233-9D5B-89ABCCAAD64E" From: William Lupton In-Reply-To: <20160608.133711.2260680881610374799.mbj@tail-f.com> Date: Wed, 8 Jun 2016 13:38:15 +0100 Message-Id: References: <04421D3F-E2FC-45BC-89AA-82C550706AC4@broadband-forum.org> <20160608.133711.2260680881610374799.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.2104) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Replacing a YANG submodule with a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 12:38:20 -0000 --Apple-Mail=_2C8F7E56-C0B7-4233-9D5B-89ABCCAAD64E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks. So the following would be valid I assume? Or (better because it = doesn=E2=80=99t change the module/submodule interface?) the second = option shown below (which simply defines a new module in order to make = the grouping externally accessible). Cheers, W. % cat test@2016-06-08.yang=20 module test { namespace "urn:bbf:yang:test"; prefix test; import mod { prefix mod; revision-date 2016-06-08; } revision 2016-06-08 { } grouping util { uses mod:util; } uses util; } Second option: % cat test@2016-06-09.yang submod@2016-06-09.yang mod@2016-06-09.yang = test@2016-06-09.tree=20 module test { namespace "urn:bbf:yang:test"; prefix test; include submod { revision-date 2016-06-09; } revision 2016-06-09 { } uses util; } submodule submod { belongs-to test { prefix test; } import mod { prefix mod; revision-date 2016-06-09; } revision 2016-06-09 { } grouping util { uses mod:util; } } module mod { namespace "urn:bbf:yang:mod"; prefix mod; revision 2016-06-09 { } grouping util { container util { } } } module: test +--rw util > On 8 Jun 2016, at 12:37, Martin Bjorklund wrote: >=20 > William Lupton wrote: >> Hi, >>=20 >> Consider the YANG module, submodule and tree files shown >> below. Suppose that I regret the decision to make =E2=80=9Csubmod=E2=80= =9D be a >> submodule and want to replace it with a module (see listings further >> down). This works, the tree file is identical, and pyang >> --check-update-from is happy, but strictly the interface has changed >> (the util grouping has moved from the urn:bbf:yang:test namespace to >> the urn:bbf:yang:mod namespace). >=20 > You have removed the "util" grouping from the module "test". This is > not allowed according to the upgrade rules. >=20 > (So yes, this is a bug in pyang --check-update-from; it doesn't work > well with this kind of structural change) >=20 >=20 > /martin >=20 >=20 >=20 >> Is this intended to be valid (I don=E2=80=99t >> see it mentioned in RFC 6020bis Section 11)? >>=20 >> Thanks, >> William >>=20 >> % cat test@2016-01-01.yang submod@2016-01-01.yang = test@2016-01-01.tree=20 >> module test { >> namespace "urn:bbf:yang:test"; >> prefix test; >>=20 >> include submod { >> revision-date 2016-01-01; >> } >>=20 >> revision 2016-01-01 { >> } >>=20 >> uses util; >> } >> submodule submod { >> belongs-to test { >> prefix test; >> } >>=20 >> revision 2016-01-01 { >> } >>=20 >> grouping util { >> container util { >> } >> } >> } >> module: test >> +--rw util >>=20 >> Replacements with submod -> mod: >>=20 >> % cat test@2016-06-08.yang mod@2016-06-08.yang test@2016-06-08.tree=20= >> module test { >> namespace "urn:bbf:yang:test"; >> prefix test; >>=20 >> import mod { >> prefix mod; >> revision-date 2016-06-08; >> } >>=20 >> revision 2016-06-08 { >> } >>=20 >> uses mod:util; >> } >> module mod { >> namespace "urn:bbf:yang:mod"; >> prefix mod; >>=20 >> revision 2016-06-08 { >> } >>=20 >> grouping util { >> container util { >> } >> } >> } >> module: test >> +--rw util >>=20 >> pyang is happy: >>=20 >> % pyang --check-update-from=3Dtest@2016-01-01.yang = test@2016-06-08.yang --Apple-Mail=_2C8F7E56-C0B7-4233-9D5B-89ABCCAAD64E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks. So the following would = be valid I assume? Or (better because it doesn=E2=80=99t change the = module/submodule interface?) the second option shown below (which simply = defines a new module in order to make the grouping externally = accessible). Cheers, W.

% cat test@2016-06-08.yang 
module test {
  namespace = "urn:bbf:yang:test";
  prefix test;

  import mod = {
    = prefix mod;
  =   revision-date 2016-06-08;
  }

  revision = 2016-06-08 {
  }

  grouping util {
    uses = mod:util;
  = }

  uses util;
}

Second option:

module test {
  namespace = "urn:bbf:yang:test";
  prefix test;

  include submod = {
    = revision-date 2016-06-09;
  }

  revision 2016-06-09 {
  }

  = uses util;
}
submodule submod {
  belongs-to test {
    prefix test;
  }

  = import mod {
    prefix mod;
    revision-date 2016-06-09;
  }

  = revision 2016-06-09 {
  }

  grouping util {
    uses = mod:util;
  = }
}
module mod {
  namespace = "urn:bbf:yang:mod";
  prefix mod;

  revision = 2016-06-09 {
  }

  grouping util {
    = container util {
    }
  }
}
module: test
   +--rw util

On = 8 Jun 2016, at 12:37, Martin Bjorklund <mbj@tail-f.com> = wrote:

William Lupton <wlupton@broadband-forum.org> wrote:
Hi,

Consider the YANG module, submodule and tree files shown
below. Suppose that I regret the decision to make = =E2=80=9Csubmod=E2=80=9D be a
submodule and want to = replace it with a module (see listings further
down). This = works, the tree file is identical, and pyang
--check-update-from is happy, but strictly the interface has = changed
(the util grouping has moved from the = urn:bbf:yang:test namespace to
the urn:bbf:yang:mod = namespace).

You have removed = the "util" grouping from the module "test".  This is
not allowed according to the upgrade rules.

(So yes, this is a bug in pyang --check-update-from; it = doesn't work
well with this kind of structural change)


/martin



Is this intended to be valid (I don=E2=80=99t
see= it mentioned in RFC 6020bis Section 11)?

Thanks,
William

% = cat test@2016-01-01.yang submod@2016-01-01.yang test@2016-01-01.tree 
module test {
 namespace "urn:bbf:yang:test";
 prefix= test;

 include submod {
   revision-date 2016-01-01;
 }
 revision 2016-01-01 {
 }

 uses util;
}
submodule submod {
 belongs-to test {
   prefix = test;
 }

 revision = 2016-01-01 {
 }

 grouping util {
   container = util {
   }
 }
}
module: test
  +--rw = util

Replacements with submod -> mod:

% cat test@2016-06-08.yang mod@2016-06-08.yang test@2016-06-08.tree 
module test {
 namespace "urn:bbf:yang:test";
 prefix= test;

 import mod {
   prefix mod;
  =  revision-date 2016-06-08;
 }

 revision 2016-06-08 {
 }

 uses mod:util;
}
module mod {
 namespace = "urn:bbf:yang:mod";
 prefix mod;

 revision 2016-06-08 {
 }

 grouping util {
  =  container util {
   }
 }
}
module: test
  +--rw util

pyang is = happy:

% pyang --check-update-from=3Dtest@2016-01-01.yang test@2016-06-08.yang

= --Apple-Mail=_2C8F7E56-C0B7-4233-9D5B-89ABCCAAD64E-- From nobody Wed Jun 8 07:48:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D2112D1DD for ; Wed, 8 Jun 2016 07:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 t7X6NsVKco10 for ; Wed, 8 Jun 2016 07:47:59 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 2CCDA12D635 for ; Wed, 8 Jun 2016 07:47:58 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-01v.sys.comcast.net with SMTP id AekMb16ly13YVAelybn1Zu; Wed, 08 Jun 2016 14:47:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465397278; bh=/VQ95STqYjtr2MIDKpecj384iV00zcC9eDusl/4iBNs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=sfOs0RgFyqPXd/KB6NRjpqjdxLqHpssO7Q4hQmpHUQGUTaTrOQYNqbQZsWIZ5BYlN 2CVo8XGUjFpyMSD3OSYqvZpHd359bvwLkoz/8OyTD9QVjP2FeXWf01aAKI5dKjWwBl Lkxuk2ayJDfZ4hNqp9ByuSlZY1swizoN16GwMlZgyTOrajjmNy5nsfJSHSGGz6B2hC h/uS85bILjrBlke2fgzF3PbIak3tsy9YgxBtnOKORA9B9sBMFnl/bWOhiM3SAoeYJC WOQnRlxharMKuk+Lh0JHB7Nug3kIrrgY9+oeBwFU18kT3mlxlpNmiqXyRtHSaDqLIh 3se98WwUS1mHQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-20v.sys.comcast.net with comcast id 4Enx1t00E1nMCLR01Enxhd; Wed, 08 Jun 2016 14:47:58 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u58Elu4e027753; Wed, 8 Jun 2016 10:47:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u58Elu1a027750; Wed, 8 Jun 2016 10:47:56 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: William Lupton In-Reply-To: <04421D3F-E2FC-45BC-89AA-82C550706AC4@broadband-forum.org> (wlupton@broadband-forum.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 08 Jun 2016 10:47:56 -0400 Message-ID: <87mvmv7n4z.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Replacing a YANG submodule with a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:48:00 -0000 William Lupton writes: > Consider the YANG module, submodule and tree files shown > below. Suppose that I regret the decision to make "submod" be a > submodule and want to replace it with a module (see listings further > down). This works, the tree file is identical, and pyang > --check-update-from is happy, but strictly the interface has changed > (the util grouping has moved from the urn:bbf:yang:test namespace to > the urn:bbf:yang:mod namespace). Is this intended to be valid (I don't > see it mentioned in RFC 6020bis Section 11)? I'm not sure what a "tree file" is. But it turns out that the XML for data trees doesn't change. The reason for that is that in the second example, the util *grouping* is in the module mod, but the schema node (which is the prototype of an XML element in a data tree) is in the module test, where the uses statement is, and so the "util" XML element will be in the XML namespace of module test. See section 7.13: The identifiers defined in the grouping are not bound to a namespace until the contents of the grouping are added to the schema tree via a "uses" statement that does not appear inside a "grouping" statement, at which point they are bound to the namespace of the current module. In regard to assigning schema nodes to an XML namespace, the uses acts like a macro expansion, while in regard to resolving references to Yang identifiers, uses/grouping is lexically scoped. Martin Bjorklund writes: > You have removed the "util" grouping from the module "test". This is > not allowed according to the upgrade rules. ["upgrade" means "updating" and refers to section 11.] If I understand Yang correctly, that error can't be fixed by revising the new module test to clone mod:util as test:util, because though the new grouping is semantically identical to the old grouping, it's still a change in its definition: module test { namespace "urn:bbf:yang:test"; prefix test; import mod { prefix mod; revision-date 2016-06-08; } revision 2016-06-08 { } uses mod:util; + grouping util { + uses mod:util; + } } Dale From nobody Wed Jun 8 07:59:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABA912D6A8 for ; Wed, 8 Jun 2016 07:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 LXBkj2gVtYRm for ; Wed, 8 Jun 2016 07:59:53 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 8318212D645 for ; Wed, 8 Jun 2016 07:59:53 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-07v.sys.comcast.net with SMTP id AewubrRXMrtfLAexUbHdlV; Wed, 08 Jun 2016 14:59:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465397992; bh=gjaml1DJVGreN3DK7IavwBoONeBto/C4qiMPyklmshE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=gg9Q5CFmZOFVDdRu8CcrM/8XsfEFwWObAnMSpMFbNqXrXWrBSwBKntjMgUfPp2kHX 1/ioGuEBbs1gmsFNoIo97fLN7kKodFBb0P+kyH8dmdB2fmVeELFIKOwmMnrqGzTJEs tfQ9AYRsi95kAJlljqBhXQnmlOocm9cUoeLszRDb7z9Tf79Q73nNHsMOguhIa0YvB/ 2Z5AV86IY+gsbXtNxAR7ccgO2asuszEAaXE6M9JcL6vDHWy2mnka/Hz+6Ws7uw4+J9 lwzXpP5vMehRGPUyz5bn2KWvgWf7w5MMVrg7jzq/AhKKipvrPdojPB6wwS8e5MOWsw FthEVj6hCoCxA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-19v.sys.comcast.net with comcast id 4Ezs1t0011nMCLR01Ezs3N; Wed, 08 Jun 2016 14:59:52 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u58ExpHI028955 for ; Wed, 8 Jun 2016 10:59:51 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u58Exphg028952; Wed, 8 Jun 2016 10:59:51 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org In-Reply-To: <87ziqx81h0.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 08 Jun 2016 10:59:51 -0400 Message-ID: <87k2hz7ml4.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 14:59:54 -0000 worley@ariadne.com (Dale R. Worley) writes: > [...] > Yes, it's difficult to explain, though once one gets the idea, it's > straightforward enough. The problem I have is that it's not pointed out > explicitly anywhere. (E.g., Juergen suggests section 9.9.2, but I don't > see it there.) > > The crucial points seem to be: > > - The XPath expression is limited by the syntax "path-arg" and the rules > in 9.9.2. > > - Because of those restrictions, there exists one data node in the > schema such that: evalutating the expression for any leaf or > leaf-list node in any data tree returns a set of nodes, all of which > are instances of that one schema node. Interestingly, there's a sort-of dependency on the fact that grouping/uses can't be recursive. If I could define a general binary tree data structure: grouping tree-grouping { container left-child { uses tree-grouping; } container right-child { uses tree-grouping; } leaf data1 { type string; } leaf data2 { type leafref { path "../left-child/data1"; } } } container a { use tree-grouping; container left-child { leaf data1 { type integer; } } } statically validating the leafref would take a clever algorithm, because the parent element of a data2 element can be a left-child container, a right-child container, or an 'a' container. But since groupings cannot be instantiated recursively, the validator can "macro expand" all 'uses' statements and then validate every instance of the leaf data2; for each instance of data2, the parent element is unique, making interpretation of the path simple. Dale From nobody Wed Jun 8 08:20:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762DB12D5FB; Wed, 8 Jun 2016 08:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 0wusLWaQsBBN; Wed, 8 Jun 2016 08:20:39 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id DB36912D131; Wed, 8 Jun 2016 08:20:38 -0700 (PDT) Received: from tops.chopps.org (24-247-68-31.dhcp.trcy.mi.charter.com [24.247.68.31]) (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 D401A61034; Wed, 8 Jun 2016 15:20:37 +0000 (UTC) References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <20160608.094518.235671744205955797.mbj@tail-f.com> User-agent: mu4e 0.9.16; emacs 24.5.1 From: To: Martin Bjorklund In-reply-to: <20160608.094518.235671744205955797.mbj@tail-f.com> Date: Wed, 08 Jun 2016 11:20:36 -0400 Message-ID: <87r3c7zozf.fsf@tops.chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 15:20:41 -0000 --=-=-= Content-Type: text/plain Martin Bjorklund writes: > Andy Bierman wrote: >> Hi, >> >> I prefer (B). > > For the record, I also prefer B. I also prefer B. In addition to the points below, it also "Just Works" for all existing and future models including ones designed outside of the purview of the IETF. Thanks, Chris. > > B is a more robust solution, since it can handle not only intended and > applied, but also other existing (e.g. startup) and future > (e.g. ephemeral) datastores. > > > /martin > > >> I do not think it is realistic that vendors will rewrite their IETF >> modules and vendor modules and all the associated client/server >> instrumentation. >> This is expensive at many levels. Stability is important for an API. >> >> So if we do (A), there will be some modules following the convention >> and the rest using proprietary RPC-based solutions. >> But if we do (B), vendors can integrate the standard RPC-based solution >> into their existing running code with zero disturbance. >> >> >> Andy >> >> >> >> On Tue, Jun 7, 2016 at 7:19 AM, Lou Berger wrote: >> >> > All, >> > >> > We want to provide an update based on the off line discussions >> > related to OpState Solutions that we have been having and solicit >> > input from the WG. >> > >> > All authors of current solution drafts [1,2,3] together with those >> > who helped conduct the solutions analysis* were invited to the these >> > discussions -- with the objective of coming up with a single >> > consolidated proposal to bring to the WG. (I/Lou acted as facilitator >> > as Kent and Juergen were and are involved with the technical details.) >> > >> > The discussions have yielded some results but, unfortunately, >> > not a single consolidated proposal as hoped, but rather two >> > alternate directions -- and clearly we need to choose one: >> > >> > 1) Adopt the conventions for representing state/config >> > based on Section 6 of [1]. >> > >> > From a model definition perspective, these conventions >> > impact every model and every model writer. >> > >> > 2) Model OpState using a revised logical datastore definition >> > as introduced in [4] and also covered in [5]. There is >> > also a variant of this that we believe doesn't significantly >> > impact this choice. >> > >> > With this approach, model definitions need no explicit >> > changes to support applied configuration. >> > >> > >From a technology/WG standpoint, we believe an approach >> > that doesn't impact every model written (i.e., #2) is superior. >> > The counterpoint to this is that the conventions based >> > approach (i.e., #1) is available today and being followed in >> > OpenConfig defined models. >> > >> > We would like to hear opinions on this from the WG before >> > declaring one of the following as the WG direction: >> > >> > A) models that wish to support applied configuration MUST >> > follow conventions based on [1] -- and the WG needs to >> > formalize these conventions. >> > or >> > B) no explicit support is required for models to support >> > applied configuration -- and that the WG needs to >> > formalize an opstate solution based on the approach >> > discussed in [4] and [5]. >> > >> > We intend to close on this choice before Berlin. >> > >> > Thank you, >> > Lou (and co-chairs) >> > >> > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 >> > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 >> > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 >> > [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 >> > [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 >> > * - Chris H. and Acee L. >> > >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXWDfEAAoJEC4dgw7XuDAlOeMP/RqNtFlVv6pne5b68O/8aQkt kszQktYwGyRq051csiHmWire1ubLQuuTjh+m1lijGreaR95X31IOEhX6ulHU0tET cXuJtrSifaZ2G2mNFmOJlvR5awY0a+30XrpuHHRhfwdB4usiobPhEknIfiXkR7cW Vo7J+LF97bmj6R/pABzNLz9xNBw5DLRi5+HSSAJhOjhSKDkTJ3AE+SxbWXV6UTYK CSDMcEr2gsUoQN11K7oJixYoBTAI2X4KznCL3lpQI1uVR3T1092D0K2s+ye2df1S IcqAAY6EO5gvkZof3owbbliv4c9XeskiofIq/u2BK00KE4ZH+dStpzeggxR1AQip wtUO7gaTlRDTjUXZclCWmzQwq/MsoWTsfyq5m5XpL3XK5tdioM5dr9DuaobukZ0k ImlX53VsMT6vJi55HSjbWmYbpl42PAXqmxSOizb7E4J/XNSPR+hyxllbprMLF8tz CfQNh+4rLywnQE3LIQ6kny/Mw6LdHg69+5H+iO230fFRGsjoK2njL4NT+LxHXjZa gRdLzvFoT2tsClCH1q9Cb0Ff2sZl0v2cULFhA8EeyWHBx0FPL38kbncsRwkxOh2a QZfSCzVOzJYdZrpckjEhRMjOlbZS+rvvGgNbIjb23pUYBXu1Ug84QcWz54FHSwxN mICasWlclZ/uRb+xUcnA =JeIs -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 8 08:22:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032D912D698 for ; Wed, 8 Jun 2016 08:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 T3_C1WcH2uZq for ; Wed, 8 Jun 2016 08:22:42 -0700 (PDT) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (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 75B6E12D645 for ; Wed, 8 Jun 2016 08:22:42 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-01v.sys.comcast.net with SMTP id AfI3bmGKQkzylAfJZbJASr; Wed, 08 Jun 2016 15:22:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465399361; bh=1xG3MSAUUYVvefib0uRT3lZB250LNB/ZbBT30FdEXTs=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=UQySTUHhczVVbD3QB9F31iCah1W83miw+QYwjhP8OFdxVDa0wPOMtQPVnGh2p59bz UhFhlExDPHlCB5wSfDJEtksOCFxEYwh8Lk/fnCisQma/qJscRBD1QYUI3FLC8qSUq7 xQS4FhUKXY0pxB4p642FtOOJLUH8+ONGH8nWX7aDktD5QuFfyEqaKZTVWHqjTCs1Ur IzjP4mg27x/6WxAuQ5/PTqjPd9eooBQ2+bZ9FuWoOoBDpB0inj0q86VaAwDIaf4y+M E/kBZKMM8nrInYD8rT2wbOZUaD1OS6aCbwlORAQGr8aZBKc7R5XrZPGtrPTT+nqkew WjIferZPNQa5Q== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-14v.sys.comcast.net with comcast id 4FNf1t00L1nMCLR01FNgmp; Wed, 08 Jun 2016 15:22:40 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u58FMdHV031251; Wed, 8 Jun 2016 11:22:39 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u58FMb41031246; Wed, 8 Jun 2016 11:22:37 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund In-Reply-To: <20160608.095115.1337034559082416025.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 08 Jun 2016 11:22:37 -0400 Message-ID: <87fusn7lj6.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 15:22:44 -0000 Martin Bjorklund writes: > The text for "path" already says: > > It takes as an argument a > string that MUST refer to a leaf or leaf-list node. Given what the text must mean, that's sufficient for me. Ladislav Lhotka writes: > Which of the two "foo" leaf nodes does the path argument point at? If > the path is interpreted in the schema tree, it may appear it is the > one inside the choice. Yes, we all know it points at the other one, > but will all readers of the spec come to the same conclusion? Well, in 9.9.2 it says: The "path" XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1: o If the "path" statement is defined within a typedef, the context node is the leaf or leaf-list node in the data tree that references the typedef. o Otherwise, the context node is the node in the data tree for which the "path" statement is defined. What's really going on is that the XPath expression will always be evaluated in the context of a particular element of a particular data tree, but that it can be shown to be always valid by doing a "generic evaluation" of the expression looking at the schema tree -- the schema tree is a generic description of all possible data trees. Of course there are various complications because not all nodes in the schema tree are represented in the XML tree. In mathematics, abstracting an operation in a particular structure to a similar operation in a "generic" structure is called "lifting", and using that term, it's easy to notify the reader what you're doing without spelling out the details. What's difficult here is that it's "obvious" what the text has to mean, but we have no simple vocabulary for pointing that out, and the reader who is not careful might not realize everything that is going on. At this point, I'm willing to ignore the issue. There doesn't seem to be a simple way to explain the critical issue. And if the reader attempts to work out the details of Yang processing, he eventually has to come to the correct conclusion; there is only one self-consistent interpretation. Dale From nobody Wed Jun 8 10:29:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988B012D73F; Wed, 8 Jun 2016 10:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 wk4yOAT2HyJV; Wed, 8 Jun 2016 10:29:43 -0700 (PDT) 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 A456F12D0C8; Wed, 8 Jun 2016 10:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6442; q=dns/txt; s=iport; t=1465406983; x=1466616583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WnpkF537ttWm3nEl8l/MmZljTOM4pJrTjzaRlNFqdLA=; b=K18EQzfpo6Dw0JC9YBBV65k/UfA1Ey8Z0PPanFH0XkGleU27SEM7HfNH vUGDVvyISftpJJ9fLIiKzw8XRu2cMi0vnjbo7CYyAFQKWSjC5UvqleOkI vxRw/MyfCg9Eto23waLtqSdKcSJ8i0D3tJ6A9+uqhTKt+d4T6BQWUtHjZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgDhVFhX/5RdJa1egz5WfQa7BoF5F?= =?us-ascii?q?wuFJ0oCHIElOBQBAQEBAQEBZSeERgEBBAEBASAROgsQAgEIGAICJgICAiULFRA?= =?us-ascii?q?CBAENBRuIFA6sRpEZAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYlzgSKDCIMXg?= =?us-ascii?q?lkFmE8BhgKII4FpjTaGPYkjAR42g25uiRB/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,440,1459814400"; d="scan'208";a="112966525" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jun 2016 17:29:42 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u58HTgSU010611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jun 2016 17:29:42 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.1104.5; Wed, 8 Jun 2016 13:29:42 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 8 Jun 2016 13:29:41 -0400 From: "Acee Lindem (acee)" To: "chopps@chopps.org" , Martin Bjorklund Thread-Topic: [netmod] Opstate solutions discussions: update and request for WG input Thread-Index: AQHRwZlfEbEN+JgX3EmzQHX8fEe3dp/f03QA Date: Wed, 8 Jun 2016 17:29:41 +0000 Message-ID: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <20160608.094518.235671744205955797.mbj@tail-f.com> <87r3c7zozf.fsf@tops.chopps.org> In-Reply-To: <87r3c7zozf.fsf@tops.chopps.org> 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="utf-8" Content-ID: <46D7F7E8C957AB48BB0A5DFD9B58D1C5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 17:29:45 -0000 SSBhZ3JlZSB0aGF0IG9wdGlvbiBCIGlzIHRoZSBiZXN0IHdheSBmb3J3YXJkLiBUaGUgc29vbmVy IHdlIHJlYWNoIHRoZQ0KY29uc2Vuc3VzIHRoZSBzb29uZXIgd2UgY2FuIGRpc2N1c3MgaG93IHRo aXMgY2FuIHNpbXBseSBtb2RlbHMgdGhhdCBhcmUNCndhaXRpbmcgZm9yIHRoZSBJRVRGIE9wc1N0 YXRlIGRpcmVjdGlvbi4NClRoYW5rcywNCkFjZWUgDQoNCk9uIDYvOC8xNiwgMTE6MjAgQU0sICJu ZXRtb2Qgb24gYmVoYWxmIG9mIGNob3Bwc0BjaG9wcHMub3JnIg0KPG5ldG1vZC1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBjaG9wcHNAY2hvcHBzLm9yZz4gd3JvdGU6DQoNCj4NCj5NYXJ0 aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JpdGVzOg0KPg0KPj4gQW5keSBCaWVybWFu IDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPj4+IEhpLA0KPj4+DQo+Pj4gSSBwcmVmZXIg KEIpLg0KPj4NCj4+IEZvciB0aGUgcmVjb3JkLCBJIGFsc28gcHJlZmVyIEIuDQo+DQo+SSBhbHNv IHByZWZlciBCLg0KPg0KPkluIGFkZGl0aW9uIHRvIHRoZSBwb2ludHMgYmVsb3csIGl0IGFsc28g Ikp1c3QgV29ya3MiIGZvciBhbGwNCj5leGlzdGluZyBhbmQgZnV0dXJlIG1vZGVscyBpbmNsdWRp bmcgb25lcyBkZXNpZ25lZCBvdXRzaWRlIG9mIHRoZQ0KPnB1cnZpZXcgb2YgdGhlIElFVEYuDQo+ DQo+VGhhbmtzLA0KPkNocmlzLg0KPg0KPj4NCj4+IEIgaXMgYSBtb3JlIHJvYnVzdCBzb2x1dGlv biwgc2luY2UgaXQgY2FuIGhhbmRsZSBub3Qgb25seSBpbnRlbmRlZCBhbmQNCj4+IGFwcGxpZWQs IGJ1dCBhbHNvIG90aGVyIGV4aXN0aW5nIChlLmcuIHN0YXJ0dXApIGFuZCBmdXR1cmUNCj4+IChl LmcuIGVwaGVtZXJhbCkgZGF0YXN0b3Jlcy4NCj4+DQo+Pg0KPj4gL21hcnRpbg0KPj4NCj4+DQo+ Pj4gSSBkbyBub3QgdGhpbmsgaXQgaXMgcmVhbGlzdGljIHRoYXQgdmVuZG9ycyB3aWxsIHJld3Jp dGUgdGhlaXIgSUVURg0KPj4+IG1vZHVsZXMgYW5kIHZlbmRvciBtb2R1bGVzIGFuZCBhbGwgdGhl IGFzc29jaWF0ZWQgY2xpZW50L3NlcnZlcg0KPj4+IGluc3RydW1lbnRhdGlvbi4NCj4+PiBUaGlz IGlzIGV4cGVuc2l2ZSBhdCBtYW55IGxldmVscy4gU3RhYmlsaXR5IGlzIGltcG9ydGFudCBmb3Ig YW4gQVBJLg0KPj4+DQo+Pj4gU28gaWYgd2UgZG8gKEEpLCB0aGVyZSB3aWxsIGJlIHNvbWUgbW9k dWxlcyBmb2xsb3dpbmcgdGhlIGNvbnZlbnRpb24NCj4+PiBhbmQgdGhlIHJlc3QgdXNpbmcgcHJv cHJpZXRhcnkgUlBDLWJhc2VkIHNvbHV0aW9ucy4NCj4+PiBCdXQgaWYgd2UgZG8gKEIpLCB2ZW5k b3JzIGNhbiBpbnRlZ3JhdGUgdGhlIHN0YW5kYXJkIFJQQy1iYXNlZCBzb2x1dGlvbg0KPj4+IGlu dG8gdGhlaXIgZXhpc3RpbmcgcnVubmluZyBjb2RlIHdpdGggemVybyBkaXN0dXJiYW5jZS4NCj4+ Pg0KPj4+DQo+Pj4gQW5keQ0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIFR1ZSwgSnVuIDcsIDIwMTYg YXQgNzoxOSBBTSwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+Pj4NCj4+ PiA+IEFsbCwNCj4+PiA+DQo+Pj4gPiBXZSB3YW50IHRvIHByb3ZpZGUgYW4gdXBkYXRlIGJhc2Vk IG9uIHRoZSBvZmYgbGluZSBkaXNjdXNzaW9ucw0KPj4+ID4gcmVsYXRlZCB0byBPcFN0YXRlIFNv bHV0aW9ucyB0aGF0IHdlIGhhdmUgYmVlbiBoYXZpbmcgYW5kIHNvbGljaXQNCj4+PiA+IGlucHV0 IGZyb20gdGhlIFdHLg0KPj4+ID4NCj4+PiA+IEFsbCBhdXRob3JzIG9mIGN1cnJlbnQgc29sdXRp b24gZHJhZnRzIFsxLDIsM10gdG9nZXRoZXIgd2l0aCB0aG9zZQ0KPj4+ID4gd2hvIGhlbHBlZCBj b25kdWN0IHRoZSBzb2x1dGlvbnMgYW5hbHlzaXMqIHdlcmUgaW52aXRlZCB0byB0aGUgdGhlc2UN Cj4+PiA+IGRpc2N1c3Npb25zIC0tIHdpdGggdGhlIG9iamVjdGl2ZSBvZiBjb21pbmcgdXAgd2l0 aCBhIHNpbmdsZQ0KPj4+ID4gY29uc29saWRhdGVkIHByb3Bvc2FsIHRvIGJyaW5nIHRvIHRoZSBX Ry4gKEkvTG91IGFjdGVkIGFzIGZhY2lsaXRhdG9yDQo+Pj4gPiBhcyBLZW50IGFuZCBKdWVyZ2Vu IHdlcmUgYW5kIGFyZSBpbnZvbHZlZCB3aXRoIHRoZSB0ZWNobmljYWwNCj4+PmRldGFpbHMuKQ0K Pj4+ID4NCj4+PiA+IFRoZSBkaXNjdXNzaW9ucyBoYXZlIHlpZWxkZWQgc29tZSByZXN1bHRzIGJ1 dCwgdW5mb3J0dW5hdGVseSwNCj4+PiA+IG5vdCBhIHNpbmdsZSBjb25zb2xpZGF0ZWQgcHJvcG9z YWwgYXMgaG9wZWQsIGJ1dCByYXRoZXIgdHdvDQo+Pj4gPiBhbHRlcm5hdGUgZGlyZWN0aW9ucyAt LSBhbmQgY2xlYXJseSB3ZSBuZWVkIHRvIGNob29zZSBvbmU6DQo+Pj4gPg0KPj4+ID4gICAgIDEp IEFkb3B0IHRoZSBjb252ZW50aW9ucyBmb3IgcmVwcmVzZW50aW5nIHN0YXRlL2NvbmZpZw0KPj4+ ID4gICAgICAgIGJhc2VkIG9uIFNlY3Rpb24gNiBvZiBbMV0uDQo+Pj4gPg0KPj4+ID4gICAgICAg IEZyb20gYSBtb2RlbCBkZWZpbml0aW9uIHBlcnNwZWN0aXZlLCB0aGVzZSBjb252ZW50aW9ucw0K Pj4+ID4gICAgICAgIGltcGFjdCBldmVyeSBtb2RlbCBhbmQgZXZlcnkgbW9kZWwgd3JpdGVyLg0K Pj4+ID4NCj4+PiA+ICAgICAyKSBNb2RlbCBPcFN0YXRlIHVzaW5nIGEgcmV2aXNlZCBsb2dpY2Fs IGRhdGFzdG9yZSBkZWZpbml0aW9uDQo+Pj4gPiAgICAgICAgYXMgaW50cm9kdWNlZCBpbiBbNF0g YW5kIGFsc28gY292ZXJlZCBpbiBbNV0uIFRoZXJlIGlzDQo+Pj4gPiAgICAgICAgYWxzbyBhIHZh cmlhbnQgb2YgdGhpcyB0aGF0IHdlIGJlbGlldmUgZG9lc24ndCBzaWduaWZpY2FudGx5DQo+Pj4g PiAgICAgICAgaW1wYWN0IHRoaXMgY2hvaWNlLg0KPj4+ID4NCj4+PiA+ICAgICAgICBXaXRoIHRo aXMgYXBwcm9hY2gsIG1vZGVsIGRlZmluaXRpb25zIG5lZWQgbm8gZXhwbGljaXQNCj4+PiA+ICAg ICAgICBjaGFuZ2VzIHRvIHN1cHBvcnQgYXBwbGllZCBjb25maWd1cmF0aW9uLg0KPj4+ID4NCj4+ PiA+ID5Gcm9tIGEgdGVjaG5vbG9neS9XRyBzdGFuZHBvaW50LCB3ZSBiZWxpZXZlIGFuIGFwcHJv YWNoDQo+Pj4gPiB0aGF0IGRvZXNuJ3QgaW1wYWN0IGV2ZXJ5IG1vZGVsIHdyaXR0ZW4gKGkuZS4s ICMyKSBpcyBzdXBlcmlvci4NCj4+PiA+IFRoZSBjb3VudGVycG9pbnQgdG8gdGhpcyBpcyB0aGF0 IHRoZSBjb252ZW50aW9ucyBiYXNlZA0KPj4+ID4gYXBwcm9hY2ggKGkuZS4sICMxKSBpcyBhdmFp bGFibGUgdG9kYXkgYW5kIGJlaW5nIGZvbGxvd2VkIGluDQo+Pj4gPiBPcGVuQ29uZmlnIGRlZmlu ZWQgbW9kZWxzLg0KPj4+ID4NCj4+PiA+IFdlIHdvdWxkIGxpa2UgdG8gaGVhciBvcGluaW9ucyBv biB0aGlzIGZyb20gdGhlIFdHIGJlZm9yZQ0KPj4+ID4gZGVjbGFyaW5nIG9uZSBvZiB0aGUgZm9s bG93aW5nIGFzIHRoZSBXRyBkaXJlY3Rpb246DQo+Pj4gPg0KPj4+ID4gICAgIEEpIG1vZGVscyB0 aGF0IHdpc2ggdG8gc3VwcG9ydCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gTVVTVA0KPj4+ID4gICAg ICAgIGZvbGxvdyBjb252ZW50aW9ucyBiYXNlZCBvbiBbMV0gLS0gYW5kIHRoZSBXRyBuZWVkcyB0 bw0KPj4+ID4gICAgICAgIGZvcm1hbGl6ZSB0aGVzZSBjb252ZW50aW9ucy4NCj4+PiA+IG9yDQo+ Pj4gPiAgICAgQikgbm8gZXhwbGljaXQgc3VwcG9ydCBpcyByZXF1aXJlZCBmb3IgbW9kZWxzIHRv IHN1cHBvcnQNCj4+PiA+ICAgICAgICBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gLS0gYW5kIHRoYXQg dGhlIFdHIG5lZWRzIHRvDQo+Pj4gPiAgICAgICAgZm9ybWFsaXplIGFuIG9wc3RhdGUgc29sdXRp b24gYmFzZWQgb24gdGhlIGFwcHJvYWNoDQo+Pj4gPiAgICAgICAgZGlzY3Vzc2VkIGluIFs0XSBh bmQgWzVdLg0KPj4+ID4NCj4+PiA+IFdlIGludGVuZCB0byBjbG9zZSBvbiB0aGlzIGNob2ljZSBi ZWZvcmUgQmVybGluLg0KPj4+ID4NCj4+PiA+IFRoYW5rIHlvdSwNCj4+PiA+IExvdSAoYW5kIGNv LWNoYWlycykNCj4+PiA+DQo+Pj4gPiBbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3RhdGUtMDENCj4+PiA+IFsyXSBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZS0wMg0KPj4+ID4gWzNd IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aWx0b24tbmV0bW9kLW9wc3RhdGUt eWFuZy0wMg0KPj4+ID4gWzRdIA0KPj4+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNjaG9lbnctbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wMA0KPj4+ID4gWzVdIA0KPj4+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbHRvbi1uZXRtb2QtcmVmaW5lZC1kYXRh c3RvcmVzLTAwDQo+Pj4gPiAqIC0gQ2hyaXMgSC4gYW5kIEFjZWUgTC4NCj4+PiA+DQo+Pj4gPg0K Pj4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiA+IG5ldG1vZEBpZXRmLm9yZw0KPj4+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+PiA+DQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1v ZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCg0K From nobody Wed Jun 8 11:08:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1E312D190 for ; Wed, 8 Jun 2016 11:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 wHng8Eifr0AB for ; Wed, 8 Jun 2016 11:08:27 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 59C9812D109 for ; Wed, 8 Jun 2016 11:08:27 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-08v.sys.comcast.net with SMTP id AhtcbLnT7lVqIAhtybDodK; Wed, 08 Jun 2016 18:08:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465409306; bh=5EVziNs6pJbfqhjtpBCdlqYwjvXprLK3m9Ev70MkyIY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=LIVSx/IACVq4DuN+zZdSgGbQHhMp0SLYpxpLNOjmzd3G4mJHtHgd5F2/aNZQUTZ/u jUQFEEYU1AKz5FE5ngPc5jwMv+q+GGxFWlEL4EX3MU+lw/VUSQ0yRd9wyV3ZSNYa48 uBXG05bN5ZhUaKn59RYe879F0JgXTsKUfpMBi+QHOg6C8+lcUqaXYSbJGRe6LbyeRg r2bj96awlKt4CedvkVSsWqT6JNMnaQbhVRjrzCg+lwmbeyAjuFdAjlqY36Zs5XDUd7 5CqkhRo3DYMiP4fHgJtPSoMJxE+rQLJEXACpOg9xtfP4brY977nEz8KHtU+cjNAdlj VflCqm2s74B7g== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-15v.sys.comcast.net with comcast id 4J8R1t00T1nMCLR01J8RDK; Wed, 08 Jun 2016 18:08:26 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u58I8PCY015914; Wed, 8 Jun 2016 14:08:25 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u58I8Or3015911; Wed, 8 Jun 2016 14:08:24 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund In-Reply-To: <20160608.101524.2250147567599766323.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 08 Jun 2016 14:08:24 -0400 Message-ID: <87vb1j5zaf.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 18:08:28 -0000 Martin Bjorklund writes: >> > > > > It is worth noting (either here or in 6.1.3) how line-breaks inside >> > > > > quoted strings are transcribed into the string's value. As now >> > > > > written, it seems that the line-break is transcribed identically to >> > > > > how it is represented in the source. That means (1) If the source is >> > > > > recoded with the other type of line break, the semantics of the Yang >> > > > > code change; and (2) if the source uses line-breaks of one type (CRLF >> > > > > or LF), only that type can be directly transcribed into string values. >> > > > > (But regardless of the source line-breaks, an LF can be transcribed >> > > > > into a double-quoted string with "\n". But a CRLF cannot be >> > > > > transcribed into a double-quoted string with escape sequences. Was >> > > > > that intended, or was "\r" intended to be legal?) >> > > >> > > Don't forget this. >> >> I was wondering that (as the text is written) the value of a quoted >> string that includes a line end will change if the line ends are >> changed (say, by moving the Yang file to a different host). Normally >> computer languages are defined so that changing how the program is >> "represented", e.g., by transforming it into a form with different >> line-ends, won't change the semantics of the program. >> >> But if it's true, I seems desirable to provide an explicit warning >> about it. It still seems to me to be valuable to warn about this. >> > You can always get the same effect by using single quoted strings. >> >> I don't see how you can get a single CR using single-quoted strings, >> because line ends are only allowed to be LF and CR-LF; writing a CR >> without an LF following it isn't allowed. Or is it that in practice, >> Yang 1 allows people to use CR alone, and it is not interpreted as a >> line-end? > > If the module has a string like this: > > 0x27 0x0d 0x27 > > it is a string with a single CR. I see in the grammar: line-break = CRLF / LF So you can't write an isolated CR in most of a Yang module. But am I correct in understanding that you *can* write an isolated CR inside a single-quoted string (and presumably, a double-quoted string)? Dale From nobody Wed Jun 8 11:34:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B4E12D0AB for ; Wed, 8 Jun 2016 11:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 9_v6s1aMiHQ1 for ; Wed, 8 Jun 2016 11:34:10 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 BB7DD12B00B for ; Wed, 8 Jun 2016 11:34:08 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-08v.sys.comcast.net with SMTP id AiEYbLpV1lVqIAiIqbDvaK; Wed, 08 Jun 2016 18:34:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465410848; bh=vVro23B7LXPuhAGT8OLmAHUSqHXpMX5C3+ZXyUVwxcA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=PPlcKRp/GW12brTzEGJtHL2v8vhWa3bGl1EoBHJQ5elnaLH13fbRYNNWCoU3yBMi0 +4aKeZnOqaSdnfsAXgftn8a1tFENQoVNOCiy/SE858aB+eIvF1C2rC1LZlMJupM/M6 XdGC4C4Uo6vike+iqpCuJW9beXENQ6TuxXISn9GFKmLNwxJhwBTvzvqj8TGvktjO14 mOCgxWX7rjXW9bMIDG8v0D9emtzyMZlixjKRpiC+pxJMuAxXwiTCMJZgxSC3CKXztr hWNNgopzDPuukHIZzfMPoiwInXnrTFrkVSZ6mkbgcRRHgw2uCV78AvSzhokq42/UP0 +MOpS/TGz5oNA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-10v.sys.comcast.net with comcast id 4Ja71t00G1nMCLR01Ja79M; Wed, 08 Jun 2016 18:34:08 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u58IY6qq018550; Wed, 8 Jun 2016 14:34:06 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u58IY6Vf018547; Wed, 8 Jun 2016 14:34:06 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund In-Reply-To: <20160608.122959.190928208866332031.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 08 Jun 2016 14:34:06 -0400 Message-ID: <87r3c75y3l.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 18:34:11 -0000 From: Juergen Schoenwaelder > An unquoted string is any sequence of characters and does not > contain any space, tab, or newline characters, a single or double > quote character, a semicolon (";"), braces ("{" or "}"), or > comment sequences ("//", "/*", or "*/"). > > Note that any keyword can legally appear as an unquoted string. That text seems to be quite clear to me. As Juergen notes, it directly points out to the implementor an important fact about lexing Yang. (Similarly, some programming languages allow keywords to be used as identifiers, they're not reserved.) Martin Bjorklund writes: >> If I understand correctly, the tokens of Yang (as the term is usually >> used in programming languages) are: >> >> whitespace (which is ignored) >> comments (which is ignored) >> single-quoted strings >> double-quoted strings >> unquoted strings (including keywords) >> ; >> { >> } >> >> >From the point of view of the tokenizer, these tokens fall into the >> obvious classes: >> >> type unquoted string >> "type" double-quoted string >> abc unquoted-string >> "abc" double-quoted string >> '---' single-quoted string >> >> I'm not quite sure how they are classified from the parser's point of >> view, though. >> >> type "type" abc "abc" '---' >> >> Is a string? ? Y ? Y Y >> (Can it appear as the >> argument of "description"?) >> >> Is a keyword? Y ? N N N >> (Can it appear as the first >> token of some statement?) >> >> Is an identifier? Y ? Y ? N >> (Can it appear as the second >> token of a type statement?) >> >> Usually programming languages use the particular syntax of different >> types of tokens to determine where they can be used in the >> context-free grammar. Yang seems to be more relaxed, but I'm not sure >> whether it is so relaxed thay any of the types of string tokens can be >> used anywhere. > > No; a keyword must be written w/o quotes, so it is special. OK, that answers one '?'. But there are effectively two that remain: Is abc valid as a string? Is "abc" valid as an identifier? I *think* the answer is No for both of those, but I can't put my finger on the rules that make that definite. >> There are two types that don't have a canonical form, identityref and >> instance-identifier. It seems that comparisons in XPath expressions >> are inexact if the type doesn't have a canonical form (section 6.4). >> But if I understand you correctly, the implicit comparisons in leafref >> are done based on the abstract values involved, not the lexical >> representation. > > Yes. I'm willing to take that as understood. >> > > The current ABNF doesn't allow for "+" for joining quoted strings. >> > > Also, it doesn't show that \" can be included in a double quoted string >> > > to include a literal ", and allows the string contents to continue -- >> > > the current ABNF "DQUOTE string DQUOTE" matches "abcd\", despite that >> > > the latter is not a proper double-quoted string. >> > >> > Note that the prose text (within <...>) says "a string that >> > matches...". That string can be any YANG token string, for example >> > one of: >> > >> > "hello" >> > "he" + "llo" >> >> If I haven't gotten confused, you're referring to >> >> string = < an unquoted string as returned by > >> < the scanner, that matches the rule > >> < yang-string > >> >> yang-string = *yang-char >> >> ;; any Unicode or ISO/IEC 10646 character including tab, carriage >> ;; return, and line feed, but excluding the other C0 control >> ;; characters, the surrogate blocks, and the noncharacters. >> yang-char = %x09 / %x0A / %x0D / %x20-D7FF / >> ; exclude surrogate blocks %xD800-DFFF >> %xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF >> %xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF >> %x10000-1FFFD / ; exclude noncharacters %x1FFFE-1FFFF >> %x20000-2FFFD / ; exclude noncharacters %x2FFFE-2FFFF >> %x30000-3FFFD / ; exclude noncharacters %x3FFFE-3FFFF >> %x40000-4FFFD / ; exclude noncharacters %x4FFFE-4FFFF >> %x50000-5FFFD / ; exclude noncharacters %x5FFFE-5FFFF >> %x60000-6FFFD / ; exclude noncharacters %x6FFFE-6FFFF >> %x70000-7FFFD / ; exclude noncharacters %x7FFFE-7FFFF >> %x80000-8FFFD / ; exclude noncharacters %x8FFFE-8FFFF >> %x90000-9FFFD / ; exclude noncharacters %x9FFFE-9FFFF >> %xA0000-AFFFD / ; exclude noncharacters %xAFFFE-AFFFF >> %xB0000-BFFFD / ; exclude noncharacters %xBFFFE-BFFFF >> %xC0000-CFFFD / ; exclude noncharacters %xCFFFE-CFFFF >> %xD0000-DFFFD / ; exclude noncharacters %xDFFFE-DFFFF >> %xE0000-EFFFD / ; exclude noncharacters %xEFFFE-EFFFF >> %xF0000-FFFFD / ; exclude noncharacters %xFFFFE-FFFFF >> %x100000-10FFFD ; exclude noncharacters %x10FFFE-10FFFF >> >> But if that's taken at face value, you can lex as single "string"s not only >> >> "hello" >> >> and >> >> "he" + "llo" >> >> but also >> >> "The MTU of the interface."; myext:c-define "MY_MTU" > > Why whould this be treated a single string? Note that line breaks are > not special in YANG, so by the same logic, this example: > > description > "The MTU of the interface."; > reference > "RFC XYZ"; > > would be scanned as the three tokens: > > description > > "The MTU of the interface."; > reference > "RFC XYZ" > > ; Actually, I've gotten completely lost in regard to how the grammar specifies how strings can be written. Let me take a single example. There are these productions: organization-stmt = organization-keyword sep string stmtend string = < an unquoted string as returned by > < the scanner, that matches the rule > < yang-string > yang-string = *yang-char (I won't quote the production for yang-char.) As written, this seems to say that in an organization statement, there is the organization keyword, a sep, a string, and then a stmtend. But the text above says that a string is "an unquoted string as returned by the scanner, that matches the rule yang-string". But looking at the example: organization "Example Inc."; I see that the string involved is quoted, which doesn't seem to be allowed by the production for "string", because the production says "an unquoted string". Now I suspect that what the production for "string" really wants to be is "a quoted or unquoted string whose *value* matches the rule yang-string". That is, what is *written* isn't allowed to be any *yang-char, but the denoted value must be *yang-char. (Some of the other productions seem to have the same issue.) Another point which is confusing me is how quoted strings are specified by the grammar. The only appearance of DQUOTE is in quoted-string = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) and the only appearance of quoted-string is in key-predicate-expr = node-identifier *WSP "=" *WSP quoted-string leaf-list-predicate-expr = "." *WSP "=" *WSP quoted-string which leaves me wondering how quoted strings are allowed elsewhere in the language. Dale From nobody Wed Jun 8 13:45:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD9512D5BD for ; Wed, 8 Jun 2016 13:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 NymNreiqY5qF for ; Wed, 8 Jun 2016 13:45:54 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A5A2512B02B for ; Wed, 8 Jun 2016 13:45:54 -0700 (PDT) Received: from localhost (h-46-190.a165.priv.bahnhof.se [46.59.46.190]) by mail.tail-f.com (Postfix) with ESMTPSA id 078E11AE0389; Wed, 8 Jun 2016 22:45:53 +0200 (CEST) Date: Wed, 08 Jun 2016 22:45:52 +0200 (CEST) Message-Id: <20160608.224552.2069028097678997544.mbj@tail-f.com> To: worley@ariadne.com From: Martin Bjorklund In-Reply-To: <87vb1j5zaf.fsf@hobgoblin.ariadne.com> References: <20160608.101524.2250147567599766323.mbj@tail-f.com> <87vb1j5zaf.fsf@hobgoblin.ariadne.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:45:56 -0000 worley@ariadne.com (Dale R. Worley) wrote: > Martin Bjorklund writes: > >> > > > > It is worth noting (either here or in 6.1.3) how line-breaks inside > >> > > > > quoted strings are transcribed into the string's value. As now > >> > > > > written, it seems that the line-break is transcribed identically to > >> > > > > how it is represented in the source. That means (1) If the source is > >> > > > > recoded with the other type of line break, the semantics of the Yang > >> > > > > code change; and (2) if the source uses line-breaks of one type (CRLF > >> > > > > or LF), only that type can be directly transcribed into string values. > >> > > > > (But regardless of the source line-breaks, an LF can be transcribed > >> > > > > into a double-quoted string with "\n". But a CRLF cannot be > >> > > > > transcribed into a double-quoted string with escape sequences. Was > >> > > > > that intended, or was "\r" intended to be legal?) > >> > > > >> > > Don't forget this. > >> > >> I was wondering that (as the text is written) the value of a quoted > >> string that includes a line end will change if the line ends are > >> changed (say, by moving the Yang file to a different host). Normally > >> computer languages are defined so that changing how the program is > >> "represented", e.g., by transforming it into a form with different > >> line-ends, won't change the semantics of the program. > >> > >> But if it's true, I seems desirable to provide an explicit warning > >> about it. > > It still seems to me to be valuable to warn about this. Do you have an suggestion for what to write? These kinds of multi-line strings are almost always 'description' statements, used for human consumption. It is not clear to me what the warning would be. > >> > You can always get the same effect by using single quoted strings. > >> > >> I don't see how you can get a single CR using single-quoted strings, > >> because line ends are only allowed to be LF and CR-LF; writing a CR > >> without an LF following it isn't allowed. Or is it that in practice, > >> Yang 1 allows people to use CR alone, and it is not interpreted as a > >> line-end? > > > > If the module has a string like this: > > > > 0x27 0x0d 0x27 > > > > it is a string with a single CR. > > I see in the grammar: > > line-break = CRLF / LF > > So you can't write an isolated CR in most of a Yang module. But am I > correct in understanding that you *can* write an isolated CR inside a > single-quoted string (and presumably, a double-quoted string)? Yes. /martin From nobody Wed Jun 8 14:00:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B38112B05B for ; Wed, 8 Jun 2016 14:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 bQrPIbA4ANtd for ; Wed, 8 Jun 2016 14:00:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id ED0CF12B02B for ; Wed, 8 Jun 2016 13:59:59 -0700 (PDT) Received: from localhost (h-46-190.a165.priv.bahnhof.se [46.59.46.190]) by mail.tail-f.com (Postfix) with ESMTPSA id 3EA3A1AE0389; Wed, 8 Jun 2016 22:59:59 +0200 (CEST) Date: Wed, 08 Jun 2016 22:59:59 +0200 (CEST) Message-Id: <20160608.225959.1712188122475580152.mbj@tail-f.com> To: worley@ariadne.com From: Martin Bjorklund In-Reply-To: <87r3c75y3l.fsf@hobgoblin.ariadne.com> References: <20160608.122959.190928208866332031.mbj@tail-f.com> <87r3c75y3l.fsf@hobgoblin.ariadne.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 21:00:01 -0000 worley@ariadne.com (Dale R. Worley) wrote: > From: Juergen Schoenwaelder > > An unquoted string is any sequence of characters and does not > > contain any space, tab, or newline characters, a single or double > > quote character, a semicolon (";"), braces ("{" or "}"), or > > comment sequences ("//", "/*", or "*/"). > > > > Note that any keyword can legally appear as an unquoted string. > > That text seems to be quite clear to me. As Juergen notes, it directly > points out to the implementor an important fact about lexing Yang. > (Similarly, some programming languages allow keywords to be used as > identifiers, they're not reserved.) Ok, let's use Juergen's proposed text. > Martin Bjorklund writes: > >> If I understand correctly, the tokens of Yang (as the term is usually > >> used in programming languages) are: > >> > >> whitespace (which is ignored) > >> comments (which is ignored) > >> single-quoted strings > >> double-quoted strings > >> unquoted strings (including keywords) > >> ; > >> { > >> } > >> > >> >From the point of view of the tokenizer, these tokens fall into the > >> obvious classes: > >> > >> type unquoted string > >> "type" double-quoted string > >> abc unquoted-string > >> "abc" double-quoted string > >> '---' single-quoted string > >> > >> I'm not quite sure how they are classified from the parser's point of > >> view, though. > >> > >> type "type" abc "abc" '---' > >> > >> Is a string? ? Y ? Y Y > >> (Can it appear as the > >> argument of "description"?) > >> > >> Is a keyword? Y ? N N N > >> (Can it appear as the first > >> token of some statement?) > >> > >> Is an identifier? Y ? Y ? N > >> (Can it appear as the second > >> token of a type statement?) > >> > >> Usually programming languages use the particular syntax of different > >> types of tokens to determine where they can be used in the > >> context-free grammar. Yang seems to be more relaxed, but I'm not sure > >> whether it is so relaxed thay any of the types of string tokens can be > >> used anywhere. > > > > No; a keyword must be written w/o quotes, so it is special. > > OK, that answers one '?'. But there are effectively two that remain: > > Is abc valid as a string? Yes. > Is "abc" valid as an identifier? Yes. All YANG statements have the same structure: statement = keyword [argument] (";" / "{" *statement "}") All arguments are strings. Strings can be unquoted or quoted (and possibly concatenated). > I *think* the answer is No for both of those, but I can't put my finger > on the rules that make that definite. > > >> There are two types that don't have a canonical form, identityref and > >> instance-identifier. It seems that comparisons in XPath expressions > >> are inexact if the type doesn't have a canonical form (section 6.4). > >> But if I understand you correctly, the implicit comparisons in leafref > >> are done based on the abstract values involved, not the lexical > >> representation. > > > > Yes. > > I'm willing to take that as understood. > > >> > > The current ABNF doesn't allow for "+" for joining quoted strings. > >> > > Also, it doesn't show that \" can be included in a double quoted string > >> > > to include a literal ", and allows the string contents to continue -- > >> > > the current ABNF "DQUOTE string DQUOTE" matches "abcd\", despite that > >> > > the latter is not a proper double-quoted string. > >> > > >> > Note that the prose text (within <...>) says "a string that > >> > matches...". That string can be any YANG token string, for example > >> > one of: > >> > > >> > "hello" > >> > "he" + "llo" > >> > >> If I haven't gotten confused, you're referring to > >> > >> string = < an unquoted string as returned by > > >> < the scanner, that matches the rule > > >> < yang-string > > >> > >> yang-string = *yang-char > >> > >> ;; any Unicode or ISO/IEC 10646 character including tab, carriage > >> ;; return, and line feed, but excluding the other C0 control > >> ;; characters, the surrogate blocks, and the noncharacters. > >> yang-char = %x09 / %x0A / %x0D / %x20-D7FF / > >> ; exclude surrogate blocks %xD800-DFFF > >> %xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF > >> %xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF > >> %x10000-1FFFD / ; exclude noncharacters %x1FFFE-1FFFF > >> %x20000-2FFFD / ; exclude noncharacters %x2FFFE-2FFFF > >> %x30000-3FFFD / ; exclude noncharacters %x3FFFE-3FFFF > >> %x40000-4FFFD / ; exclude noncharacters %x4FFFE-4FFFF > >> %x50000-5FFFD / ; exclude noncharacters %x5FFFE-5FFFF > >> %x60000-6FFFD / ; exclude noncharacters %x6FFFE-6FFFF > >> %x70000-7FFFD / ; exclude noncharacters %x7FFFE-7FFFF > >> %x80000-8FFFD / ; exclude noncharacters %x8FFFE-8FFFF > >> %x90000-9FFFD / ; exclude noncharacters %x9FFFE-9FFFF > >> %xA0000-AFFFD / ; exclude noncharacters %xAFFFE-AFFFF > >> %xB0000-BFFFD / ; exclude noncharacters %xBFFFE-BFFFF > >> %xC0000-CFFFD / ; exclude noncharacters %xCFFFE-CFFFF > >> %xD0000-DFFFD / ; exclude noncharacters %xDFFFE-DFFFF > >> %xE0000-EFFFD / ; exclude noncharacters %xEFFFE-EFFFF > >> %xF0000-FFFFD / ; exclude noncharacters %xFFFFE-FFFFF > >> %x100000-10FFFD ; exclude noncharacters %x10FFFE-10FFFF > >> > >> But if that's taken at face value, you can lex as single "string"s not only > >> > >> "hello" > >> > >> and > >> > >> "he" + "llo" > >> > >> but also > >> > >> "The MTU of the interface."; myext:c-define "MY_MTU" > > > > Why whould this be treated a single string? Note that line breaks are > > not special in YANG, so by the same logic, this example: > > > > description > > "The MTU of the interface."; > > reference > > "RFC XYZ"; > > > > would be scanned as the three tokens: > > > > description > > > > "The MTU of the interface."; > > reference > > "RFC XYZ" > > > > ; > > Actually, I've gotten completely lost in regard to how the grammar > specifies how strings can be written. The grammar doesn't specify how strings can be written. This is defined in the section "Lexical Tokenization": unquoted quoted quoted and concatenated > Let me take a single example. > There are these productions: > > organization-stmt = organization-keyword sep string stmtend > > string = < an unquoted string as returned by > > < the scanner, that matches the rule > > < yang-string > > > yang-string = *yang-char > > (I won't quote the production for yang-char.) As written, this seems to > say that in an organization statement, there is the organization > keyword, a sep, a string, and then a stmtend. But the text above says > that a string is "an unquoted string as returned by the scanner This means that in all these examples, the resulting string is the same: hello "hello" 'hello' 'he' + "llo" and the resulting string is a string with 5 characters. >, that > matches the rule yang-string". But looking at the example: > > organization "Example Inc."; > > I see that the string involved is quoted, which doesn't seem to be > allowed by the production for "string", because the production says "an > unquoted string". > > Now I suspect that what the production for "string" really wants to be > is "a quoted or unquoted string whose *value* matches the rule > yang-string". That is, what is *written* isn't allowed to be any > *yang-char, but the denoted value must be *yang-char. Yes, but it is more than quoted or unquoted; it is also concatenation, escape char substition and whitespace trimming. > (Some of the > other productions seem to have the same issue.) > > Another point which is confusing me is how quoted strings are specified > by the grammar. The only appearance of DQUOTE is in > > quoted-string = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE) > > and the only appearance of quoted-string is in > > key-predicate-expr = node-identifier *WSP "=" *WSP quoted-string > > leaf-list-predicate-expr = "." *WSP "=" *WSP quoted-string Note that these are quoted strings *after* the scanner's processing of the input, so e.g., you might have: path '/foo[bar="hi"]'; /martin > > which leaves me wondering how quoted strings are allowed elsewhere in > the language. > > Dale > From nobody Wed Jun 8 17:25:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6E12D866 for ; Wed, 8 Jun 2016 17:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg9VovemOspd for ; Wed, 8 Jun 2016 17:25:53 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 96BDC12D845 for ; Wed, 8 Jun 2016 17:25:53 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id c72so23481467ywb.1 for ; Wed, 08 Jun 2016 17:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=BetPZUb5gLHZJ+Wh4sJKywwsDrRpmyEiiQF0uODcs2g=; b=wQWf6pgESNh8nTbUVsYkgYfFxozycl16K0l0eC8dKGw4WoSvJWBxPtWeIYwv0BVjMo 9fEWT5W74kYTH8EKtJj82v9iipDzGOUR999pJsQ0emc8sdIFGb1XS8Wrzo/EeYMxl58s GyTEu+qc+FjMuLtnfX+m2vc+KwsfGyceRN7I5ddhTfANDjeyKiyzL+ZflCYo5Ci+9490 1ky1+wd9TgVx4NPQ3KDJ/suPZC2dfpl9IlZ3/Aa+2OkiyqxO8GnGzGK5HJSs2OdZJHyK YAillwzYIuEKWxo7OLpyJHpN2Euoz9rGqvwpLV6K6zg/bxaB1bzCOw6X/du0jZo1CEep h4xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=BetPZUb5gLHZJ+Wh4sJKywwsDrRpmyEiiQF0uODcs2g=; b=jmh1pcU+Y+JwYeUMD35HKfayPLUuecMpPBgD1RrlG0ig571Iy/roeeXH8NBJXO5Dr2 KKL18q67F+eOdpoOA8+uvlOfcN6HwZlrCu9++EsTvdX4S9+nFbOwHvndLoEWX/tBz4hK MnrqQ8YZywy4A/A56y7iu9ZxbnDsSjjFRHeP29GtnQRluCNUZk31bzUcYDQuaj+toreF vgNqMRKn0nb9s4ROouSyDceWjz1/RVEkHysIjKAwu7lDYTYxgraWeXTwoWDx/I3wp3hl ISH5wkXJorYoxo798P6hGMhoaGfnDYIjSQdtQP8n/MxQJ5/4KmAeoLzkR6UGmaNUtPGO U9MA== X-Gm-Message-State: ALyK8tLIOX7r+K/1xBbGY3pqgBcfUg58LLYsz37ThVN/TNB0LHbtczwlASmVvwKlnfTQtkBPJIZli2Xm60Lqbw== MIME-Version: 1.0 X-Received: by 10.129.101.137 with SMTP id z131mr4727341ywb.88.1465431952883; Wed, 08 Jun 2016 17:25:52 -0700 (PDT) Received: by 10.37.42.77 with HTTP; Wed, 8 Jun 2016 17:25:52 -0700 (PDT) Date: Wed, 8 Jun 2016 17:25:52 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114c6d8cfeaf360534cd76fa Archived-At: Subject: [netmod] YANG library update and new YANG guideline issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 00:25:55 -0000 --001a114c6d8cfeaf360534cd76fa Content-Type: text/plain; charset=UTF-8 Hi, We have been asked to make the YANG library module consistent wrt/ use of a container parent for a list. We decided to remove the submodules container parent from the child submodule. The submodule list and deviation list will now be consistent. Benoit has asked for a YANG guideline in rfc6087bis on this issue. I added the issue with an example to github https://github.com/netmod-wg/rfc6087bis/issues/35 Please comment if you prefer (A) guideline is be consistent throughout module (whichever choice) (B) guideline is for use of a container parent (C) guideline is to not use a container parent (D) something else thanks, Andy, Martin, and Kent --001a114c6d8cfeaf360534cd76fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


We have been asked t= o make the YANG library module consistent
wrt/ use of a container= parent for a list.=C2=A0 We decided to remove the
submodules con= tainer parent from the child submodule.
The submodule list and de= viation list will now be consistent.

Benoit has as= ked for a YANG guideline in rfc6087bis on this issue.
I added the= issue with an example to github

Please comment if you prefer
=C2=A0 (A) guideline is be consistent throughout module (whichever choice= )
=C2=A0 (B) guideline is for use of a container parent
=C2=A0 (C) guideline is to not use a container parent
=C2=A0 (D)= something else



than= ks,
Andy, Martin, and Kent





--001a114c6d8cfeaf360534cd76fa-- From nobody Thu Jun 9 00:42:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D9C12D197 for ; Thu, 9 Jun 2016 00:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 jGdKczPty4vC for ; Thu, 9 Jun 2016 00:42:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6408B12B043 for ; Thu, 9 Jun 2016 00:42:38 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 29F9F1AE018B; Thu, 9 Jun 2016 09:42:37 +0200 (CEST) Date: Thu, 09 Jun 2016 09:42:59 +0200 (CEST) Message-Id: <20160609.094259.2082528782584874294.mbj@tail-f.com> To: worley@ariadne.com From: Martin Bjorklund In-Reply-To: <87mvmv7n4z.fsf@hobgoblin.ariadne.com> References: <04421D3F-E2FC-45BC-89AA-82C550706AC4@broadband-forum.org> <87mvmv7n4z.fsf@hobgoblin.ariadne.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Replacing a YANG submodule with a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 07:42:40 -0000 worley@ariadne.com (Dale R. Worley) wrote: > William Lupton writes: > > Consider the YANG module, submodule and tree files shown > > below. Suppose that I regret the decision to make "submod" be a > > submodule and want to replace it with a module (see listings further > > down). This works, the tree file is identical, and pyang > > --check-update-from is happy, but strictly the interface has changed > > (the util grouping has moved from the urn:bbf:yang:test namespace to > > the urn:bbf:yang:mod namespace). Is this intended to be valid (I don't > > see it mentioned in RFC 6020bis Section 11)? > > I'm not sure what a "tree file" is. Most IETF documents that define YANG modules contain a simplified "tree" view of the data models they define, in order for the reader to quickly get an overview of the model. See e.g., https://tools.ietf.org/html/rfc7223#page-5. Such tree diagrams can be produced with tools like "pyang" (pyang -f tree ...). (The tree diagrams are also very useful when reviewing modules). > But it turns out that the XML for > data trees doesn't change. The reason for that is that in the second > example, the util *grouping* is in the module mod, but the schema node > (which is the prototype of an XML element in a data tree) is in the > module test, where the uses statement is, and so the "util" XML element > will be in the XML namespace of module test. See section 7.13: > > The identifiers defined in the grouping are not bound to a namespace > until the contents of the grouping are added to the schema tree via a > "uses" statement that does not appear inside a "grouping" statement, > at which point they are bound to the namespace of the current module. > > In regard to assigning schema nodes to an XML namespace, the uses acts > like a macro expansion, while in regard to resolving references to Yang > identifiers, uses/grouping is lexically scoped. > > Martin Bjorklund writes: > > You have removed the "util" grouping from the module "test". This is > > not allowed according to the upgrade rules. > > ["upgrade" means "updating" and refers to section 11.] > > If I understand Yang correctly, that error can't be fixed by revising > the new module test to clone mod:util as test:util, because though the > new grouping is semantically identical to the old grouping, it's still a > change in its definition: Hmm, why do you think that this isn't allowed? If the syntax and semantics are the same it should be allowed. Section 11 has: - Any set of data definition nodes may be replaced with another set of syntactically and semantically equivalent nodes. For example, a set of leafs may be replaced by a uses of a grouping with the same leafs. /martin > > module test { > namespace "urn:bbf:yang:test"; > prefix test; > > import mod { > prefix mod; > revision-date 2016-06-08; > } > > revision 2016-06-08 { > } > > uses mod:util; > > + grouping util { > + uses mod:util; > + } > } > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Jun 9 02:18:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CC112D10B for ; Thu, 9 Jun 2016 02:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 jtQ5exyj7mAr for ; Thu, 9 Jun 2016 02:18:41 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE65012D18D for ; Thu, 9 Jun 2016 02:18:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E79B11E5D81; Thu, 9 Jun 2016 02:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id f-VbsRGeMrWx; Thu, 9 Jun 2016 02:18:27 -0700 (PDT) Received: from [192.168.1.100] (host86-133-84-177.range86-133.btcentralplus.com [86.133.84.177]) by c8a.amsl.com (Postfix) with ESMTPSA id D74F41E5D7D; Thu, 9 Jun 2016 02:18:26 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_56987D2A-179C-4D21-95E5-C80871FC63AA" From: William Lupton In-Reply-To: Date: Thu, 9 Jun 2016 10:18:38 +0100 Message-Id: <864F4298-7933-416A-AD5B-42D0C522B4AA@broadband-forum.org> References: <04421D3F-E2FC-45BC-89AA-82C550706AC4@broadband-forum.org> <20160608.133711.2260680881610374799.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.2104) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Replacing a YANG submodule with a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 09:18:43 -0000 --Apple-Mail=_56987D2A-179C-4D21-95E5-C80871FC63AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Martin, I think that the answer is =E2=80=9Cyes=E2=80=9D but please could you = just confirm that the alternatives presented here are valid? In the real = world I think I would usually follow the second approach of retaining = the submodule (including its groupings) but simply breaking out the = definitions of the bodies of its groupings into groupings defined in new = module(s). Thanks, William > On 8 Jun 2016, at 13:38, William Lupton = wrote: >=20 > Thanks. So the following would be valid I assume? Or (better because = it doesn=E2=80=99t change the module/submodule interface?) the second = option shown below (which simply defines a new module in order to make = the grouping externally accessible). Cheers, W. >=20 > % cat test@2016-06-08.yang =20 > module test { > namespace "urn:bbf:yang:test"; > prefix test; >=20 > import mod { > prefix mod; > revision-date 2016-06-08; > } >=20 > revision 2016-06-08 { > } >=20 > grouping util { > uses mod:util; > } >=20 > uses util; > } >=20 > Second option: >=20 > % cat test@2016-06-09.yang = submod@2016-06-09.yang = mod@2016-06-09.yang test@2016-06-09.tree = =20 > module test { > namespace "urn:bbf:yang:test"; > prefix test; >=20 > include submod { > revision-date 2016-06-09; > } >=20 > revision 2016-06-09 { > } >=20 > uses util; > } > submodule submod { > belongs-to test { > prefix test; > } >=20 > import mod { > prefix mod; > revision-date 2016-06-09; > } >=20 > revision 2016-06-09 { > } >=20 > grouping util { > uses mod:util; > } > } > module mod { > namespace "urn:bbf:yang:mod"; > prefix mod; >=20 > revision 2016-06-09 { > } >=20 > grouping util { > container util { > } > } > } > module: test > +--rw util >=20 >> On 8 Jun 2016, at 12:37, Martin Bjorklund > wrote: >>=20 >> William Lupton > wrote: >>> Hi, >>>=20 >>> Consider the YANG module, submodule and tree files shown >>> below. Suppose that I regret the decision to make =E2=80=9Csubmod=E2=80= =9D be a >>> submodule and want to replace it with a module (see listings further >>> down). This works, the tree file is identical, and pyang >>> --check-update-from is happy, but strictly the interface has changed >>> (the util grouping has moved from the urn:bbf:yang:test namespace to >>> the urn:bbf:yang:mod namespace). >>=20 >> You have removed the "util" grouping from the module "test". This is >> not allowed according to the upgrade rules. >>=20 >> (So yes, this is a bug in pyang --check-update-from; it doesn't work >> well with this kind of structural change) >>=20 >>=20 >> /martin >>=20 >>=20 >>=20 >>> Is this intended to be valid (I don=E2=80=99t >>> see it mentioned in RFC 6020bis Section 11)? >>>=20 >>> Thanks, >>> William >>>=20 >>> % cat test@2016-01-01.yang = submod@2016-01-01.yang = test@2016-01-01.tree =20 >>> module test { >>> namespace "urn:bbf:yang:test"; >>> prefix test; >>>=20 >>> include submod { >>> revision-date 2016-01-01; >>> } >>>=20 >>> revision 2016-01-01 { >>> } >>>=20 >>> uses util; >>> } >>> submodule submod { >>> belongs-to test { >>> prefix test; >>> } >>>=20 >>> revision 2016-01-01 { >>> } >>>=20 >>> grouping util { >>> container util { >>> } >>> } >>> } >>> module: test >>> +--rw util >>>=20 >>> Replacements with submod -> mod: >>>=20 >>> % cat test@2016-06-08.yang = mod@2016-06-08.yang test@2016-06-08.tree = =20 >>> module test { >>> namespace "urn:bbf:yang:test"; >>> prefix test; >>>=20 >>> import mod { >>> prefix mod; >>> revision-date 2016-06-08; >>> } >>>=20 >>> revision 2016-06-08 { >>> } >>>=20 >>> uses mod:util; >>> } >>> module mod { >>> namespace "urn:bbf:yang:mod"; >>> prefix mod; >>>=20 >>> revision 2016-06-08 { >>> } >>>=20 >>> grouping util { >>> container util { >>> } >>> } >>> } >>> module: test >>> +--rw util >>>=20 >>> pyang is happy: >>>=20 >>> % pyang --check-update-from=3Dtest@2016-01-01.yang = test@2016-06-08.yang = >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_56987D2A-179C-4D21-95E5-C80871FC63AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Martin,

I = think that the answer is =E2=80=9Cyes=E2=80=9D but please could you just = confirm that the alternatives presented here are valid? In the real = world I think I would usually follow the second approach of retaining = the submodule (including its groupings) but simply breaking out the = definitions of the bodies of its groupings into groupings defined in new = module(s).

Thanks,
William

On = 8 Jun 2016, at 13:38, William Lupton <wlupton@broadband-forum.org> wrote:

Thanks. So the = following would be valid I assume? Or (better because it doesn=E2=80=99t = change the module/submodule interface?) the second option shown below = (which simply defines a new module in order to make the grouping = externally accessible). Cheers, W.

module test {
  namespace = "urn:bbf:yang:test";
  prefix test;

  import mod = {
    = prefix mod;
  =   revision-date 2016-06-08;
  }

  revision = 2016-06-08 {
  }

  grouping util {
    uses = mod:util;
  = }

  uses util;
}

Second option:

module test {
  namespace = "urn:bbf:yang:test";
  prefix test;

  include submod = {
    = revision-date 2016-06-09;
  }

  revision 2016-06-09 {
  }

  = uses util;
}
submodule submod {
  belongs-to test {
    prefix test;
  }

  = import mod {
    prefix mod;
    revision-date 2016-06-09;
  }

  = revision 2016-06-09 {
  }

  grouping util {
    uses = mod:util;
  = }
}
module mod {
  namespace = "urn:bbf:yang:mod";
  prefix mod;

  revision = 2016-06-09 {
  }

  grouping util {
    = container util {
    }
  }
}
module: test
   +--rw util

On = 8 Jun 2016, at 12:37, Martin Bjorklund <mbj@tail-f.com> = wrote:

William Lupton <wlupton@broadband-forum.org> wrote:
Hi,

Consider the YANG module, submodule and tree files shown
below. Suppose that I regret the decision to make = =E2=80=9Csubmod=E2=80=9D be a
submodule and want to = replace it with a module (see listings further
down). This = works, the tree file is identical, and pyang
--check-update-from is happy, but strictly the interface has = changed
(the util grouping has moved from the = urn:bbf:yang:test namespace to
the urn:bbf:yang:mod = namespace).

You have removed = the "util" grouping from the module "test".  This is
not allowed according to the upgrade rules.

(So yes, this is a bug in pyang --check-update-from; it = doesn't work
well with this kind of structural change)


/martin



Is this intended to be valid (I don=E2=80=99t
see= it mentioned in RFC 6020bis Section 11)?

Thanks,
William

% = cat test@2016-01-01.yang submod@2016-01-01.yang test@2016-01-01.tree 
module test {
 namespace "urn:bbf:yang:test";
 prefix= test;

 include submod {
   revision-date 2016-01-01;
 }
 revision 2016-01-01 {
 }

 uses util;
}
submodule submod {
 belongs-to test {
   prefix = test;
 }

 revision = 2016-01-01 {
 }

 grouping util {
   container = util {
   }
 }
}
module: test
  +--rw = util

Replacements with submod -> mod:

% cat test@2016-06-08.yang mod@2016-06-08.yang test@2016-06-08.tree 
module test {
 namespace "urn:bbf:yang:test";
 prefix= test;

 import mod {
   prefix mod;
  =  revision-date 2016-06-08;
 }

 revision 2016-06-08 {
 }

 uses mod:util;
}
module mod {
 namespace = "urn:bbf:yang:mod";
 prefix mod;

 revision 2016-06-08 {
 }

 grouping util {
  =  container util {
   }
 }
}
module: test
  +--rw util

pyang is = happy:

% pyang --check-update-from=3Dtest@2016-01-01.yang test@2016-06-08.yang

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

= --Apple-Mail=_56987D2A-179C-4D21-95E5-C80871FC63AA-- From nobody Thu Jun 9 02:23:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5421F12D1E0; Thu, 9 Jun 2016 02:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 KJRX7uyO_92V; Thu, 9 Jun 2016 02:23:29 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A80112D18D; Thu, 9 Jun 2016 02:23:29 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 23554180262; Thu, 9 Jun 2016 11:23:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id E95901A005B; Thu, 9 Jun 2016 11:23:27 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0294.000; Thu, 9 Jun 2016 11:23:28 +0200 From: To: Lou Berger , netmod WG Thread-Topic: [netmod] Opstate solutions discussions: update and request for WG input Thread-Index: AQHRwMeryY8MgJBTQEykBoRF6CHPKJ/g3qSA Date: Thu, 9 Jun 2016 09:23:27 +0000 Message-ID: <18419_1465464208_5759358F_18419_2226_1_9E32478DFA9976438E7A22F69B08FF921BC48871@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> In-Reply-To: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod-chairs@ietf.org" Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 09:23:31 -0000 I'm also in favor of B. I personally do not like the way state/config are expressed in [1] as it co= mplexifies the way yang modules are written while a solution like [4] allow= s to have a more cleaner yang module while achieving the same goal. As expressed by others, B will also be faster with existing modules. Best Regards, Stephane -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger Sent: Tuesday, June 07, 2016 16:20 To: netmod WG Cc: netmod-chairs@ietf.org Subject: [netmod] Opstate solutions discussions: update and request for WG = input All, We want to provide an update based on the off line discussions related to O= pState Solutions that we have been having and solicit input from the WG. All authors of current solution drafts [1,2,3] together with those who help= ed conduct the solutions analysis* were invited to the these discussions --= with the objective of coming up with a single consolidated proposal to bri= ng to the WG. (I/Lou acted as facilitator as Kent and Juergen were and are = involved with the technical details.) The discussions have yielded some results but, unfortunately, not a single = consolidated proposal as hoped, but rather two alternate directions -- and = clearly we need to choose one: 1) Adopt the conventions for representing state/config based on Section 6 of [1]. From a model definition perspective, these conventions impact every model and every model writer. 2) Model OpState using a revised logical datastore definition as introduced in [4] and also covered in [5]. There is also a variant of this that we believe doesn't significantly impact this choice. With this approach, model definitions need no explicit changes to support applied configuration. >From a technology/WG standpoint, we believe an approach that doesn't impact every model written (i.e., #2) is superior. The counterpoint to this is that the conventions based approach (i.e., #1) = is available today and being followed in OpenConfig defined models. We would like to hear opinions on this from the WG before declaring one of = the following as the WG direction: A) models that wish to support applied configuration MUST follow conventions based on [1] -- and the WG needs to formalize these conventions. or B) no explicit support is required for models to support applied configuration -- and that the WG needs to formalize an opstate solution based on the approach discussed in [4] and [5]. We intend to close on this choice before Berlin. Thank you, Lou (and co-chairs) [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 * - Chris H. and Acee L. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jun 9 02:57:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8AB12D0F0 for ; Thu, 9 Jun 2016 02:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 dvipaUSNSm5Z for ; Thu, 9 Jun 2016 02:57:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 D9D4B12D0A0 for ; Thu, 9 Jun 2016 02:57:10 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 298D256BB0E2C; Thu, 9 Jun 2016 09:57:07 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u599v8q7010999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jun 2016 09:57:08 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u599v0c7015531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jun 2016 11:57:08 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.34]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 9 Jun 2016 11:56:59 +0200 From: "Scharf, Michael (Nokia - DE)" To: "netmod@ietf.org" Thread-Topic: Template mechanism? Thread-Index: AdHCNUKRewvL7/AlQB6Xs58iULTIxg== Date: Thu, 9 Jun 2016 09:56:58 +0000 Message-ID: <655C07320163294895BBADA28372AF5D488C9F36@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: EXT David Ball , "adrian@olddog.co.uk" Subject: [netmod] Template mechanism? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 09:57:12 -0000 The current L3SM YANG data model uses templates in the YANG model. Specific= ally, draft-ietf-l3sm-l3vpn-service-model currently models "site-templates"= . Recently, on the L3SM list the question has been raised whether such templa= tes could be a concept with broader applicability (see https://www.ietf.org= /mail-archive/web/l3sm/current/msg00475.html, https://www.ietf.org/mail-arc= hive/web/l3sm/current/msg00482.html). Is there a more generic solution that could be used in L3SM? Any thoughts o= r references?=20 Thanks! Michael From nobody Thu Jun 9 04:02:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFA012D10E for ; Thu, 9 Jun 2016 04:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 l_eRwJdYf5ha for ; Thu, 9 Jun 2016 04:02:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0139712D0FD for ; Thu, 9 Jun 2016 04:02:14 -0700 (PDT) Received: from [172.16.1.164] (176.100.broadband6.iol.cz [88.101.100.176]) by mail.nic.cz (Postfix) with ESMTPSA id B673861809; Thu, 9 Jun 2016 13:02:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465470132; bh=GSNCfJc/abHt2T60VGq6XYzqSYhIbJwretaK+HyZYE0=; h=From:Date:To; b=FcxFijm9s+vahm9G+xYKb6K2kPerzgoLlxRjVWvPHYpT6cANzQPQl8a+g8M3KJ5C3 JON28aM9nYf39cIB2WHmoFv9Yz1O/RG/8c01HeB9L7KJpdRrRwPuf8yFla0eLLbPTj ywew9HMH9W/R6EUC2g4ScTidRGfDluz34WQy3OnY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <87fusn7lj6.fsf@hobgoblin.ariadne.com> Date: Thu, 9 Jun 2016 13:02:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <87fusn7lj6.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] leafref value space and constraint X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 11:02:17 -0000 > On 08 Jun 2016, at 17:22, Dale R. Worley wrote: > > Martin Bjorklund writes: >> The text for "path" already says: >> >> It takes as an argument a >> string that MUST refer to a leaf or leaf-list node. > > Given what the text must mean, that's sufficient for me. Then it's fine with me, too. Lada > > Ladislav Lhotka writes: >> Which of the two "foo" leaf nodes does the path argument point at? If >> the path is interpreted in the schema tree, it may appear it is the >> one inside the choice. Yes, we all know it points at the other one, >> but will all readers of the spec come to the same conclusion? > > Well, in 9.9.2 it says: > > The "path" XPath expression is conceptually evaluated in the > following context, in addition to the definition in Section 6.4.1: > > o If the "path" statement is defined within a typedef, the context > node is the leaf or leaf-list node in the data tree that > references the typedef. > > o Otherwise, the context node is the node in the data tree for which > the "path" statement is defined. > > What's really going on is that the XPath expression will always be > evaluated in the context of a particular element of a particular data > tree, but that it can be shown to be always valid by doing a "generic > evaluation" of the expression looking at the schema tree -- the schema > tree is a generic description of all possible data trees. Of course > there are various complications because not all nodes in the schema tree > are represented in the XML tree. > > In mathematics, abstracting an operation in a particular structure to a > similar operation in a "generic" structure is called "lifting", and > using that term, it's easy to notify the reader what you're doing > without spelling out the details. What's difficult here is that it's > "obvious" what the text has to mean, but we have no simple vocabulary > for pointing that out, and the reader who is not careful might not > realize everything that is going on. > > At this point, I'm willing to ignore the issue. There doesn't seem to > be a simple way to explain the critical issue. And if the reader > attempts to work out the details of Yang processing, he eventually has > to come to the correct conclusion; there is only one self-consistent > interpretation. > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 9 04:08:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F336212D124 for ; Thu, 9 Jun 2016 04:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 uckVgethSNpM for ; Thu, 9 Jun 2016 04:08:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9921112B076 for ; Thu, 9 Jun 2016 04:08:32 -0700 (PDT) Received: from [172.16.1.164] (176.100.broadband6.iol.cz [88.101.100.176]) by mail.nic.cz (Postfix) with ESMTPSA id 265D8617DD; Thu, 9 Jun 2016 13:08:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465470511; bh=F57Jb/ctDE2HEjXcJhlYqi9CBqTjkIukmgfgx2e/JHU=; h=From:Date:To; b=Q75Fc1Rh5EGbshUx8hy1bUaS9uI9pSQj3m/QQCC/1k9df9/CDr1EZTljj/uxOo/qX rv4hZPYqVdixpFG/1U9xxSQaoiabSEbfYL/cCtjhRKY0BhrwpxXISVXf78I8luJ6zL JKhA9q25s5hU7/sw7XKbDiXtM5irosTszA9kL16o= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 9 Jun 2016 13:08:36 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG library update and new YANG guideline issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 11:08:34 -0000 > On 09 Jun 2016, at 02:25, Andy Bierman wrote: > > Hi, > > > We have been asked to make the YANG library module consistent > wrt/ use of a container parent for a list. We decided to remove the > submodules container parent from the child submodule. > The submodule list and deviation list will now be consistent. > > Benoit has asked for a YANG guideline in rfc6087bis on this issue. > I added the issue with an example to github > https://github.com/netmod-wg/rfc6087bis/issues/35 > > Please comment if you prefer > (A) guideline is be consistent throughout module (whichever choice) > (B) guideline is for use of a container parent > (C) guideline is to not use a container parent > (D) something else I prefer (C). Lada > > > > thanks, > Andy, Martin, and Kent > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 9 04:14:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DA912B076 for ; Thu, 9 Jun 2016 04:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 hyyi5Ivon2WP for ; Thu, 9 Jun 2016 04:14:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA6612D0FD for ; Thu, 9 Jun 2016 04:14:28 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id E95E91AE0426; Thu, 9 Jun 2016 13:14:26 +0200 (CEST) Date: Thu, 09 Jun 2016 13:14:49 +0200 (CEST) Message-Id: <20160609.131449.1039370213863662942.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG library update and new YANG guideline issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 11:14:30 -0000 Ladislav Lhotka wrote: > > > On 09 Jun 2016, at 02:25, Andy Bierman wrote: > > > > Hi, > > > > > > We have been asked to make the YANG library module consistent > > wrt/ use of a container parent for a list. We decided to remove the > > submodules container parent from the child submodule. > > The submodule list and deviation list will now be consistent. > > > > Benoit has asked for a YANG guideline in rfc6087bis on this issue. > > I added the issue with an example to github > > https://github.com/netmod-wg/rfc6087bis/issues/35 > > > > Please comment if you prefer > > (A) guideline is be consistent throughout module (whichever choice) > > (B) guideline is for use of a container parent > > (C) guideline is to not use a container parent > > (D) something else > > > I prefer (C). If the question is: "should I always wrap every list with a container that contains only the list?", then my answer would be "no". I guess that means that I prefer (C) as well. (There might be exceptions, e.g., if the list otherwise would be on the top-level; such as in ietf-interfaces.) /martin From nobody Thu Jun 9 04:31:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41FD12D11A for ; Thu, 9 Jun 2016 04:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bc_avxe8a43i for ; Thu, 9 Jun 2016 04:31:01 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [IPv6:2001:1900:3001:11::28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A333412B076 for ; Thu, 9 Jun 2016 04:31:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 896831E5D81; Thu, 9 Jun 2016 04:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id o6Ab0NOdND6M; Thu, 9 Jun 2016 04:30:47 -0700 (PDT) Received: from [192.168.1.100] (host86-133-84-177.range86-133.btcentralplus.com [86.133.84.177]) by c8a.amsl.com (Postfix) with ESMTPSA id 017FE1E5D7D; Thu, 9 Jun 2016 04:30:46 -0700 (PDT) From: William Lupton Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jun 2016 12:30:58 +0100 To: netmod@ietf.org Message-Id: <339D00A3-FB6A-4D24-B449-60D96CAA2A9B@broadband-forum.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [netmod] Canonical order: linkage and meta X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 11:31:03 -0000 All, RFC 6020bis says =E2=80=9CThe ABNF grammar [RFC5234] [RFC7405] defines = the canonical order. To improve module readability, it is RECOMMENDED = that clauses be entered in this order.=E2=80=9D The ABNF places linkage-stmts (import, include) before meta-stmts = (organization, contact, description, reference) but if there are a lot = of linkage statements (which will be the case in the main module if = there are a large number of submodules=E2=80=A6 as there are for some of = the modules that BBF is defining) this means that the description can be = a fair way down the module. Would there be any support for regarding placement of the meta = statements before the linkage statements as not being a violation of = canonical order? Note (this might be inadvertent) that the ABNF actually = defines =E2=80=9Cmeta-stmts=E2=80=9D before =E2=80=9Clinkage-stmts=E2=80=9D= . Thanks, William= From nobody Thu Jun 9 04:57:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA4612D56F for ; Thu, 9 Jun 2016 04:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 se6gw2HDxrpT for ; Thu, 9 Jun 2016 04:57:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F80712D0CC for ; Thu, 9 Jun 2016 04:57:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3326311D4; Thu, 9 Jun 2016 13:57:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LHAH4VcNKoV7; Thu, 9 Jun 2016 13:57:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Jun 2016 13:57:36 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 30C6D20050; Thu, 9 Jun 2016 13:57:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3ydknx21uJh4; Thu, 9 Jun 2016 13:57:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 642482004E; Thu, 9 Jun 2016 13:57:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B62363B0F039; Thu, 9 Jun 2016 13:57:33 +0200 (CEST) Date: Thu, 9 Jun 2016 13:57:33 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160609115733.GA13942@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG library update and new YANG guideline issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 11:57:40 -0000 On Thu, Jun 09, 2016 at 01:08:36PM +0200, Ladislav Lhotka wrote: > > > On 09 Jun 2016, at 02:25, Andy Bierman wrote: > > > > Hi, > > > > > > We have been asked to make the YANG library module consistent > > wrt/ use of a container parent for a list. We decided to remove the > > submodules container parent from the child submodule. > > The submodule list and deviation list will now be consistent. > > > > Benoit has asked for a YANG guideline in rfc6087bis on this issue. > > I added the issue with an example to github > > https://github.com/netmod-wg/rfc6087bis/issues/35 > > > > Please comment if you prefer > > (A) guideline is be consistent throughout module (whichever choice) > > (B) guideline is for use of a container parent > > (C) guideline is to not use a container parent > > (D) something else > > > I prefer (C). > Is there a reasoning as well? Or just a question of style and taste? /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 Jun 9 05:08:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9F312D0EA for ; Thu, 9 Jun 2016 05:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 Ko2ed3DNsgL0 for ; Thu, 9 Jun 2016 05:08:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A896912B013 for ; Thu, 9 Jun 2016 05:08:43 -0700 (PDT) Received: from [172.16.1.164] (176.100.broadband6.iol.cz [88.101.100.176]) by mail.nic.cz (Postfix) with ESMTPSA id 1C56061696; Thu, 9 Jun 2016 14:08:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465474122; bh=QW1pbMOolbM+uulwgT1dNDoRTjUEiFUq8/Oy0LO6XzU=; h=From:Date:To; b=JpVaupIQdP3RFZPPPz8WvXx7q0onoZbAjxwk50BP32pLiD0zwIqrUI0hy/QQ4CAVJ 2BFOThf0BY8CZArEklqHTQ2usU4g/OkjJwb778BtUbzG35QdWWhMb14qeBQCo0StuL qH6ZoDm3lijWRgLudqpFqrMJn70OwYw5h1BKjCA4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160609115733.GA13942@elstar.local> Date: Thu, 9 Jun 2016 14:08:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0942D433-7817-415B-8197-E746529B8C3A@nic.cz> References: <20160609115733.GA13942@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG library update and new YANG guideline issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 12:08:46 -0000 =20 > On 09 Jun 2016, at 13:57, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jun 09, 2016 at 01:08:36PM +0200, Ladislav Lhotka wrote: >>=20 >>> On 09 Jun 2016, at 02:25, Andy Bierman wrote: >>>=20 >>> Hi, >>>=20 >>>=20 >>> We have been asked to make the YANG library module consistent >>> wrt/ use of a container parent for a list. We decided to remove the >>> submodules container parent from the child submodule. >>> The submodule list and deviation list will now be consistent. >>>=20 >>> Benoit has asked for a YANG guideline in rfc6087bis on this issue. >>> I added the issue with an example to github >>> https://github.com/netmod-wg/rfc6087bis/issues/35 >>>=20 >>> Please comment if you prefer >>> (A) guideline is be consistent throughout module (whichever choice) >>> (B) guideline is for use of a container parent >>> (C) guideline is to not use a container parent >>> (D) something else >>=20 >>=20 >> I prefer (C). >>=20 >=20 > Is there a reasoning as well? Or just a question of style and taste? In JSON encoding (and CBOR as well), the containers make no sense at all = and just add clutter. They are a workaround for the lack of list-like = structures in XML. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 9 05:17:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780D612D596 for ; Thu, 9 Jun 2016 05:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 MlOHM00_43Q8 for ; Thu, 9 Jun 2016 05:17:54 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E415612B012 for ; Thu, 9 Jun 2016 05:17:53 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 9299E1AE018B; Thu, 9 Jun 2016 14:17:52 +0200 (CEST) Date: Thu, 09 Jun 2016 14:18:14 +0200 (CEST) Message-Id: <20160609.141814.1102638375200307227.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <0942D433-7817-415B-8197-E746529B8C3A@nic.cz> References: <20160609115733.GA13942@elstar.local> <0942D433-7817-415B-8197-E746529B8C3A@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG library update and new YANG guideline issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 12:17:56 -0000 Ladislav Lhotka wrote: > > > On 09 Jun 2016, at 13:57, Juergen Schoenwaelder > > wrote: > > > > On Thu, Jun 09, 2016 at 01:08:36PM +0200, Ladislav Lhotka wrote: > >> > >>> On 09 Jun 2016, at 02:25, Andy Bierman wrote: > >>> > >>> Hi, > >>> > >>> > >>> We have been asked to make the YANG library module consistent > >>> wrt/ use of a container parent for a list. We decided to remove the > >>> submodules container parent from the child submodule. > >>> The submodule list and deviation list will now be consistent. > >>> > >>> Benoit has asked for a YANG guideline in rfc6087bis on this issue. > >>> I added the issue with an example to github > >>> https://github.com/netmod-wg/rfc6087bis/issues/35 > >>> > >>> Please comment if you prefer > >>> (A) guideline is be consistent throughout module (whichever choice) > >>> (B) guideline is for use of a container parent > >>> (C) guideline is to not use a container parent > >>> (D) something else > >> > >> > >> I prefer (C). > >> > > > > Is there a reasoning as well? Or just a question of style and taste? > > In JSON encoding (and CBOR as well), the containers make no sense at > all and just add clutter. They are a workaround for the lack of > list-like structures in XML. I prefer if the data models are designed w/o worrying too much about specific encodings or specific protocol issues. With YANG 1.1, we're trying to move slowly in the direction of being more encoding/protocol-neutral. This will fail as soon as data models are designed with some specific encoding / protocol in mind. Such issues need be handled by fixing the encoding / protocol. Another example is that some people prefer (B) b/c then you can delete all entries in a list over NETCONF (by deleting the container). I prefer (C) b/c I think that you should be careful with NP-containers, and only use them when they have some structural meaning. It's like your filesystem; you don't put all files in a single dir, and you don't have one dir per file. You try to keep some meaningful structure. /martin From nobody Thu Jun 9 05:45:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB7A12D5E3 for ; Thu, 9 Jun 2016 05:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 f1ZIR4yOfh7f for ; Thu, 9 Jun 2016 05:45:38 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398AB12D5F4 for ; Thu, 9 Jun 2016 05:45:38 -0700 (PDT) Received: from [172.16.1.164] (176.100.broadband6.iol.cz [88.101.100.176]) by mail.nic.cz (Postfix) with ESMTPSA id 8CB1F6183A; Thu, 9 Jun 2016 14:45:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465476336; bh=TN0oYzbX2dQ/1llSTfc4lmvAjtjvPITo3l//M91tFM8=; h=From:Date:To; b=Px8o0TZP840Q+70v3g/tQosolbHUUj3mP9lVz337KENJfWUHIqeFAM1mP3BaQHzql c4+HzTz8jK9RMAlc7DnIXdoaiiW6Bb3gbSGYoQyf+LHMMltEKT0ffOxpe9k+baduWb HOsOUiE5Reu++O9Ugega45MeCP4LbTX/VikYtA+I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160609.141814.1102638375200307227.mbj@tail-f.com> Date: Thu, 9 Jun 2016 14:45:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <19810430-0857-4FCC-AD7C-600898F5181C@nic.cz> References: <20160609115733.GA13942@elstar.local> <0942D433-7817-415B-8197-E746529B8C3A@nic.cz> <20160609.141814.1102638375200307227.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG library update and new YANG guideline issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 12:45:43 -0000 > On 09 Jun 2016, at 14:18, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 09 Jun 2016, at 13:57, Juergen Schoenwaelder >>> wrote: >>>=20 >>> On Thu, Jun 09, 2016 at 01:08:36PM +0200, Ladislav Lhotka wrote: >>>>=20 >>>>> On 09 Jun 2016, at 02:25, Andy Bierman wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>>=20 >>>>> We have been asked to make the YANG library module consistent >>>>> wrt/ use of a container parent for a list. We decided to remove = the >>>>> submodules container parent from the child submodule. >>>>> The submodule list and deviation list will now be consistent. >>>>>=20 >>>>> Benoit has asked for a YANG guideline in rfc6087bis on this issue. >>>>> I added the issue with an example to github >>>>> https://github.com/netmod-wg/rfc6087bis/issues/35 >>>>>=20 >>>>> Please comment if you prefer >>>>> (A) guideline is be consistent throughout module (whichever = choice) >>>>> (B) guideline is for use of a container parent >>>>> (C) guideline is to not use a container parent >>>>> (D) something else >>>>=20 >>>>=20 >>>> I prefer (C). >>>>=20 >>>=20 >>> Is there a reasoning as well? Or just a question of style and taste? >>=20 >> In JSON encoding (and CBOR as well), the containers make no sense at >> all and just add clutter. They are a workaround for the lack of >> list-like structures in XML. >=20 > I prefer if the data models are designed w/o worrying too much about > specific encodings or specific protocol issues. With YANG 1.1, we're I suspect in this case the preference will be strongly correlated to = the preferred encoding. YANG does have lists (unlike XML schema languages), so having a = (leaf-)list as the only child of a NP container doesn't make much sense = either. =20 > trying to move slowly in the direction of being more > encoding/protocol-neutral. This will fail as soon as data models are > designed with some specific encoding / protocol in mind. Such issues > need be handled by fixing the encoding / protocol. Another example is > that some people prefer (B) b/c then you can delete all entries in a > list over NETCONF (by deleting the container). This should be fixed in NETCONF. >=20 > I prefer (C) b/c I think that you should be careful with > NP-containers, and only use them when they have some structural > meaning. It's like your filesystem; you don't put all files in a > single dir, and you don't have one dir per file. You try to keep some > meaningful structure. Agreed, but the list wrappers have a structural meaning only in the XML = encoding. Lada=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 9 07:42:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E0412D623 for ; Thu, 9 Jun 2016 07:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0tMjXR8b7pIq for ; Thu, 9 Jun 2016 07:42:21 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 11D7212D740 for ; Thu, 9 Jun 2016 07:35:49 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id p204so66038784oih.3 for ; Thu, 09 Jun 2016 07:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=3fVvqD1mcA95dxZFjG9bm4098XruFSyvG9YAIOboSfE=; b=zItnBa5TCw7Y2NBc/wR1Z8EJP2iBSzeKs0QXzKefmj8UiMLGeLaR9S5MxGQ43wertp Bzf8FtZsDTbToHkJWWDLctF1kiU6ACteZTaeFoNHGD/AOMo8aS1J0Xc+/YoCDkw9ryCe A/xxi498Ks0j62wEHj/DV9OrIVnXGylYx4BXD/az3ZHBDKt8T5qVRaRFKn3plRkBlTEo vVGegJBhUOa88g5ws+7778/TOMjtkVGxSN0SW1Gxw+1fUZlQ9XA85Q69r2d1QoF8VAy+ loWR1H8HOQNFf1DUmxFXljpE7aUs7jcVwhXSsJjfRTpjKqzd/MxMrnW9Vf/xsLKobgVQ 1/Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3fVvqD1mcA95dxZFjG9bm4098XruFSyvG9YAIOboSfE=; b=gtOKPc2VuWGJrqwBHFP5NmANKixsz2uyVFyG/+08SQINlEiOItCwgOMU1owvQh/OyG WXFdFWTJpiQA+qBiERRraJ25WwLCDY9urb1qMxUL2NZfJs52E66ezDVZjKQ5W4yoOjsF EKTPsVYL72+NAhClU8IGs/cOW0OEDpYRvmJ9Z/hYcFlVnT7rPFxdB5uoxp38cn62hS4R L0WefLo515AXIr2geMgXmGCTBlgOEc01HMhbUVIkurg/SfbErLaYOFGjH4NLvhyeOgzN fHk46LYEjnRXGBte5KXy1uQzAKIM0bdD9gEMTowbUVHf2d06uccTnEnBw9OwBgr3Acxn P6gA== X-Gm-Message-State: ALyK8tIOGHrXzFDxwZmhzG/lGH+5PRJ00Bd01Esb5WGockbs0xNYbfd97oveVYUyLGyY1g== X-Received: by 10.202.181.131 with SMTP id e125mr5127981oif.12.1465482948299; Thu, 09 Jun 2016 07:35:48 -0700 (PDT) Received: from [192.168.1.150] (108-247-125-249.lightspeed.sntcca.sbcglobal.net. [108.247.125.249]) by smtp.gmail.com with ESMTPSA id r63sm2951995oif.12.2016.06.09.07.35.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 07:35:47 -0700 (PDT) References: <38F48C5F-F8FA-49F0-87F2-C3D27ADBF3C5@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <38F48C5F-F8FA-49F0-87F2-C3D27ADBF3C5@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-02B8F0ED-5023-46EE-BB92-34687FF01CEE Content-Transfer-Encoding: 7bit Message-Id: <4F17C04E-028C-4A71-AA20-0D858FC9771C@gmail.com> X-Mailer: iPad Mail (13E238) From: Mahesh Jethanandani Date: Thu, 9 Jun 2016 07:35:45 -0700 To: Dean Bogdanovic Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 14:42:23 -0000 --Apple-Mail-02B8F0ED-5023-46EE-BB92-34687FF01CEE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dean/Acee, Is this a relevant example of ACL being configured on an interface? http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-2/add= r_serv/configuration/guide/b_ipaddr_cg42a9k/b_ipaddr_cg42a9k_chapter_01.html= #task_1049371 Talking to implementers, the feature is very much desired. Mahesh Jethanandani mjethanandani@gmail.com > On Apr 2, 2016, at 4:39 AM, Dean Bogdanovic wrote: >=20 > Hi Acee, >=20 >> On Mar 31, 2016, at 8:17 AM, Acee Lindem (acee) wrote: >>=20 >> Hi Dean,=20 >>=20 >> From: netmod on behalf of Dean Bogdanovic >> Date: Thursday, March 31, 2016 at 5:26 AM >> To: "Sterne, Jason (Nokia - CA)" >> Cc: netmod WG >> Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-m= odel-07 ? >>=20 >>=20 >>> On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) wrote: >>>=20 >>> Hi all, >>> =20 >>> The ACL model is converging on a small core set of functionality that is= fairly common. >>> =20 >>> But I think the matching on input-interface should be removed from the m= odel (or at the least put inside a feature flag). >>> =20 >>> Matching on basic IPv4/IPv4/MAC header fields is common functionality. B= ut having that input-interface match on metadata in the core model is out of= place. It should be left to further extension drafts or vendor specific au= gmentations (along with whatever other metadata might be useful or vendor-sp= ecific). >>> =20 >>> ACLs are typically assigned to interfaces as shown in section A.3. of th= e ACL draft. That is the most common use case. >>> =20 >>> Actually matching on input-interface in the ACL rules themselves is not b= asic core ACL functionality. Nokia SR OS does not have that capability. Do= es IOS-XR ? Brocade ? others ? >>=20 >> Cisco and Juniper support matching on input interface. It is useful when y= ou want to filter on general traffic coming from interface. >>=20 >> Cisco >> match input-interface >> match input-vlan >>=20 >> These are =E2=80=9Cclass-map=E2=80=9D sub-commands - not =E2=80=9Caccess= -list" sub-commands. So you are referring to the general functionality rathe= r than specifically functionality supported by access-list?=20 >=20 > According to the Cisco website (http://www.cisco.com/c/en/us/td/docs/switc= hes/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/= 3750xscg/swacl.html) >=20 > Note The ACL must be an extended named ACL. >=20 > =E2=80=93 match input-interface interface-id-list > =E2=80=93 match ip dscp dscp-list > =E2=80=93 match ip precedence ip-precedence-list >=20 >>=20 >>=20 >>=20 >> Junos >> family any { >> filter L2_filter { >> term t1 { >> from { >> interface fe-0/0/0.0; >> } >> then { >> policer p1; >> count c1; >> } >> } >> } >> } >>=20 >> Brocade supports matching based on interface, Dell supports VLAN matching= , Arista supports input interface matching, Redback supports matching agains= t input interface for logging, >>=20 >> If you are referring to =E2=80=9Clog-input=E2=80=9D, this indicates to in= clude the input-interface in the log message. Cisco supports this as well.=20= >>=20 >> Thanks, >> Acee=20 >>=20 >>=20 >> so it is pretty standard across multiple vendors >>=20 >> Dean >>=20 >>> If some major implementations don=E2=80=99t do it, and it isn=E2=80= =99t necessary for typical basic ACL use, then it should be removed (or feat= ure flagged). >>> =20 >>> Regards, >>> Jason=20 >>> =20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail-02B8F0ED-5023-46EE-BB92-34687FF01CEE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dean/Acee,

Is this a relevant example= of ACL being configured on an interface?


Talking to implementers, the feature is very much desired.
Mahesh Jethanandani

On Apr 2, 2016, at 4:39 AM, Dean Bo= gdanovic <ivandean@gmail.com>= ; wrote:

Hi Acee,

On Mar 31, 2016, at 8:17 AM, Acee Lindem (ac= ee) <acee@cisco.com> w= rote:

Hi Dean, 

From: netmod <netmod-bounces@ietf.org> o= n behalf of Dean Bogdanovic <ivandean@gmail.com>
Date: Thursday, March 31,= 2016 at 5:26 AM
To: "Sterne, Jason (Nokia= - CA)" <jason.stern= e@nokia.com>
Cc: netmod WG <netmod@ietf.org>
Subject: Re: [netmod] Rem= ove input-interface (metadata) from netmod-acl-model-07 ?


On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) <= jason.sterne@nokia.com<= /a>> wrote:

Hi all,
 
The ACL model is converging on a small core set of functiona= lity that is fairly common.
 
But I think the matching on input-interface should be remove= d from the model (or at the least put inside a feature flag).
 
Matching on basic IPv4/IPv4/MAC header fields is common func= tionality.  But having that input-interface match on metadata in the co= re model is out of place.  It should be left to further extension draft= s or vendor specific augmentations (along with whatever other metadata might be useful or vendor-specific).
 
ACLs are typically assigned to interfaces as shown in sectio= n A.3. of the ACL draft.   That is the most common use case.
=
 
Actually matching on input-interface in the ACL rules themse= lves is not basic core ACL functionality.  Nokia SR OS does not have th= at capability.  Does IOS-XR ?  Brocade ?  others ?

Cisco and Juniper support matching on input interface. It is= useful when you want to filter on general traffic coming from interface.

Cisco
match input-interface
match input-vlan

These are =E2=80=9Cclass-map=E2=80=9D  sub-commands - n= ot =E2=80=9Caccess-list" sub-commands. So you are referring to the general f= unctionality rather than specifically functionality supported by access-list= ? 

According to= the Cisco website (http://www.cisco.com/c/en/us/td/docs/switches/l= an/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750x= scg/swacl.html)

Note The ACL must be an ext= ended named ACL.

=E2=80=93<blank.gif> match input-interface interface-id-list

=E2=80=93<blank.gif> = match ip dscp dscp-list

=E2=80=93<blank.gif> match ip precedence=  ip-precedence-list





Junos
family any {
filter L2_filter {
term t1 {
from {
interface fe-0/0/0.0;
}
then {
policer p1;
count c1;
}
}
}
}

Brocade supports matching based on interface, Dell supports V= LAN matching, Arista supports input interface matching, Redback supports mat= ching against input interface for logging,

If you are referring to =E2=80=9Clog-input=E2=80=9D, this in= dicates to include the input-interface in the log message. Cisco supports th= is as well. 

Thanks,
Acee 


so it is pretty standard across multiple vendors

Dean

     If some major implementations don=E2= =80=99t do it, and it isn=E2=80=99t necessary for typical basic ACL use, the= n it should be removed (or feature flagged).
 
Regards,
Jason 
 
__________= _____________________________________
netmod mailing list
netmod@ietf.org
https://www.iet= f.org/mailman/listinfo/netmod

____________________________________________= ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod=
= --Apple-Mail-02B8F0ED-5023-46EE-BB92-34687FF01CEE-- From nobody Thu Jun 9 07:58:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B744112D829 for ; Thu, 9 Jun 2016 07:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 RbVpItAU7el0 for ; Thu, 9 Jun 2016 07:58:39 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD35A12D823 for ; Thu, 9 Jun 2016 07:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7000; q=dns/txt; s=iport; t=1465484318; x=1466693918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Wfx7D1sk5qJBvGsEbgwigWRccDgqjPqFhPjzllEpF20=; b=Q7JQhBPHpNTZaODieH/sfICcYEVkmLWPzSjUl86+0GQzDVrUo1R3YRdw ouLRbEH4QkBP6i4/Ef8jmz/QLiMnUB5s+fEOT5JMCsYDmM7jcf+MKaaM4 SIXHqEZI8A5fZkcV6mw/xj80u3KetDd9DNCyzVvz0qyS5qTwDGkHsvPNr 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AQDSg1lX/5RdJa1egz5WfQavEot/g?= =?us-ascii?q?XoXDYI8gmlKAhyBGTgUAQEBAQEBAWUnhEUBAQEEAQEBIBE6CxACAQgOAwMBAgE?= =?us-ascii?q?CAiYCAgIfBgsVCAgCBAENBYgVAxcOrQqNAw2DfwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARyBAYlzgkOBfYMBglkFjWqFPYR6NAGMLIF6imKEPod5h2sBHjaDbm6JCX8?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.26,445,1459814400"; d="scan'208";a="113331786" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 14:58:10 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u59Ew91d028311 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jun 2016 14:58:10 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 10:58:09 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 9 Jun 2016 10:58:08 -0400 From: "Acee Lindem (acee)" To: Mahesh Jethanandani , Dean Bogdanovic Thread-Topic: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? Thread-Index: AQHRiy9QFzBlKCUK2Eu8wY4yL7QnTp9zZ1EAgANuIACAaw+ogP//wy+A Date: Thu, 9 Jun 2016 14:58:08 +0000 Message-ID: References: <38F48C5F-F8FA-49F0-87F2-C3D27ADBF3C5@gmail.com> <4F17C04E-028C-4A71-AA20-0D858FC9771C@gmail.com> In-Reply-To: <4F17C04E-028C-4A71-AA20-0D858FC9771C@gmail.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="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 14:58:41 -0000 SGkgTWFoZXNoLCANCg0KRnJvbTogIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlA Z21haWwuY29tPg0KRGF0ZTogIFRodXJzZGF5LCBKdW5lIDksIDIwMTYgYXQgMTA6MzUgQU0NClRv OiAgRGVhbiBCb2dkYW5vdmljIDxpdmFuZGVhbkBnbWFpbC5jb20+DQpDYzogIEFjZWUgTGluZGVt IDxhY2VlQGNpc2NvLmNvbT4sIG5ldG1vZCBXRyA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDog IFJlOiBbbmV0bW9kXSBSZW1vdmUgaW5wdXQtaW50ZXJmYWNlIChtZXRhZGF0YSkgZnJvbQ0KbmV0 bW9kLWFjbC1tb2RlbC0wNyA/DQoNCg0KPkRlYW4vQWNlZSwNCj4NCj4NCg0KSSBpbml0aWFsbHkg bWlzcmVhZCB0aGlzIGFzIOKAnERlYXIgQWNlZeKAnSA7XikNCg0KPg0KPklzIHRoaXMgYSByZWxl dmFudCBleGFtcGxlIG9mIEFDTCBiZWluZyBjb25maWd1cmVkIG9uIGFuIGludGVyZmFjZT8NCj4N Cj5odHRwOi8vd3d3LmNpc2NvLmNvbS9jL2VuL3VzL3RkL2RvY3Mvcm91dGVycy9hc3I5MDAwL3Nv ZnR3YXJlL2FzcjlrX3I0LTIvYQ0KPmRkcl9zZXJ2L2NvbmZpZ3VyYXRpb24vZ3VpZGUvYl9pcGFk ZHJfY2c0MmE5ay9iX2lwYWRkcl9jZzQyYTlrX2NoYXB0ZXJfMDEuDQo+aHRtbCN0YXNrXzEwNDkz NzENCj4NCj4NCg0KSW4gdGhlIHNhbWUgd2F5IEkgbWlzcmVhZCB5b3VyIHNhbHV0YXRpb24sIEkg dGhpbmsgeW914oCZdmUgbWlzaW50ZXJwcmV0ZWQNCnRoaXMgZXhhbXBsZSBhcyBpdCBhcHBsaWVz IHRvIGluY2x1ZGluZyBpbnRlcmZhY2UgaW4gdGhlIEFDTCBtb2RlbC4gSWYgeW91DQpleGFtaW5l IHRoZSByZWZlcmVuY2VkIGNvbmZpZ3VyYXRpb24gaHRtbCBjbG9zZWx5LCB5b3XigJlsbCBzZWUg dGhhdCB0aGUgQUNMDQppcyBhIHJldXNhYmxlIHBhY2tldC1tYXRjaGluZyBwb2xpY3kgdGhhdCBp cyBhcHBsaWVkIHRvIGFuIGludGVyZmFjZQ0KcmF0aGVyIHRoYW4gdGhlIGludGVyZmFjZSBiZWlu ZyBpbmNsdWRlZCBpbiB0aGUgQUNMIHJ1bGVzIHRoZW1zZWx2ZXMuIEluDQpJT1MtWFIsIHRoZSBj b21tYW5kIHRvIGFwcGx5IHRoZSBBQ0wgdG8gYW4gaW50ZXJmYWNlIGlzIOKAnHtpcHY0IHwgaXB2 Nn0NCmFjY2Vzcy1ncm91cCA8YWNsLW5hbWU+4oCdIHNwZWNpZmllZCBpbiBpbnRlcmZhY2UgY29u ZmlndXJhdGlvbiBzdWJtb2RlLiBJcw0KdGhlcmUgc29tZXRoaW5nIGluIHRoZSB0ZXh0IHRoYXQg SeKAmW0gbWlzc2luZz8NCg0KPg0KPlRhbGtpbmcgdG8gaW1wbGVtZW50ZXJzLCB0aGUgZmVhdHVy ZSBpcyB2ZXJ5IG11Y2ggZGVzaXJlZC4NCj4NCj4NCg0KQXMgdGhlIGluaXRpYWwgaW1wbGVtZW50 b3Igb2YgdGhlIGZ1bmN0aW9uIG9uIFJlZGJhY2sgU0VPUyAobm93IEVyaWNzc29uDQpJUE9TKSwg SSBjYW4gY29uZmlybSB0aGF0IGF0dGFjaGluZyBhbiBBQ0wgdG8gYW4gaW50ZXJmYWNlIGlzLCBp bmRlZWQsIGFuDQplc3NlbnRpYWwgZnVuY3Rpb24uDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KDQo+ DQo+DQo+TWFoZXNoIEpldGhhbmFuZGFuaQ0KPm1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQo+DQo+ DQo+T24gQXByIDIsIDIwMTYsIGF0IDQ6MzkgQU0sIERlYW4gQm9nZGFub3ZpYyA8aXZhbmRlYW5A Z21haWwuY29tPiB3cm90ZToNCj4NCj4NCj4NCj5IaSBBY2VlLA0KPg0KPg0KPk9uIE1hciAzMSwg MjAxNiwgYXQgODoxNyBBTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT4gd3Jv dGU6DQo+DQo+SGkgRGVhbiwgDQo+DQo+RnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRm Lm9yZz4gb24gYmVoYWxmIG9mIERlYW4gQm9nZGFub3ZpYw0KPjxpdmFuZGVhbkBnbWFpbC5jb20+ DQo+RGF0ZTogVGh1cnNkYXksIE1hcmNoIDMxLCAyMDE2IGF0IDU6MjYgQU0NCj5UbzogIlN0ZXJu ZSwgSmFzb24gKE5va2lhIC0gQ0EpIiA8amFzb24uc3Rlcm5lQG5va2lhLmNvbT4NCj5DYzogbmV0 bW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc+DQo+U3ViamVjdDogUmU6IFtuZXRtb2RdIFJlbW92ZSBp bnB1dC1pbnRlcmZhY2UgKG1ldGFkYXRhKSBmcm9tDQo+bmV0bW9kLWFjbC1tb2RlbC0wNyA/DQo+ DQo+DQo+Pg0KPj4NCj4+T24gTWFyIDMwLCAyMDE2LCBhdCA5OjM2IFBNLCBTdGVybmUsIEphc29u IChOb2tpYSAtIENBKQ0KPj48amFzb24uc3Rlcm5lQG5va2lhLmNvbT4gd3JvdGU6DQo+Pg0KPj5I aSBhbGwsDQo+PiANCj4+VGhlIEFDTCBtb2RlbCBpcyBjb252ZXJnaW5nIG9uIGEgc21hbGwgY29y ZSBzZXQgb2YgZnVuY3Rpb25hbGl0eSB0aGF0IGlzDQo+PmZhaXJseSBjb21tb24uDQo+PiANCj4+ QnV0IEkgdGhpbmsgdGhlIG1hdGNoaW5nIG9uIGlucHV0LWludGVyZmFjZSBzaG91bGQgYmUgcmVt b3ZlZCBmcm9tIHRoZQ0KPj5tb2RlbCAob3IgYXQgdGhlIGxlYXN0IHB1dCBpbnNpZGUgYSBmZWF0 dXJlIGZsYWcpLg0KPj4gDQo+Pk1hdGNoaW5nIG9uIGJhc2ljIElQdjQvSVB2NC9NQUMgaGVhZGVy IGZpZWxkcyBpcyBjb21tb24gZnVuY3Rpb25hbGl0eS4NCj4+QnV0IGhhdmluZyB0aGF0IGlucHV0 LWludGVyZmFjZSBtYXRjaCBvbiBtZXRhZGF0YSBpbiB0aGUgY29yZSBtb2RlbCBpcw0KPj5vdXQg b2YgcGxhY2UuICBJdCBzaG91bGQgYmUgbGVmdCB0byBmdXJ0aGVyIGV4dGVuc2lvbiBkcmFmdHMg b3IgdmVuZG9yDQo+PnNwZWNpZmljIGF1Z21lbnRhdGlvbnMgKGFsb25nDQo+PiB3aXRoIHdoYXRl dmVyIG90aGVyIG1ldGFkYXRhIG1pZ2h0IGJlIHVzZWZ1bCBvciB2ZW5kb3Itc3BlY2lmaWMpLg0K Pj4NCj4+DQo+PiANCj4+QUNMcyBhcmUgdHlwaWNhbGx5IGFzc2lnbmVkIHRvIGludGVyZmFjZXMg YXMgc2hvd24gaW4gc2VjdGlvbiBBLjMuIG9mDQo+PnRoZSBBQ0wgZHJhZnQuICAgVGhhdCBpcyB0 aGUgbW9zdCBjb21tb24gdXNlIGNhc2UuDQo+PiANCj4+QWN0dWFsbHkgbWF0Y2hpbmcgb24gaW5w dXQtaW50ZXJmYWNlIGluIHRoZSBBQ0wgcnVsZXMgdGhlbXNlbHZlcyBpcyBub3QNCj4+YmFzaWMg Y29yZSBBQ0wgZnVuY3Rpb25hbGl0eS4gIE5va2lhIFNSIE9TIGRvZXMgbm90IGhhdmUgdGhhdA0K Pj5jYXBhYmlsaXR5LiAgRG9lcyBJT1MtWFIgPyAgQnJvY2FkZSA/ICBvdGhlcnMgPw0KPj4NCj4+ DQo+Pg0KPj4NCj4+Q2lzY28gYW5kIEp1bmlwZXIgc3VwcG9ydCBtYXRjaGluZyBvbiBpbnB1dCBp bnRlcmZhY2UuIEl0IGlzIHVzZWZ1bCB3aGVuDQo+PnlvdSB3YW50IHRvIGZpbHRlciBvbiBnZW5l cmFsIHRyYWZmaWMgY29taW5nIGZyb20gaW50ZXJmYWNlLg0KPj4NCj4+Q2lzY28NCj4+bWF0Y2gg aW5wdXQtaW50ZXJmYWNlDQo+Pm1hdGNoIGlucHV0LXZsYW4NCj4+DQo+Pg0KPj4NCj4+DQo+DQo+ VGhlc2UgYXJlIOKAnGNsYXNzLW1hcOKAnSAgc3ViLWNvbW1hbmRzIC0gbm90IOKAnGFjY2Vzcy1s aXN0IiBzdWItY29tbWFuZHMuIFNvDQo+eW91IGFyZSByZWZlcnJpbmcgdG8gdGhlIGdlbmVyYWwg ZnVuY3Rpb25hbGl0eSByYXRoZXIgdGhhbiBzcGVjaWZpY2FsbHkNCj5mdW5jdGlvbmFsaXR5IHN1 cHBvcnRlZCBieSBhY2Nlc3MtbGlzdD8NCj4NCj4NCj4NCj4NCj4NCj5BY2NvcmRpbmcgdG8gdGhl IENpc2NvIHdlYnNpdGUNCj4oaHR0cDovL3d3dy5jaXNjby5jb20vYy9lbi91cy90ZC9kb2NzL3N3 aXRjaGVzL2xhbi9jYXRhbHlzdDM3NTB4XzM1NjB4L3NvZg0KPnR3YXJlL3JlbGVhc2UvMTItMl81 NV9zZS9jb25maWd1cmF0aW9uL2d1aWRlLzM3NTB4c2NnL3N3YWNsLmh0bWwpDQo+DQo+Tm90ZSBU aGUgQUNMIG11c3QgYmUgYW4gZXh0ZW5kZWQgbmFtZWQgQUNMLg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4NCj7igJM8YmxhbmsuZ2lmPiBtYXRjaCBpbnB1 dC1pbnRlcmZhY2UgaW50ZXJmYWNlLWlkLWxpc3QNCj7igJM8YmxhbmsuZ2lmPiBtYXRjaCBpcCBk c2NwIGRzY3AtbGlzdA0KPuKAkzxibGFuay5naWY+IG1hdGNoIGlwIHByZWNlZGVuY2UgaXAtcHJl Y2VkZW5jZS1saXN0DQo+DQo+DQo+DQo+Pg0KPj4NCj4+SnVub3MNCj4+ZmFtaWx5IGFueSB7DQo+ PmZpbHRlciBMMl9maWx0ZXIgew0KPj50ZXJtIHQxIHsNCj4+ZnJvbSB7DQo+PmludGVyZmFjZSBm ZS0wLzAvMC4wOw0KPj59DQo+PnRoZW4gew0KPj5wb2xpY2VyIHAxOw0KPj5jb3VudCBjMTsNCj4+ fQ0KPj59DQo+Pn0NCj4+fQ0KPj4NCj4+QnJvY2FkZSBzdXBwb3J0cyBtYXRjaGluZyBiYXNlZCBv biBpbnRlcmZhY2UsIERlbGwgc3VwcG9ydHMgVkxBTg0KPj5tYXRjaGluZywgQXJpc3RhIHN1cHBv cnRzIGlucHV0IGludGVyZmFjZSBtYXRjaGluZywgUmVkYmFjayBzdXBwb3J0cw0KPj5tYXRjaGlu ZyBhZ2FpbnN0IGlucHV0IGludGVyZmFjZSBmb3IgbG9nZ2luZywNCj4+DQo+Pg0KPj4NCj4+DQo+ Pg0KPg0KPklmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIOKAnGxvZy1pbnB1dOKAnSwgdGhpcyBpbmRp Y2F0ZXMgdG8gaW5jbHVkZSB0aGUNCj5pbnB1dC1pbnRlcmZhY2UgaW4gdGhlIGxvZyBtZXNzYWdl LiBDaXNjbyBzdXBwb3J0cyB0aGlzIGFzIHdlbGwuDQo+DQo+VGhhbmtzLA0KPkFjZWUgDQo+DQo+ DQo+PnNvIGl0IGlzIHByZXR0eSBzdGFuZGFyZCBhY3Jvc3MgbXVsdGlwbGUgdmVuZG9ycw0KPj4N Cj4+RGVhbg0KPj4NCj4+DQo+Pg0KPj4gICAgIElmIHNvbWUgbWFqb3IgaW1wbGVtZW50YXRpb25z IGRvbuKAmXQgZG8gaXQsIGFuZCBpdCBpc27igJl0IG5lY2Vzc2FyeQ0KPj5mb3IgdHlwaWNhbCBi YXNpYyBBQ0wgdXNlLCB0aGVuIGl0IHNob3VsZCBiZSByZW1vdmVkIChvciBmZWF0dXJlDQo+PmZs YWdnZWQpLg0KPj4gDQo+PlJlZ2FyZHMsDQo+Pkphc29uIA0KPj4gDQo+Pl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pm5ldG1vZA0KPj4gbWFpbGluZyBs aXN0DQo+Pm5ldG1vZEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZA0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4NCj4NCj4NCj4NCj4N Cj4NCj4NCj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Thu Jun 9 08:41:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC10712D6B5 for ; Thu, 9 Jun 2016 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 joZf2Kf8q4MC for ; Thu, 9 Jun 2016 08:41:34 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6F912D791 for ; Thu, 9 Jun 2016 08:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12704; q=dns/txt; s=iport; t=1465486891; x=1466696491; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=gEQ5gxjeTPTdJWbAVju51f3oFWzFaZ9m1k44/pDqj9I=; b=RM6i6BW/BT/mLZqgWtXYvujr91CRfDfhh3bp7WKNvxZex38zh751aZBe J/m4xPv7jTdye24GVZWGAHfJOWkHjDS6WHVPjTOwo3WNJXKPcJSVyncMc c5OZjvZo8R60BIC+orxuy5Cmms75ran2oguHKU4WEszIDpxMMsT1L5PAO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAQDljVlX/xbLJq1ehBQrUrYbgnCCD?= =?us-ascii?q?4F6JIVvAoFtFAEBAQEBAQFlJ4RFAQEBBCNmHAMBAisCAk0CCAYNBgIBAQULAga?= =?us-ascii?q?IEw4DrReRCAEBAQEBAQEBAQEBAQEBAQEBAR+ECYIegXeCVoJZgXMUgmGCWQWJc?= =?us-ascii?q?olKhRmGA4gkgjeHDYVcj2UeNoNwOjIBigcBAQE?= X-IronPort-AV: E=Sophos;i="5.26,445,1459814400"; d="scan'208,217";a="677634958" 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; 09 Jun 2016 15:41:27 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u59FfQao003145 for ; Thu, 9 Jun 2016 15:41:27 GMT References: To: NETMOD Working Group From: Benoit Claise X-Forwarded-Message-Id: Message-ID: Date: Thu, 9 Jun 2016 17:41:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------38FA0726D1FCD20D6C19AF6F" Archived-At: Subject: [netmod] Fwd: YANG Model Coordination Group directory closure X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 15:41:40 -0000 This is a multi-part message in MIME format. --------------38FA0726D1FCD20D6C19AF6F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit FYI. -------- Forwarded Message -------- Subject: YANG Model Coordination Group directory closure Date: Thu, 9 Jun 2016 17:35:07 +0200 From: Benoit Claise To: IETF-Discussion list , yang-coord@ietf.org Dear all, The YANG Model Coordination Group has been a success, and has served its purpose. The plan and the time commitment (each person committed to spend 1/3 of his time) for this group were ambitious: * Phase 1: List of the YANG models (inventory) * Phase 2: Tooling * Phase 3: Help with compilation * Phase 4: Training & Education * Phase 5: Coordination across SDOs/Opensource * Phase 6: Model Coordination within the IETF * Phase 7: Standardization Priorities Let's review the achievements. Quiet impressive for a couple of volunteers if you ask me. Phase 1: List of the YANG models (inventory) Extracted all YANG data models from IETF drafts and RFCs on http://www.claise.be/ Started to work on YANG data model catalog for the industry Phase 2: Tooling YANG data models extraction from drafts/RFCs YANG data models dependency visualization YANG data model grouping extraction and compilation Created http://www.yangvalidator.org/ pyang integration in idnits/tracker pyang plugin for the YANG data model catalog Along the process we filed a couple of pyang bugs Organized the YANG track at the IETF Hackathon etc. Phase 3: Help with compilation Proactively contacted the IETF draft authors, discussing their compilation error messages Kept track of the situation here Flagged the duplicate YANG module names, groupings, etc. Phase 4: Training & Education Created some training materials, presented at IETF94 NETCONF Slides , YANG Slides , pyang Slides Phase 5: Coordination across SDOs/Opensource Coordinated with the IEEE/MEF/BBF, amongst others Worked on the YANG Data Model Classification, accepted as NETMOD WG document Based on github, we're compiling the IEEE/BBF/Opendaylight/openconfig data models Helped on URN for different SDOs YANG Modeling Efforts in the Industry Phase 6: Model Coordination within the IETF We helped with the coordination, even if the YANG routing design team contributed significantly for the routing aspects. Phase 7: Standardization Priorities This is maybe where we haven't had enough time to dedicate, even if we have identified the next steps. See YANG Data Models in the Industry: Current State of Affairs I probably missed some of the achievements. Sorry about that. Let's analyze the current situation! It's difficult, in a voluntary-based organization to dedicate so much time on this YANG effort. On the other hand, this group efforts helped with the heavy-lifting job to promote YANG in the industry. Thanks for that. These days, even if it doesn't translate yet in many RFC numbers, YANG became a mature technology, which can now rely on a bigger community. I expect that the YANG doctors to take over some of the effort here, helping with the proactive review of YANG data models. More on this later. Regarding the tooling aspects, the IETF hackathon will continue to play an important role: a couple of people signed up already Thanks to Carl, Dean, and Qin as YANG Model Coordination Group members, and to many others who helped directly or indirectly. I will now request to close this directorate. Regards, Benoit (OPS AD) --------------38FA0726D1FCD20D6C19AF6F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit FYI.


-------- Forwarded Message --------
Subject: YANG Model Coordination Group directory closure
Date: Thu, 9 Jun 2016 17:35:07 +0200
From: Benoit Claise <bclaise@cisco.com>
To: IETF-Discussion list <ietf@ietf.org>, yang-coord@ietf.org <yang-coord@ietf.org>


Dear all,

The YANG Model Coordination Group has been a success, and has served its purpose.

The plan and the time commitment (each person committed to spend 1/3 of his time) for this group were ambitious:
  • Phase 1: List of the YANG models (inventory)
  • Phase 2: Tooling
  • Phase 3: Help with compilation
  • Phase 4: Training & Education
  • Phase 5: Coordination across SDOs/Opensource
  • Phase 6: Model Coordination within the IETF
  • Phase 7: Standardization Priorities
Let's review the achievements. Quiet impressive for a couple of volunteers if you ask me.

Phase 1: List of the YANG models (inventory)
    Extracted all YANG data models from IETF drafts and RFCs on http://www.claise.be/
    Started to work on YANG data model catalog for the industry

Phase 2: Tooling
    YANG data models extraction from drafts/RFCs
    YANG data models dependency visualization
    YANG data model grouping extraction and compilation
    Created http://www.yangvalidator.org/
    pyang integration in idnits/tracker
    pyang plugin for the YANG data model catalog
    Along the process we filed a couple of pyang bugs
    Organized the YANG track at the IETF Hackathon
    etc.

Phase 3: Help with compilation
    Proactively contacted the IETF draft authors, discussing their compilation error messages
    Kept track of the situation here
    Flagged the duplicate YANG module names, groupings, etc.

Phase 4: Training & Education
    Created some training materials, presented at IETF94
    NETCONF Slides, YANG Slides, pyang Slides

Phase 5: Coordination across SDOs/Opensource
    Coordinated with the IEEE/MEF/BBF, amongst others
    Worked on the YANG Data Model Classification, accepted as NETMOD WG document
    Based on github, we're compiling the IEEE/BBF/Opendaylight/openconfig data models
    Helped on URN for different SDOs
    YANG Modeling Efforts in the Industry

Phase 6: Model Coordination within the IETF
    We helped with the coordination, even if the YANG routing design team
    contributed significantly for the routing aspects.

Phase 7: Standardization Priorities
    This is maybe where we haven't had enough time to dedicate,
    even if we have identified the next steps.
    See YANG Data Models in the Industry: Current State of Affairs

I probably missed some of the achievements. Sorry about that.

Let's analyze the current situation!
It's difficult, in a voluntary-based organization to dedicate so much time on this YANG effort. On the other hand, this group efforts helped with the heavy-lifting job to promote YANG in the industry. Thanks for that. These days, even if it doesn't translate yet in many RFC numbers, YANG became a mature technology, which can now rely on a bigger community.
I expect that the YANG doctors to take over some of the effort here, helping with the proactive review of YANG data models. More on this later.
Regarding the tooling aspects, the IETF hackathon will continue to play an important role: a couple of people signed up already

Thanks to Carl, Dean, and Qin as YANG Model Coordination Group members, and to many others who helped directly or indirectly.

I will now request to close this directorate.

Regards, Benoit (OPS AD)
--------------38FA0726D1FCD20D6C19AF6F-- From nobody Thu Jun 9 12:54:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E09012D180 for ; Thu, 9 Jun 2016 12:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 YNRK_MGsJ0HG for ; Thu, 9 Jun 2016 12:54:07 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 F328712D146 for ; Thu, 9 Jun 2016 12:54:04 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-08v.sys.comcast.net with SMTP id B61GbNaSElVqIB61kbHzz5; Thu, 09 Jun 2016 19:54:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465502044; bh=ll+RkfeQZRYkHhflcFtenK8j/xX2OkPDDSB9hCuRO1s=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ZvPcI/Aetsozu31lntS9RAT5gzAD2AF2fTZbQghox7pU/Jka86dDL+gB+inxyfUp3 DIqS7ruyUSNDnib1PokUhXDz/0ts826xEcPKPklsVSZtgeKlOz0rGpTf/CdUPp5X/I 6sfMr7WZol/XVZrSxLtz2nHeg+wxLaPeLBLh8ITeXnh2X2IXJU/neR0G8R8SK/gPMc pFzJZFaUaiAtCqNR79vIuIsAhz6B3DF/0i3cCnaV19hJAxfVFdzSiXp3s5qUrmVeG1 n2KCAIzIMYkGXfNMAMnnAv2tgtssg/QLaDGto5fXOYEiMpN1F0vf6/5nIMJ+2o5seH WjEJ+VjhIYIhQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-08v.sys.comcast.net with comcast id 4ju31t0091nMCLR01ju3b0; Thu, 09 Jun 2016 19:54:04 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u59Js2Kd003327; Thu, 9 Jun 2016 15:54:02 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u59Js2ZT003324; Thu, 9 Jun 2016 15:54:02 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund In-Reply-To: <20160609.094259.2082528782584874294.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 09 Jun 2016 15:54:02 -0400 Message-ID: <87oa7a3zqd.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Replacing a YANG submodule with a module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 19:54:08 -0000 Martin Bjorklund writes: >> If I understand Yang correctly, that error can't be fixed by revising >> the new module test to clone mod:util as test:util, because though the >> new grouping is semantically identical to the old grouping, it's still a >> change in its definition: > > Hmm, why do you think that this isn't allowed? If the syntax and > semantics are the same it should be allowed. Section 11 has: > > - Any set of data definition nodes may be replaced with another set of > syntactically and semantically equivalent nodes. For example, a set > of leafs may be replaced by a uses of a grouping with the same > leafs. Ugh, that's my mistake. I started skimming the list of criteria and saw that they were all specific changes as to what was allowed and didn't realize that the ones near the bottom were quite general. In that case, this version should be OK in that the grouping util is still defined by module test: module test { namespace "urn:bbf:yang:test"; prefix test; import mod { prefix mod; revision-date 2016-06-08; } revision 2016-06-08 { } uses mod:util; + grouping util { + uses mod:util; + } } Dale From nobody Thu Jun 9 14:08:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5849812DA06 for ; Thu, 9 Jun 2016 14:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 RiSFR9PgqdF8 for ; Thu, 9 Jun 2016 14:08:47 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 139EA12D9FE for ; Thu, 9 Jun 2016 14:08:47 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-02v.sys.comcast.net with SMTP id B7A9bbQLOQRyhB7C2bNFAk; Thu, 09 Jun 2016 21:08:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465506526; bh=66jiUr1n6puCy3pN0O5ATgEYoC+dDqzu63OpmQgKQps=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=X6DeI8AKomu3ttgnv+m1m79Q+aaPCvjuE/3RKigfK+kFp0FMG4fTLYa+TZ7wSoe/Z ACtZj3JR1X3cbRhqsu476F+zn58Ohnekooo4z0WNhI3EIIWr5fUChK03pISC9czXio wSj/R1+gR7lEWIEAwbsswUCPbJaViEIerJaaVRc5IbV08SuIBFCgmk3HiYDuvI33EB uRsd6Do6iKsSpmlHq2qgZPIF1GAvnpOaMdAZ/SNoXBacDJAASDJAyrlhv52aG5TcXG 43vj6BWf2uZ9wJSjbJMAjD/F0SQ2t40ZcD12vX9+MXZuyycpt7kg4mo12qQ2dnZlFC 9ddJAfRKZJcIQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-11v.sys.comcast.net with comcast id 4l8l1t00S1nMCLR01l8llJ; Thu, 09 Jun 2016 21:08:46 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u59L8jQx011058; Thu, 9 Jun 2016 17:08:45 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u59L8ivP011055; Thu, 9 Jun 2016 17:08:44 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund In-Reply-To: <20160608.224552.2069028097678997544.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 09 Jun 2016 17:08:44 -0400 Message-ID: <87y46e2hpf.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 21:08:48 -0000 Martin Bjorklund writes: > Do you have an suggestion for what to write? These kinds of > multi-line strings are almost always 'description' statements, > used for human consumption. It is not clear to me what the warning > would be. >> So you can't write an isolated CR in most of a Yang module. But am I >> correct in understanding that you *can* write an isolated CR inside a >> single-quoted string (and presumably, a double-quoted string)? > > Yes. I think all of this could be summarized well by putting a paragraph that tells everything about line ends in Yang at the end of section 6. Section 6 already deals with the valid characaters for Yang, how they're encoded, etc. Lines in a YANG module may end with a carriage return-line feed combination or with a line feed alone. A carriage return that is not followed by a line feed may only appear inside a quoted string. Note that carriage returns and line feeds that appear inside quoted strings become part of the value of the string without modification; the value of a multi-line quoted string contains the same form of line ends as those lines of the YANG module. In a way, that doesn't add much to the specification. As I think you said, "Line ends aren't special in Yang." But it does spell out exactly when CR and LF can be used, and it warns readers against misleading analogies from other programming languages (where line ends usually are special). Dale From nobody Thu Jun 9 14:10:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1E212D9FE for ; Thu, 9 Jun 2016 14:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=kuatrotechnology.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 fcEG35-5b05Y for ; Thu, 9 Jun 2016 14:10:08 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0657.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::657]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E0512D7AD for ; Thu, 9 Jun 2016 14:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UY3eqFWH2HpsvUH8Di1ubSTKBTdxL2lqGjv/LLmN/sE=; b=I+WTn91fV59BXUdNDE4YT2eiJTn9K3IsUWUyhcv6q8b+uEFgnuqyBWMftuduv2NGY7jMPgnNx9pnxHR3bLebZAYEOyoGDUFjo1I/SD8eaYHPobKNdQK9P44bK/3Vt1VSZsPbeJ+gA79OuAi8ZPFqowm71HrFoP9pLEr5eNnSKaA= Received: from HE1PR06MB0955.eurprd06.prod.outlook.com (10.162.251.141) by HE1PR06MB0956.eurprd06.prod.outlook.com (10.162.251.142) with Microsoft SMTP Server (TLS) id 15.1.517.2; Thu, 9 Jun 2016 21:06:33 +0000 Received: from HE1PR06MB0955.eurprd06.prod.outlook.com ([10.162.251.141]) by HE1PR06MB0955.eurprd06.prod.outlook.com ([10.162.251.141]) with mapi id 15.01.0517.005; Thu, 9 Jun 2016 21:06:32 +0000 From: "Ing-Wher (Helen) Chen" To: Alex Campbell Thread-Topic: [netmod] update on "rdns" URN for enterprise YANG models Thread-Index: AdGXJqT2atwqDO1sS7m+/GLgZx0D2AABBcaAAAASVyAAEV4yAAC5VLVAAASqeQAAKi2lIAcoQSaAArdgvWA= Date: Thu, 9 Jun 2016 21:06:31 +0000 Message-ID: References: <20160415152317.GB95324@elstar.local> <20160415234236.GC95761@elstar.local> <20160419182250.GA3771@elstar.local>, <1464310422122.33255@Aviatnet.com> In-Reply-To: <1464310422122.33255@Aviatnet.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=ichen@kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: e0c87eff-9274-40d5-9639-08d390a9ef4c x-microsoft-exchange-diagnostics: 1; HE1PR06MB0956; 6:hlgq4vzjcTLeUXrnAy0ywWAiQqI1h2fCbEytK+YfgJ8BZUtwrvtG8dsULrM29C3fpyJXWDRrABRXfc8tVHetTwZhqvBDsnCwNmfATrA+Qv3yHNovFM9bMEoBOv5YcWEtaVcKTLDniSEfI2z9ClqtCPpqLTScMvWm7F0oUpZ44cRNdvJXByAhrkhza/3fitVM0gtLqBDKZakLaAOcN2Ba6TwU8v7nc5z1knEKdmMVALu+GhtjuMLc2K1DdPZJ5rQmgAA7iXN+GUVmV9A77+W27uOgL1A+a7iStcNO4dWJN06/SRDG2rGAyfuJ1dMvvdVr; 5:Nt1C1CAtyROvUWyfu1w0lDirQI/pg2hcs+B7Y1CERwcGC8n5wV8lzNUCf9OGia0YpV6jZu1jhpUTngPg8feGstJ6xp3RQny5PPze7zHej15be8l4uu8rfxmfVtMDLHnAcg5xzYoeATDjhp74mdyUMA==; 24:aXh59dq6J1s5D7+TMJAEnj5q5kGoGwNzdjOZKb3tFpgN12Eu4em8X8yTCCSseIGOHwGJwHnJeIOQll3aQRF8xUwUarXYLrX/+dSmCAFo/Gc=; 7:++g47Px/2UY1O2SwHW62gwP2yzS6RQORC6ShfeS+/YrTnUYGK+B/4zhe/ouF9+oDM78bstWxHvtSeLZ3I/k5spYZTLpE23MqztKqztJPUzGziZM/gimNlHACnncyJlc9dSrDa5dqakhQ7JePTM8xRPKpuWQdcIVRjVYtlBu5oJCOf1+9owz6p49SftSbLMksbH5n6zuL9B9vebBztrKqzsLwBG8m2cgv7S4zD+pz0ws= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR06MB0956; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046); SRVR:HE1PR06MB0956; BCL:0; PCL:0; RULEID:; SRVR:HE1PR06MB0956; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(24454002)(13464003)(199003)(189002)(377454003)(2950100001)(15975445007)(92566002)(2900100001)(93886004)(66066001)(19580395003)(106356001)(105586002)(3660700001)(19580405001)(2906002)(74316001)(3280700002)(586003)(189998001)(81166006)(5003600100002)(5008740100001)(5002640100001)(9686002)(76176999)(54356999)(561944003)(110136002)(50986999)(68736007)(81156014)(33656002)(5004730100002)(10400500002)(97736004)(4326007)(87936001)(101416001)(122556002)(77096005)(6116002)(3900700001)(76576001)(3846002)(8676002)(8936002)(15650500001)(102836003)(86362001)(170073001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR06MB0956; H:HE1PR06MB0955.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: kuatrotech.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: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 21:06:32.0191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR06MB0956 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 21:10:10 -0000 > -----Original Message----- > From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com] > Sent: Thursday, May 26, 2016 8:54 PM > To: Ing-Wher (Helen) Chen > Cc: netmod@ietf.org > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models >=20 >=20 > > From: netmod on behalf of Ing-Wher (Helen) > > Chen > > Sent: Thursday, 21 April 2016 2:40 a.m. > > To: Juergen Schoenwaelder > > Cc: netmod@ietf.org > > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > > university.de] > > > Sent: Tuesday, April 19, 2016 2:23 PM > > > To: Ing-Wher (Helen) Chen > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] update on "rdns" URN for enterprise YANG > > > models > > > > > > On Tue, Apr 19, 2016 at 04:23:51PM +0000, Ing-Wher (Helen) Chen > wrote: > > > > I'm not an expert on XML namespaces and I'm a little confused by > > > > some of the questions, so I apologize if my response below does > > > > not quite answer the questions. I'd like to point out that the > > > > request for "rdns" URN is not to prevent the use of URLs. The reque= st > for "rdns" > > > > URN is to allow an enterprise to easily create a URN namespace, if > > > > the enterprise happens to prefer to use URN as a YANG module > > > > namespace. I also think that the problems that arise when a YANG > > > > module uses a URN based on an enterprise's domain name are the > > > > same problems that arise when a YANG module uses a URL based on an > enterprise's domain name. > > > > (Of course, this is not an excuse to fix the problems that should > > > > be > > > > fixed.) > > > > > > You write "happen to prefer to use URN" - why? >=20 > > draft-chen-rdns-urn Section 4 > > > > discusses why an enterprise might prefer to use URN over URL. URL > > provides resource access mechanism, which might mislead a customer to > > request that the YANG module be accessible at a specific location. > > It's true that the device does not care that the YANG module is not at > > a particular URL, but I can still imagine getting a bug requesting that= the > YANG module be accessible at the URL. >=20 > URLs are frequently used as namespaces in XML, without referring to a > particular resource (and most of them are HTTP URLs that return generic > error-404 pages). > Does this proposal suggest that YANG namespaces should be treated > differently from XML namespaces? No. (Just because a URL is used as an XML Namespace doesn't mean that the URL should be treated differently from how it's defined in . This seems like a reasonable preference to me.) Thanks, Helen From nobody Thu Jun 9 14:17:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B315412D9D5 for ; Thu, 9 Jun 2016 14:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, 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 iP1dywDWFgsd for ; Thu, 9 Jun 2016 14:17:37 -0700 (PDT) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B9B12D0ED for ; Thu, 9 Jun 2016 14:17:37 -0700 (PDT) From: Alex Campbell To: Andy Bierman Thread-Topic: [netmod] YANG library update and new YANG guideline issue Thread-Index: AQHRweWBXzbknxVF8E+47W0cN12d2Z/gUMzN Date: Thu, 9 Jun 2016 21:17:35 +0000 Message-ID: <1465507055467.99339@Aviatnet.com> References: In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: multipart/alternative; boundary="_000_146550705546799339Aviatnetcom_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG library update and new YANG guideline issue X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 21:17:39 -0000 --_000_146550705546799339Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My preference is not to add schema nodes that are not useful. If it is foreseen that other nodes will be added in the container then the = container is fine; otherwise I see no reason to have one. ________________________________ From: netmod on behalf of Andy Bierman Sent: Thursday, 9 June 2016 12:25 p.m. To: netmod@ietf.org Subject: [netmod] YANG library update and new YANG guideline issue Hi, We have been asked to make the YANG library module consistent wrt/ use of a container parent for a list. We decided to remove the submodules container parent from the child submodule. The submodule list and deviation list will now be consistent. Benoit has asked for a YANG guideline in rfc6087bis on this issue. I added the issue with an example to github https://github.com/netmod-wg/rfc6087bis/issues/35 Please comment if you prefer (A) guideline is be consistent throughout module (whichever choice) (B) guideline is for use of a container parent (C) guideline is to not use a container parent (D) something else thanks, Andy, Martin, and Kent --_000_146550705546799339Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

My preference is not to add schema nodes that are not useful.

If it is foreseen that other nodes will be added in the container then t= he container is fine; otherwise I see no reason to have one.


From: netmod <netmod-bo= unces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
Sent: Thursday, 9 June 2016 12:25 p.m.
To: netmod@ietf.org
Subject: [netmod] YANG library update and new YANG guideline issue
 
Hi,


We have been asked to make the YANG library module consistent
wrt/ use of a container parent for a list.  We decided to remove = the
submodules container parent from the child submodule.
The submodule list and deviation list will now be consistent.

Benoit has asked for a YANG guideline in rfc6087bis on this issue.
I added the issue with an example to github

Please comment if you prefer
  (A) guideline is be consistent throughout module (whichever cho= ice)
  (B) guideline is for use of a container parent
  (C) guideline is to not use a container parent
  (D) something else



thanks,
Andy, Martin, and Kent





--_000_146550705546799339Aviatnetcom_-- From nobody Thu Jun 9 14:18:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C890812D0B2 for ; Thu, 9 Jun 2016 14:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 HMdurLKAZqZW for ; Thu, 9 Jun 2016 14:18:02 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7325112D0C5 for ; Thu, 9 Jun 2016 14:18:01 -0700 (PDT) Received: from localhost (h-155-4-131-90.na.cust.bahnhof.se [155.4.131.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 5D6AC1AE0426; Thu, 9 Jun 2016 23:18:00 +0200 (CEST) Date: Thu, 09 Jun 2016 23:17:59 +0200 (CEST) Message-Id: <20160609.231759.2138073227838043200.mbj@tail-f.com> To: worley@ariadne.com From: Martin Bjorklund In-Reply-To: <87y46e2hpf.fsf@hobgoblin.ariadne.com> References: <20160608.224552.2069028097678997544.mbj@tail-f.com> <87y46e2hpf.fsf@hobgoblin.ariadne.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Gen-art] Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 1) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 21:18:04 -0000 worley@ariadne.com (Dale R. Worley) wrote: > Martin Bjorklund writes: > > Do you have an suggestion for what to write? These kinds of > > multi-line strings are almost always 'description' statements, > > used for human consumption. It is not clear to me what the warning > > would be. > > >> So you can't write an isolated CR in most of a Yang module. But am I > >> correct in understanding that you *can* write an isolated CR inside a > >> single-quoted string (and presumably, a double-quoted string)? > > > > Yes. > > I think all of this could be summarized well by putting a paragraph that > tells everything about line ends in Yang at the end of section 6. > Section 6 already deals with the valid characaters for Yang, how they're > encoded, etc. > > Lines in a YANG module may end with a carriage return-line feed > combination or with a line feed alone. A carriage return that is not > followed by a line feed may only appear inside a quoted string. Note > that carriage returns and line feeds that appear inside quoted strings > become part of the value of the string without modification; the value > of a multi-line quoted string contains the same form of line ends as > those lines of the YANG module. > > In a way, that doesn't add much to the specification. Right, it provides additional clarification. Thank you for this text! /martin From nobody Thu Jun 9 15:03:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4405912D550 for ; Thu, 9 Jun 2016 15:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 eEJCNVJQ1IfH for ; Thu, 9 Jun 2016 15:03:54 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 0DED412D513 for ; Thu, 9 Jun 2016 15:03:53 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-06v.sys.comcast.net with SMTP id B83Mb9uVIBNj9B83MbuXHn; Thu, 09 Jun 2016 22:03:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465509832; bh=b+q9nVp+aVAgNeKiz/Psqv1s1LrXYTTYXyyxzuG2dDY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=NJaCi3XHGbwmIvCr7b7xM9HT3pBWB2pqsJgfHUKH5HD6Qok39PTAVerYZvaLnkhrt TdkcTReR22IQNTkv0jTHDB1uTpyRE+jZGrA/i+1YtCArir5r+YloujQWrHOhDdhcej ahXb5yF90SuHDaVUqHSX8ZPC9AE2BNUiqI6V6ZdXtP3CVc3xLhNoY529tPfzrgt7b7 VCLRWkqxRmWgsfAHTPHVY3RDGCy717WpFoJe1lbrVKsUoRVTxUOEfgmCMmLGNwPeJM qdsg4FE7VjWAMt1txgyWsXkizwXgCWo/ZVTml9bYdtP0bUPmgExvSZAeIzxAqHsJ+S hsOrTTNBwU5rg== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-14v.sys.comcast.net with comcast id 4m3r1t00F1nMCLR01m3s8Q; Thu, 09 Jun 2016 22:03:52 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u59M3ovt016793; Thu, 9 Jun 2016 18:03:50 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u59M3oEo016790; Thu, 9 Jun 2016 18:03:50 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Martin Bjorklund In-Reply-To: <20160608.225959.1712188122475580152.mbj@tail-f.com> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 09 Jun 2016 18:03:50 -0400 Message-ID: <87vb1i2f5l.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: [netmod] Tokenizing and strings (was: Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2)) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 22:03:55 -0000 At this point, I think there are some aspects of the use of strings and identifiers that aren't completely specified, but I'd have to check the current text to know for certain. However, that's a minor matter. The issue that concerns me is that the ABNF doesn't specify what is allowed as a string. I'm used to programming language definitions, where the grammar is specified quite rigidly, to the point that the ABNF can be input to a parser generator. In this document, the ABNF is quite complete except for a specification of strings. On the other hand, the text description of strings seems to be sufficient for an implementer, so we don't actually need to provide ABNF. My strong preference is to provide a complete ABNF, as is the norm for programming languages. The following is a complete ABNF for Yang strings. Of course, it's a bit complicated, because the definition of strings in Yang actually is a bit complicated. string = unquoted-string / quoted-string unquoted-string = *unquoted-item ( unquoted-item / "/" / "*" *"*" ) ;; a sequence of one or more characters from ;; ordinary-char / "/" / "*", not containing ;; "//", "/*", or "*/" unquoted-item = ordinary-char / "/" ordinary-char / "*" *"*" ordinary-char ordinary-char = < any character matching yang-char, except > < space, tab, newline, carriage return, > < semicolon, left brace, right brace, > < slash, and asterisk > *** Hmmm, is an unaccompanied CR allowed in an unquoted string? If so, "ordinary-char" and my previous text regarding line breaks need to be amended. quoted-string = ( single-quoted-string / double-quoted-string ) *( optsep "+" optsep ( single-quoted-string / double-quoted-string ) ) (I think you said that there can be whitespace around + but not comments.) single-quoted-string = SQUOTE *sq-char SQUOTE sq-char = < any character matching yang-char, except > < SQUOTE > double-quoted-string = DQUOTE *dq-item DQUOTE dq-item = dq-char / "\n" / "\t" / "\" DQUOTE / "\\" dq-char = < any character matching yang-char, except > < DQUOTE and backslash > (The existing production for yang-string is removed.) ;; any Unicode or ISO/IEC 10646 character including tab, carriage ;; return, and line feed, but excluding the other C0 control ;; characters, the surrogate blocks, and the noncharacters. yang-char = %x09 / %x0A / %x0D / %x20-D7FF / [continuing as before] Dale From nobody Thu Jun 9 17:57:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B485412D78B for ; Thu, 9 Jun 2016 17:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Hl4Pr-bRpS0Q for ; Thu, 9 Jun 2016 17:57:41 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 9533812D842 for ; Thu, 9 Jun 2016 17:57:41 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id ec8so18175122pac.0 for ; Thu, 09 Jun 2016 17:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tyQ+cJozDz04qwB47BPAi93MRiaZ/pzzmDNVcWipWTs=; b=PknRQ0+wcGpvMaLNcFVV43rT+XINAh6AkxCnDL2EkCPh1XRl4Ov1WZp4UxpQG5vVpQ ACkfJXCREqLI5R1ScuCsOm5k6eT/FwP0vToKcQxDHVMHA4JnG3GuiBAtVWGYc3celmvU bj7w0trC+3IZdT53kE08bFNBLN4LfwpfGWZ6ajQoNZ1tFAhwVUk8n7s7iSikaoDMaDpr hv+ps3YfMDFeHhU5h8sdbEo1NlmZgijyiYHbil3TCUuK2KtjQe42TRvP+qvwErAEdYkE RhTPeVljPW2InBnCB2PsxQOYkq2vWye1np1NcWtobcPTzFnYRJbzn7hGBja9H8mRGfcP HxNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tyQ+cJozDz04qwB47BPAi93MRiaZ/pzzmDNVcWipWTs=; b=hys6yxzIurFmqcqzTZ97YauG0DgdrIifyUyEwCv1R0HL/iZPKIJdOL1vcL13sDISZL iEcv0UAKNo/pNNkGHdNVJmiwSNM+605GHI1viO/fZuBK8jOTsi0b17/KPeELl+/bQasQ p4IxnxUlUAHKPd20I/TCFU9XPHRkLcCysCjrLSVYFtfvz+b8Peldbjtjb94/tF6La/V9 b/2Xwervrf24hWLfuR+0kj072N7gIXDTXDF2S1q2XPMW/2qRRwTUI2GNZqyKUnABBNDY yeBrZeKfIePkc2PPGLwFOanmNVK8XqOZ/xEGTmGu7SkEzeiX2W8jZJvRFVcGL6F54Ep4 IznQ== X-Gm-Message-State: ALyK8tI1wP1GWSe4rCeCgB2buJAel5LrdCfuyg8MmZ+UndRPIIMZpJnQ1/EAWJOGy0FJSw== X-Received: by 10.66.122.73 with SMTP id lq9mr15702549pab.124.1465520261055; Thu, 09 Jun 2016 17:57:41 -0700 (PDT) Received: from dhcp-171-71-145-139.cisco.com (dhcp-171-71-145-139.cisco.com. [171.71.145.139]) by smtp.gmail.com with ESMTPSA id q127sm12826210pfb.34.2016.06.09.17.57.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 17:57:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 9 Jun 2016 17:57:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E108464-1E5E-4090-A1BC-2E4B8628DCB0@gmail.com> References: <38F48C5F-F8FA-49F0-87F2-C3D27ADBF3C5@gmail.com> <4F17C04E-028C-4A71-AA20-0D858FC9771C@gmail.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 00:57:44 -0000 > On Jun 9, 2016, at 7:58 AM, Acee Lindem (acee) wrote: >>=20 >> Is this a relevant example of ACL being configured on an interface? >>=20 >> = http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-2/a= >> = ddr_serv/configuration/guide/b_ipaddr_cg42a9k/b_ipaddr_cg42a9k_chapter_01.= >> html#task_1049371 >>=20 >>=20 >=20 > In the same way I misread your salutation, I think you=E2=80=99ve = misinterpreted > this example as it applies to including interface in the ACL model. If = you > examine the referenced configuration html closely, you=E2=80=99ll see = that the ACL > is a reusable packet-matching policy that is applied to an interface > rather than the interface being included in the ACL rules themselves. = In > IOS-XR, the command to apply the ACL to an interface is =E2=80=9C{ipv4 = | ipv6} > access-group =E2=80=9D specified in interface configuration = submode. Is > there something in the text that I=E2=80=99m missing? You are correct. I was thinking of interface as one of the parameters in = the ACL rule, where this example is of configuring an ACL under an = interface.=20 >=20 >>=20 >> Talking to implementers, the feature is very much desired. >>=20 >>=20 >=20 > As the initial implementor of the function on Redback SEOS (now = Ericsson > IPOS), I can confirm that attaching an ACL to an interface is, indeed, = an > essential function. And this is more of a question to the authors - unless I am missing = something, where and how is this achieved today? >=20 >>=20 >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >> On Apr 2, 2016, at 4:39 AM, Dean Bogdanovic = wrote: >>=20 >>=20 >>=20 >> Hi Acee, >>=20 >>=20 >> On Mar 31, 2016, at 8:17 AM, Acee Lindem (acee) = wrote: >>=20 >> Hi Dean,=20 >>=20 >> From: netmod on behalf of Dean Bogdanovic >> >> Date: Thursday, March 31, 2016 at 5:26 AM >> To: "Sterne, Jason (Nokia - CA)" >> Cc: netmod WG >> Subject: Re: [netmod] Remove input-interface (metadata) from >> netmod-acl-model-07 ? >>=20 >>=20 >>>=20 >>>=20 >>> On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) >>> wrote: >>>=20 >>> Hi all, >>>=20 >>> The ACL model is converging on a small core set of functionality = that is >>> fairly common. >>>=20 >>> But I think the matching on input-interface should be removed from = the >>> model (or at the least put inside a feature flag). >>>=20 >>> Matching on basic IPv4/IPv4/MAC header fields is common = functionality. >>> But having that input-interface match on metadata in the core model = is >>> out of place. It should be left to further extension drafts or = vendor >>> specific augmentations (along >>> with whatever other metadata might be useful or vendor-specific). >>>=20 >>>=20 >>>=20 >>> ACLs are typically assigned to interfaces as shown in section A.3. = of >>> the ACL draft. That is the most common use case. >>>=20 >>> Actually matching on input-interface in the ACL rules themselves is = not >>> basic core ACL functionality. Nokia SR OS does not have that >>> capability. Does IOS-XR ? Brocade ? others ? >>>=20 >>>=20 >>>=20 >>>=20 >>> Cisco and Juniper support matching on input interface. It is useful = when >>> you want to filter on general traffic coming from interface. >>>=20 >>> Cisco >>> match input-interface >>> match input-vlan >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> These are =E2=80=9Cclass-map=E2=80=9D sub-commands - not = =E2=80=9Caccess-list" sub-commands. So >> you are referring to the general functionality rather than = specifically >> functionality supported by access-list? >>=20 >>=20 >>=20 >>=20 >>=20 >> According to the Cisco website >> = (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/sof= >> tware/release/12-2_55_se/configuration/guide/3750xscg/swacl.html) >>=20 >> Note The ACL must be an extended named ACL. >> ________________________________________ >>=20 >>=20 >> =E2=80=93 match input-interface interface-id-list >> =E2=80=93 match ip dscp dscp-list >> =E2=80=93 match ip precedence ip-precedence-list >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> Junos >>> family any { >>> filter L2_filter { >>> term t1 { >>> from { >>> interface fe-0/0/0.0; >>> } >>> then { >>> policer p1; >>> count c1; >>> } >>> } >>> } >>> } >>>=20 >>> Brocade supports matching based on interface, Dell supports VLAN >>> matching, Arista supports input interface matching, Redback supports >>> matching against input interface for logging, >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> If you are referring to =E2=80=9Clog-input=E2=80=9D, this indicates = to include the >> input-interface in the log message. Cisco supports this as well. >>=20 >> Thanks, >> Acee=20 >>=20 >>=20 >>> so it is pretty standard across multiple vendors >>>=20 >>> Dean >>>=20 >>>=20 >>>=20 >>> If some major implementations don=E2=80=99t do it, and it isn=E2=80= =99t necessary >>> for typical basic ACL use, then it should be removed (or feature >>> flagged). >>>=20 >>> Regards, >>> Jason=20 >>>=20 >>> _______________________________________________ >>> netmod >>> mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Thu Jun 9 18:59:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65224128874 for ; Thu, 9 Jun 2016 18:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 9wrN4stxddra for ; Thu, 9 Jun 2016 18:59:04 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 1C7D812D665 for ; Thu, 9 Jun 2016 18:59:04 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 4191F2F210D88; Fri, 10 Jun 2016 01:59:02 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u5A1x29G007016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Jun 2016 01:59:02 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u5A1x2b6028139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Jun 2016 01:59:02 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 9 Jun 2016 21:59:02 -0400 From: "Sterne, Jason (Nokia - CA)" To: Mahesh Jethanandani , "Acee Lindem (acee)" Thread-Topic: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? Thread-Index: AQHRwrMlwzarHZ0L9Eadq7FrV8iYEp/h8XbQ Date: Fri, 10 Jun 2016 01:59:01 +0000 Message-ID: References: <38F48C5F-F8FA-49F0-87F2-C3D27ADBF3C5@gmail.com> <4F17C04E-028C-4A71-AA20-0D858FC9771C@gmail.com> <5E108464-1E5E-4090-A1BC-2E4B8628DCB0@gmail.com> In-Reply-To: <5E108464-1E5E-4090-A1BC-2E4B8628DCB0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 01:59:06 -0000 SXQgaXMgc2hvd24gaW4gdGhlIGRyYWZ0IGFzIGFuIGV4YW1wbGUgb2YgaG93IHRvIGF1Z21lbnQg dGhlIGludGVyZmFjZSBtb2R1bGUuDQoNCkp1c3QgdG8gYmUgY2xlYXIgLT4gdGhlIGxpbmsgeW91 IHNlbnQgdG8gdGhlIENpc2NvIGRvYyBkb2VzIG5vdCBzaG93IHRoZSB1c2Ugb2YgJ21ldGFkYXRh JyBvciBhbiBpbnB1dC1pbnRlcmZhY2UgbWF0Y2ggY3JpdGVyaWEuIA0KDQpKYXNvbg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWhlc2ggSmV0aGFuYW5kYW5pDQpTZW50OiBUaHVy c2RheSwgSnVuZSAwOSwgMjAxNiAyMDo1OA0KVG86IEFjZWUgTGluZGVtIChhY2VlKQ0KQ2M6IG5l dG1vZCBXRw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFJlbW92ZSBpbnB1dC1pbnRlcmZhY2UgKG1l dGFkYXRhKSBmcm9tIG5ldG1vZC1hY2wtbW9kZWwtMDcgPw0KDQoNCj4gT24gSnVuIDksIDIwMTYs IGF0IDc6NTggQU0sIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0K Pj4gDQo+PiBJcyB0aGlzIGEgcmVsZXZhbnQgZXhhbXBsZSBvZiBBQ0wgYmVpbmcgY29uZmlndXJl ZCBvbiBhbiBpbnRlcmZhY2U/DQo+PiANCj4+IGh0dHA6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMv dGQvZG9jcy9yb3V0ZXJzL2FzcjkwMDAvc29mdHdhcmUvYXNyOWtfcg0KPj4gNC0yL2EgDQo+PiBk ZHJfc2Vydi9jb25maWd1cmF0aW9uL2d1aWRlL2JfaXBhZGRyX2NnNDJhOWsvYl9pcGFkZHJfY2c0 MmE5a19jaGFwdGVyXzAxLg0KPj4gaHRtbCN0YXNrXzEwNDkzNzENCj4+IA0KPj4gDQo+IA0KPiBJ biB0aGUgc2FtZSB3YXkgSSBtaXNyZWFkIHlvdXIgc2FsdXRhdGlvbiwgSSB0aGluayB5b3XigJl2 ZSANCj4gbWlzaW50ZXJwcmV0ZWQgdGhpcyBleGFtcGxlIGFzIGl0IGFwcGxpZXMgdG8gaW5jbHVk aW5nIGludGVyZmFjZSBpbiANCj4gdGhlIEFDTCBtb2RlbC4gSWYgeW91IGV4YW1pbmUgdGhlIHJl ZmVyZW5jZWQgY29uZmlndXJhdGlvbiBodG1sIA0KPiBjbG9zZWx5LCB5b3XigJlsbCBzZWUgdGhh dCB0aGUgQUNMIGlzIGEgcmV1c2FibGUgcGFja2V0LW1hdGNoaW5nIHBvbGljeSANCj4gdGhhdCBp cyBhcHBsaWVkIHRvIGFuIGludGVyZmFjZSByYXRoZXIgdGhhbiB0aGUgaW50ZXJmYWNlIGJlaW5n IA0KPiBpbmNsdWRlZCBpbiB0aGUgQUNMIHJ1bGVzIHRoZW1zZWx2ZXMuIEluIElPUy1YUiwgdGhl IGNvbW1hbmQgdG8gYXBwbHkgDQo+IHRoZSBBQ0wgdG8gYW4gaW50ZXJmYWNlIGlzIOKAnHtpcHY0 IHwgaXB2Nn0gYWNjZXNzLWdyb3VwIDxhY2wtbmFtZT7igJ0gDQo+IHNwZWNpZmllZCBpbiBpbnRl cmZhY2UgY29uZmlndXJhdGlvbiBzdWJtb2RlLiBJcyB0aGVyZSBzb21ldGhpbmcgaW4gdGhlIHRl eHQgdGhhdCBJ4oCZbSBtaXNzaW5nPw0KDQpZb3UgYXJlIGNvcnJlY3QuIEkgd2FzIHRoaW5raW5n IG9mIGludGVyZmFjZSBhcyBvbmUgb2YgdGhlIHBhcmFtZXRlcnMgaW4gdGhlIEFDTCBydWxlLCB3 aGVyZSB0aGlzIGV4YW1wbGUgaXMgb2YgY29uZmlndXJpbmcgYW4gQUNMIHVuZGVyIGFuIGludGVy ZmFjZS4gDQoNCj4gDQo+PiANCj4+IFRhbGtpbmcgdG8gaW1wbGVtZW50ZXJzLCB0aGUgZmVhdHVy ZSBpcyB2ZXJ5IG11Y2ggZGVzaXJlZC4NCj4+IA0KPj4gDQo+IA0KPiBBcyB0aGUgaW5pdGlhbCBp bXBsZW1lbnRvciBvZiB0aGUgZnVuY3Rpb24gb24gUmVkYmFjayBTRU9TIChub3cgDQo+IEVyaWNz c29uIElQT1MpLCBJIGNhbiBjb25maXJtIHRoYXQgYXR0YWNoaW5nIGFuIEFDTCB0byBhbiBpbnRl cmZhY2UgDQo+IGlzLCBpbmRlZWQsIGFuIGVzc2VudGlhbCBmdW5jdGlvbi4NCg0KQW5kIHRoaXMg aXMgbW9yZSBvZiBhIHF1ZXN0aW9uIHRvIHRoZSBhdXRob3JzIC0gdW5sZXNzIEkgYW0gbWlzc2lu ZyBzb21ldGhpbmcsIHdoZXJlIGFuZCBob3cgaXMgdGhpcyBhY2hpZXZlZCB0b2RheT8NCg0KPiAN Cj4+IA0KPj4gDQo+PiBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+PiBtamV0aGFuYW5kYW5pQGdtYWls LmNvbQ0KPj4gDQo+PiANCj4+IE9uIEFwciAyLCAyMDE2LCBhdCA0OjM5IEFNLCBEZWFuIEJvZ2Rh bm92aWMgPGl2YW5kZWFuQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+IA0KPj4gDQo+PiBIaSBB Y2VlLA0KPj4gDQo+PiANCj4+IE9uIE1hciAzMSwgMjAxNiwgYXQgODoxNyBBTSwgQWNlZSBMaW5k ZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiANCj4+IEhpIERlYW4sDQo+PiAN Cj4+IEZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBE ZWFuIEJvZ2Rhbm92aWMgDQo+PiA8aXZhbmRlYW5AZ21haWwuY29tPg0KPj4gRGF0ZTogVGh1cnNk YXksIE1hcmNoIDMxLCAyMDE2IGF0IDU6MjYgQU0NCj4+IFRvOiAiU3Rlcm5lLCBKYXNvbiAoTm9r aWEgLSBDQSkiIDxqYXNvbi5zdGVybmVAbm9raWEuY29tPg0KPj4gQ2M6IG5ldG1vZCBXRyA8bmV0 bW9kQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFJlbW92ZSBpbnB1dC1pbnRl cmZhY2UgKG1ldGFkYXRhKSBmcm9tDQo+PiBuZXRtb2QtYWNsLW1vZGVsLTA3ID8NCj4+IA0KPj4g DQo+Pj4gDQo+Pj4gDQo+Pj4gT24gTWFyIDMwLCAyMDE2LCBhdCA5OjM2IFBNLCBTdGVybmUsIEph c29uIChOb2tpYSAtIENBKSANCj4+PiA8amFzb24uc3Rlcm5lQG5va2lhLmNvbT4gd3JvdGU6DQo+ Pj4gDQo+Pj4gSGkgYWxsLA0KPj4+IA0KPj4+IFRoZSBBQ0wgbW9kZWwgaXMgY29udmVyZ2luZyBv biBhIHNtYWxsIGNvcmUgc2V0IG9mIGZ1bmN0aW9uYWxpdHkgDQo+Pj4gdGhhdCBpcyBmYWlybHkg Y29tbW9uLg0KPj4+IA0KPj4+IEJ1dCBJIHRoaW5rIHRoZSBtYXRjaGluZyBvbiBpbnB1dC1pbnRl cmZhY2Ugc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSANCj4+PiB0aGUgbW9kZWwgKG9yIGF0IHRoZSBs ZWFzdCBwdXQgaW5zaWRlIGEgZmVhdHVyZSBmbGFnKS4NCj4+PiANCj4+PiBNYXRjaGluZyBvbiBi YXNpYyBJUHY0L0lQdjQvTUFDIGhlYWRlciBmaWVsZHMgaXMgY29tbW9uIGZ1bmN0aW9uYWxpdHku DQo+Pj4gQnV0IGhhdmluZyB0aGF0IGlucHV0LWludGVyZmFjZSBtYXRjaCBvbiBtZXRhZGF0YSBp biB0aGUgY29yZSBtb2RlbCANCj4+PiBpcyBvdXQgb2YgcGxhY2UuICBJdCBzaG91bGQgYmUgbGVm dCB0byBmdXJ0aGVyIGV4dGVuc2lvbiBkcmFmdHMgb3IgDQo+Pj4gdmVuZG9yIHNwZWNpZmljIGF1 Z21lbnRhdGlvbnMgKGFsb25nIHdpdGggd2hhdGV2ZXIgb3RoZXIgbWV0YWRhdGEgDQo+Pj4gbWln aHQgYmUgdXNlZnVsIG9yIHZlbmRvci1zcGVjaWZpYykuDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4g QUNMcyBhcmUgdHlwaWNhbGx5IGFzc2lnbmVkIHRvIGludGVyZmFjZXMgYXMgc2hvd24gaW4gc2Vj dGlvbiBBLjMuIG9mDQo+Pj4gdGhlIEFDTCBkcmFmdC4gICBUaGF0IGlzIHRoZSBtb3N0IGNvbW1v biB1c2UgY2FzZS4NCj4+PiANCj4+PiBBY3R1YWxseSBtYXRjaGluZyBvbiBpbnB1dC1pbnRlcmZh Y2UgaW4gdGhlIEFDTCBydWxlcyB0aGVtc2VsdmVzIGlzIA0KPj4+IG5vdCBiYXNpYyBjb3JlIEFD TCBmdW5jdGlvbmFsaXR5LiAgTm9raWEgU1IgT1MgZG9lcyBub3QgaGF2ZSB0aGF0IA0KPj4+IGNh cGFiaWxpdHkuICBEb2VzIElPUy1YUiA/ICBCcm9jYWRlID8gIG90aGVycyA/DQo+Pj4gDQo+Pj4g DQo+Pj4gDQo+Pj4gDQo+Pj4gQ2lzY28gYW5kIEp1bmlwZXIgc3VwcG9ydCBtYXRjaGluZyBvbiBp bnB1dCBpbnRlcmZhY2UuIEl0IGlzIHVzZWZ1bCANCj4+PiB3aGVuIHlvdSB3YW50IHRvIGZpbHRl ciBvbiBnZW5lcmFsIHRyYWZmaWMgY29taW5nIGZyb20gaW50ZXJmYWNlLg0KPj4+IA0KPj4+IENp c2NvDQo+Pj4gbWF0Y2ggaW5wdXQtaW50ZXJmYWNlDQo+Pj4gbWF0Y2ggaW5wdXQtdmxhbg0KPj4+ IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4gDQo+PiBUaGVzZSBhcmUg4oCcY2xhc3MtbWFw4oCdICBz dWItY29tbWFuZHMgLSBub3Qg4oCcYWNjZXNzLWxpc3QiIHN1Yi1jb21tYW5kcy4gDQo+PiBTbyB5 b3UgYXJlIHJlZmVycmluZyB0byB0aGUgZ2VuZXJhbCBmdW5jdGlvbmFsaXR5IHJhdGhlciB0aGFu IA0KPj4gc3BlY2lmaWNhbGx5IGZ1bmN0aW9uYWxpdHkgc3VwcG9ydGVkIGJ5IGFjY2Vzcy1saXN0 Pw0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IEFjY29yZGluZyB0byB0aGUgQ2lzY28gd2Vi c2l0ZQ0KPj4gKGh0dHA6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9zd2l0Y2hlcy9s YW4vY2F0YWx5c3QzNzUweF8zNTYwDQo+PiB4L3NvZg0KPj4gdHdhcmUvcmVsZWFzZS8xMi0yXzU1 X3NlL2NvbmZpZ3VyYXRpb24vZ3VpZGUvMzc1MHhzY2cvc3dhY2wuaHRtbCkNCj4+IA0KPj4gTm90 ZSBUaGUgQUNMIG11c3QgYmUgYW4gZXh0ZW5kZWQgbmFtZWQgQUNMLg0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gDQo+PiANCj4+IOKAkzxibGFuay5naWY+ IG1hdGNoIGlucHV0LWludGVyZmFjZSBpbnRlcmZhY2UtaWQtbGlzdCDigJM8YmxhbmsuZ2lmPiAN Cj4+IG1hdGNoIGlwIGRzY3AgZHNjcC1saXN0IOKAkzxibGFuay5naWY+IG1hdGNoIGlwIHByZWNl ZGVuY2UgDQo+PiBpcC1wcmVjZWRlbmNlLWxpc3QNCj4+IA0KPj4gDQo+PiANCj4+PiANCj4+PiAN Cj4+PiBKdW5vcw0KPj4+IGZhbWlseSBhbnkgew0KPj4+IGZpbHRlciBMMl9maWx0ZXIgew0KPj4+ IHRlcm0gdDEgew0KPj4+IGZyb20gew0KPj4+IGludGVyZmFjZSBmZS0wLzAvMC4wOw0KPj4+IH0N Cj4+PiB0aGVuIHsNCj4+PiBwb2xpY2VyIHAxOw0KPj4+IGNvdW50IGMxOw0KPj4+IH0NCj4+PiB9 DQo+Pj4gfQ0KPj4+IH0NCj4+PiANCj4+PiBCcm9jYWRlIHN1cHBvcnRzIG1hdGNoaW5nIGJhc2Vk IG9uIGludGVyZmFjZSwgRGVsbCBzdXBwb3J0cyBWTEFOIA0KPj4+IG1hdGNoaW5nLCBBcmlzdGEg c3VwcG9ydHMgaW5wdXQgaW50ZXJmYWNlIG1hdGNoaW5nLCBSZWRiYWNrIHN1cHBvcnRzIA0KPj4+ IG1hdGNoaW5nIGFnYWluc3QgaW5wdXQgaW50ZXJmYWNlIGZvciBsb2dnaW5nLA0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4gDQo+PiBJZiB5b3UgYXJlIHJlZmVycmluZyB0byDigJxs b2ctaW5wdXTigJ0sIHRoaXMgaW5kaWNhdGVzIHRvIGluY2x1ZGUgdGhlIA0KPj4gaW5wdXQtaW50 ZXJmYWNlIGluIHRoZSBsb2cgbWVzc2FnZS4gQ2lzY28gc3VwcG9ydHMgdGhpcyBhcyB3ZWxsLg0K Pj4gDQo+PiBUaGFua3MsDQo+PiBBY2VlDQo+PiANCj4+IA0KPj4+IHNvIGl0IGlzIHByZXR0eSBz dGFuZGFyZCBhY3Jvc3MgbXVsdGlwbGUgdmVuZG9ycw0KPj4+IA0KPj4+IERlYW4NCj4+PiANCj4+ PiANCj4+PiANCj4+PiAgICBJZiBzb21lIG1ham9yIGltcGxlbWVudGF0aW9ucyBkb27igJl0IGRv IGl0LCBhbmQgaXQgaXNu4oCZdCBuZWNlc3NhcnkgDQo+Pj4gZm9yIHR5cGljYWwgYmFzaWMgQUNM IHVzZSwgdGhlbiBpdCBzaG91bGQgYmUgcmVtb3ZlZCAob3IgZmVhdHVyZSANCj4+PiBmbGFnZ2Vk KS4NCj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IEphc29uDQo+Pj4gDQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBuZXRtb2QNCj4+PiBtYWls aW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g bmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCg0KTWFoZXNoIEpldGhhbmFuZGFu aQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo= From nobody Fri Jun 10 00:35:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA3C12DAAD for ; Fri, 10 Jun 2016 00:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 HRm7nNxd-cG5 for ; Fri, 10 Jun 2016 00:35:37 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499C912D11B for ; Fri, 10 Jun 2016 00:35:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4F97111EB; Fri, 10 Jun 2016 09:35:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id V_zRmdQQDIRf; Fri, 10 Jun 2016 09:35:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Jun 2016 09:35:33 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A1B82004E; Fri, 10 Jun 2016 09:35:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o_4-xXeQDnBV; Fri, 10 Jun 2016 09:35:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42B2820047; Fri, 10 Jun 2016 09:35:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 57BC03B10259; Fri, 10 Jun 2016 09:35:30 +0200 (CEST) Date: Fri, 10 Jun 2016 09:35:29 +0200 From: Juergen Schoenwaelder To: "Dale R. Worley" Message-ID: <20160610073529.GA15538@elstar.local> Mail-Followup-To: "Dale R. Worley" , Martin Bjorklund , netmod@ietf.org References: <20160608.225959.1712188122475580152.mbj@tail-f.com> <87vb1i2f5l.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vb1i2f5l.fsf@hobgoblin.ariadne.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Tokenizing and strings (was: Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2)) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 07:35:40 -0000 I think we should consider this for a future version of YANG but not now. I am not aware what implementors had problems to implement YANG strings in YANG 1 or YANG 1.1 and we are at a point in the process where I like to not run the risk to make bigger changes to the specification that may turn out to introduce incompabilities. /js On Thu, Jun 09, 2016 at 06:03:50PM -0400, Dale R. Worley wrote: > At this point, I think there are some aspects of the use of strings and > identifiers that aren't completely specified, but I'd have to check the > current text to know for certain. However, that's a minor matter. > > The issue that concerns me is that the ABNF doesn't specify what is > allowed as a string. I'm used to programming language definitions, > where the grammar is specified quite rigidly, to the point that the ABNF > can be input to a parser generator. In this document, the ABNF is quite > complete except for a specification of strings. On the other hand, the > text description of strings seems to be sufficient for an implementer, > so we don't actually need to provide ABNF. My strong preference is to > provide a complete ABNF, as is the norm for programming languages. > > The following is a complete ABNF for Yang strings. Of course, it's a > bit complicated, because the definition of strings in Yang actually is a > bit complicated. > > string = unquoted-string / quoted-string > > unquoted-string = *unquoted-item ( unquoted-item / > "/" / > "*" *"*" ) > ;; a sequence of one or more characters from > ;; ordinary-char / "/" / "*", not containing > ;; "//", "/*", or "*/" > > unquoted-item = ordinary-char / > "/" ordinary-char / > "*" *"*" ordinary-char > > ordinary-char = < any character matching yang-char, except > > < space, tab, newline, carriage return, > > < semicolon, left brace, right brace, > > < slash, and asterisk > > > *** Hmmm, is an unaccompanied CR allowed in an unquoted string? If > so, "ordinary-char" and my previous text regarding line breaks need > to be amended. > > quoted-string = ( single-quoted-string / double-quoted-string ) > *( optsep "+" optsep > ( single-quoted-string / double-quoted-string ) ) > > (I think you said that there can be whitespace around + but not comments.) > > single-quoted-string = SQUOTE *sq-char SQUOTE > > sq-char = < any character matching yang-char, except > > < SQUOTE > > > double-quoted-string = DQUOTE *dq-item DQUOTE > > dq-item = dq-char / > "\n" / > "\t" / > "\" DQUOTE / > "\\" > > dq-char = < any character matching yang-char, except > > < DQUOTE and backslash > > > (The existing production for yang-string is removed.) > > ;; any Unicode or ISO/IEC 10646 character including tab, carriage > ;; return, and line feed, but excluding the other C0 control > ;; characters, the surrogate blocks, and the noncharacters. > yang-char = %x09 / %x0A / %x0D / %x20-D7FF / > [continuing as before] > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jun 10 01:00:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C01812B04E for ; Fri, 10 Jun 2016 01:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 3Jv7Q20IiLMp for ; Fri, 10 Jun 2016 01:00:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 17BEC12B01E for ; Fri, 10 Jun 2016 01:00:57 -0700 (PDT) Received: from localhost (unknown [192.118.78.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 2D8F61AE0312; Fri, 10 Jun 2016 10:00:55 +0200 (CEST) Date: Fri, 10 Jun 2016 10:00:53 +0200 (CEST) Message-Id: <20160610.100053.1121944500378803384.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160610073529.GA15538@elstar.local> References: <20160608.225959.1712188122475580152.mbj@tail-f.com> <87vb1i2f5l.fsf@hobgoblin.ariadne.com> <20160610073529.GA15538@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Tokenizing and strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 08:00:58 -0000 Juergen Schoenwaelder wrote: > I think we should consider this for a future version of YANG but not > now. I am not aware what implementors had problems to implement YANG > strings in YANG 1 or YANG 1.1 and we are at a point in the process > where I like to not run the risk to make bigger changes to the > specification that may turn out to introduce incompabilities. I agree. However, there is one thing below that I'd like to clarify: > > *** Hmmm, is an unaccompanied CR allowed in an unquoted string? If > > so, "ordinary-char" and my previous text regarding line breaks need > > to be amended. To clarify this, I suggest: OLD: An unquoted string is any sequence of characters that does not contain any space, tab or newline characters, a single or double quote character, a semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"). NEW: An unquoted string is any sequence of characters that does not contain any space, tab, carrige return, or line feed characters, a single or double quote character, a semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"). /martin From nobody Fri Jun 10 01:13:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9912D51C for ; Fri, 10 Jun 2016 01:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 oIAUbeCMYq1h for ; Fri, 10 Jun 2016 01:13:37 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3DE12D09B for ; Fri, 10 Jun 2016 01:13:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AD623A8C; Fri, 10 Jun 2016 10:13:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7L9HB1gKLIAE; Fri, 10 Jun 2016 10:13:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Jun 2016 10:13:34 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C94EF2004E; Fri, 10 Jun 2016 10:13:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id n05zN1A8V7zd; Fri, 10 Jun 2016 10:13:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4937B20047; Fri, 10 Jun 2016 10:13:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 351593B1B040; Fri, 10 Jun 2016 10:13:33 +0200 (CEST) Date: Fri, 10 Jun 2016 10:13:33 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160610081333.GB15751@elstar.local> Mail-Followup-To: Martin Bjorklund , worley@ariadne.com, netmod@ietf.org References: <20160608.225959.1712188122475580152.mbj@tail-f.com> <87vb1i2f5l.fsf@hobgoblin.ariadne.com> <20160610073529.GA15538@elstar.local> <20160610.100053.1121944500378803384.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160610.100053.1121944500378803384.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Tokenizing and strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 08:13:38 -0000 On Fri, Jun 10, 2016 at 10:00:53AM +0200, Martin Bjorklund wrote: > However, there is one thing below that I'd like to clarify: > > > > *** Hmmm, is an unaccompanied CR allowed in an unquoted string? If > > > so, "ordinary-char" and my previous text regarding line breaks need > > > to be amended. > > To clarify this, I suggest: > > OLD: > > An unquoted string is any sequence of characters that does not > contain any space, tab or newline characters, a single or double > quote character, a semicolon (";"), braces ("{" or "}"), or comment > sequences ("//", "/*", or "*/"). > > NEW: > > An unquoted string is any sequence of characters that does not > contain any space, tab, carrige return, or line feed characters, a > single or double quote character, a semicolon (";"), braces ("{" or > "}"), or comment sequences ("//", "/*", or "*/"). > This looks good to me. /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 Jun 10 01:38:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E0812B035 for ; Fri, 10 Jun 2016 01:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 isxJ0r1YkDlC for ; Fri, 10 Jun 2016 01:38:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4984112D0B3 for ; Fri, 10 Jun 2016 01:38:27 -0700 (PDT) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id E663A61CF8; Fri, 10 Jun 2016 10:38:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465547905; bh=JiDbcfWAM5JhjDnLq6VOXdOpUba8yWZOzSH2Nrgkj8A=; h=From:Date:To; b=s0ihYC5mbEAkaH7ph/MrJOUjCu2LnY0fhB76r3ZP8tp1rlEhfsRr5YV+yH0ssbLkG TM+iWsyS41ZY7MYQJ8NWWUrGksFMWt77OQCkJHcE938fC46nB4Pr7l4Zkmhi+Ea4O9 QWmmoTSNkBji2aenHGhyEPhKMF595UmZ65QT+caA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160610.100053.1121944500378803384.mbj@tail-f.com> Date: Fri, 10 Jun 2016 10:38:28 +0200 Content-Transfer-Encoding: 7bit Message-Id: <178DB7F2-3E62-4042-A189-02A4C93FB42C@nic.cz> References: <20160608.225959.1712188122475580152.mbj@tail-f.com> <87vb1i2f5l.fsf@hobgoblin.ariadne.com> <20160610073529.GA15538@elstar.local> <20160610.100053.1121944500378803384.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Tokenizing and strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 08:38:29 -0000 > On 10 Jun 2016, at 10:00, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: >> I think we should consider this for a future version of YANG but not >> now. I am not aware what implementors had problems to implement YANG >> strings in YANG 1 or YANG 1.1 and we are at a point in the process >> where I like to not run the risk to make bigger changes to the >> specification that may turn out to introduce incompabilities. > > I agree. > > However, there is one thing below that I'd like to clarify: > >>> *** Hmmm, is an unaccompanied CR allowed in an unquoted string? If >>> so, "ordinary-char" and my previous text regarding line breaks need >>> to be amended. > > To clarify this, I suggest: > > OLD: > > An unquoted string is any sequence of characters that does not > contain any space, tab or newline characters, a single or double > quote character, a semicolon (";"), braces ("{" or "}"), or comment > sequences ("//", "/*", or "*/"). > > NEW: > > An unquoted string is any sequence of characters that does not > contain any space, tab, carrige return, or line feed characters, a > single or double quote character, a semicolon (";"), braces ("{" or > "}"), or comment sequences ("//", "/*", or "*/"). s/carrige/carriage/ Lada > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jun 10 01:46:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B591612D51B for ; Fri, 10 Jun 2016 01:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s64k5LpVmpzJ for ; Fri, 10 Jun 2016 01:46:03 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1337612D1B9 for ; Fri, 10 Jun 2016 01:46:01 -0700 (PDT) Received: from jernejthpPC (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 304BDC4175C2; Fri, 10 Jun 2016 10:46:00 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si 304BDC4175C2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1465548360; bh=Dan9VOBJShew6ASg4OBx2z31gW65HH5QTQSghww8VTU=; h=From:To:Cc:Subject:Date:From; b=hp706qvdqgkmiz+OF/y8SzWRjLUFapDQbxyr/AEa9tIz6xzoGN/Yo6W+tso4ruPJU f9heJ9NFLFH72GiWfnL3Tw9+g4OUiyAUZNAqFXDeE/UciD/P1oavKsIZc3gElPaCmP 4SY9QOlYpM2IVLc1zU03dkCemLtLUDm1iRHBSovEgxz9W1SldrqNDj0wvGdNUJYuvA a8jiapnueJEG1fb/XfeP+T83eNimZt9k65UtLZoihlfzlvuAJgjf0LFthpoNIAXTUl 7EKzdWGPbQPehUMj45dEtQkODjkm08ullpYaOzq64Nsv6MOkLoqwjg0nTuMxpVxy2Z YXziI6WABGNyg== From: "Jernej Tuljak" To: "'Dale R. Worley'" , "'Martin Bjorklund'" Date: Fri, 10 Jun 2016 10:45:58 +0200 Message-ID: <023801d1c2f4$8268cc90$873a65b0$@mg-soft.si> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdHC8TXpRukFgb7TSNeE5S0X6jHAZQ== Content-Language: sl Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Tokenizing and strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 08:46:05 -0000 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Dale R. > Worley > Sent: Friday, June 10, 2016 12:04 AM > To: Martin Bjorklund > Cc: netmod@ietf.org > Subject: [netmod] Tokenizing and strings (was: Gen-ART IETF Last Call=20 > review > of draft-ietf-netmod-rfc6020bis-12 (part 2)) > > At this point, I think there are some aspects of the use of strings = and > identifiers that aren't completely specified, but I'd have to check = the=20 > current > text to know for certain. However, that's a minor matter. > > The issue that concerns me is that the ABNF doesn't specify what is=20 > allowed > as a string. I'm used to programming language definitions, where the > grammar is specified quite rigidly, to the point that the ABNF can be=20 > input to > a parser generator. In this document, the ABNF is quite complete = except=20 > for > a specification of strings. On the other hand, the text description = of=20 > strings > seems to be sufficient for an implementer, so we don't actually need = to > provide ABNF. My strong preference is to provide a complete ABNF, as = is=20 > the > norm for programming languages. > > The following is a complete ABNF for Yang strings. Of course, it's a = bit > complicated, because the definition of strings in Yang actually is a = bit > complicated. > > string =3D unquoted-string / quoted-string > > unquoted-string =3D *unquoted-item ( unquoted-item / > "/" / > "*" *"*" ) > ;; a sequence of one or more characters from > ;; ordinary-char / "/" / "*", not containing > ;; "//", "/*", or "*/" This rule allows the "*/" sequence to appear inside unquoted strings! Less is more in case of YANG strings and grammars in general. You can be = as descriptive as you want in text, but not in pure ABNF. =20 You are also forgetting the fact that the existing 'string' production = expects an "unquoted string as returned by the scanner" (no quotes, no = concats, no pretty printing whitespace). Jernej > > unquoted-item =3D ordinary-char / > "/" ordinary-char / > "*" *"*" ordinary-char > > ordinary-char =3D < any character matching yang-char, except = > > < space, tab, newline, carriage return, > > < semicolon, left brace, right brace, > > < slash, and asterisk > > > *** Hmmm, is an unaccompanied CR allowed in an unquoted string? If = so, > "ordinary-char" and my previous text regarding line breaks need to be > amended. > > quoted-string =3D ( single-quoted-string / = double-quoted-string ) > *( optsep "+" optsep > ( single-quoted-string / = double-quoted-string ) > ) > > (I think you said that there can be whitespace around + but not = comments.) > > single-quoted-string =3D SQUOTE *sq-char SQUOTE > > sq-char =3D < any character matching yang-char, except > > < SQUOTE > > > double-quoted-string =3D DQUOTE *dq-item DQUOTE > > dq-item =3D dq-char / > "\n" / > "\t" / > "\" DQUOTE / > "\\" > > dq-char =3D < any character matching yang-char, except > > < DQUOTE and backslash > > > (The existing production for yang-string is removed.) > > ;; any Unicode or ISO/IEC 10646 character including tab, carriage > ;; return, and line feed, but excluding the other C0 control > ;; characters, the surrogate blocks, and the noncharacters. > yang-char =3D %x09 / %x0A / %x0D / %x20-D7FF / > [continuing as before] > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jun 10 02:06:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0B012D0FF for ; Fri, 10 Jun 2016 02:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 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=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbBRb1jyEk0K for ; Fri, 10 Jun 2016 02:06:43 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDD112D09E for ; Fri, 10 Jun 2016 02:06:43 -0700 (PDT) Received: from jernejthpPC (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 63B70C4175C2; Fri, 10 Jun 2016 11:06:42 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si 63B70C4175C2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1465549602; bh=RoOhBmBa1UvM29uX89J8x0oVAOeRHWE/0ioIFc2ii6s=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=CqwBbAaq+A6mEHTwr/uDOAN9qHT1Mv3Zy65VsOaBntBsrHv33CASmTBxvsbYz5RQe Iz4oll0PK/Q0aD51FHXOTU8uMU++Kz2LrmIbeHZdIss6eJ+GtwwaniERmiJ+4bSTHT 02+aTDJLUQ3F4C5NZlk7nG6NZ53jg3Wse+H5jBv2ZRtC5S2ng9/RX7AqkLo/9Ci7x3 itinfy/SvpQfpjg6UbK9Wu7MZL11wMHovHxxAVvFrnR8jseNmuLp+c3zTf+fyPHpPN 8BwBjrE65a9hbdg5hJ50ywC1QqvkMBj6MDGpiBWRAvvqPhvNzsu5cSkyXr+u0I6H+0 BBA1o2TJC3Mew== From: "Jernej Tuljak" To: "'Dale R. Worley'" , "'Martin Bjorklund'" References: <023801d1c2f4$8268cc90$873a65b0$@mg-soft.si> In-Reply-To: <023801d1c2f4$8268cc90$873a65b0$@mg-soft.si> Date: Fri, 10 Jun 2016 11:06:40 +0200 Message-ID: <023901d1c2f7$66cf0910$346d1b30$@mg-soft.si> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFeIPNWkkNVl/8sPdi0DSCD35DkCqDJrFEA Content-Language: sl Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Tokenizing and strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:06:45 -0000 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Jernej = Tuljak > Sent: Friday, June 10, 2016 10:46 AM > To: 'Dale R. Worley' ; 'Martin Bjorklund' = f.com> > Cc: netmod@ietf.org > Subject: Re: [netmod] Tokenizing and strings >=20 > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Dale R. > > Worley > > Sent: Friday, June 10, 2016 12:04 AM > > To: Martin Bjorklund > > Cc: netmod@ietf.org > > Subject: [netmod] Tokenizing and strings (was: Gen-ART IETF Last = Call > > review of draft-ietf-netmod-rfc6020bis-12 (part 2)) > > > > At this point, I think there are some aspects of the use of strings > > and identifiers that aren't completely specified, but I'd have to > > check the current text to know for certain. However, that's a minor > > matter. > > > > The issue that concerns me is that the ABNF doesn't specify what is > > allowed as a string. I'm used to programming language definitions, > > where the grammar is specified quite rigidly, to the point that the > > ABNF can be input to a parser generator. In this document, the ABNF > > is quite complete except >=20 > > for > > a specification of strings. On the other hand, the text description > > of strings seems to be sufficient for an implementer, so we don't > > actually need to provide ABNF. My strong preference is to provide a > > complete ABNF, as is >=20 > > the > > norm for programming languages. > > > > The following is a complete ABNF for Yang strings. Of course, it's = a > bit > > complicated, because the definition of strings in Yang actually is a > > bit complicated. > > > > string =3D unquoted-string / quoted-string > > > > unquoted-string =3D *unquoted-item ( unquoted-item / > > "/" / > > "*" *"*" ) > > ;; a sequence of one or more characters = from > > ;; ordinary-char / "/" / "*", not = containing > > ;; "//", "/*", or "*/" >=20 > This rule allows the "*/" sequence to appear inside unquoted strings! Scratch that. I had a bug in my test ANTLR4 grammar. Jernej >=20 > Less is more in case of YANG strings and grammars in general. You can = be as > descriptive as you want in text, but not in pure ABNF. >=20 > You are also forgetting the fact that the existing 'string' production = expects > an "unquoted string as returned by the scanner" (no quotes, no = concats, no > pretty printing whitespace). >=20 > Jernej >=20 >=20 > > > > unquoted-item =3D ordinary-char / > > "/" ordinary-char / > > "*" *"*" ordinary-char > > > > ordinary-char =3D < any character matching yang-char, = except > > > < space, tab, newline, carriage return, = > > > < semicolon, left brace, right brace, = > > > < slash, and asterisk = > > > > > *** Hmmm, is an unaccompanied CR allowed in an unquoted string? If > > so, "ordinary-char" and my previous text regarding line breaks need = to > > be amended. > > > > quoted-string =3D ( single-quoted-string / = double-quoted-string ) > > *( optsep "+" optsep > > ( single-quoted-string / > > double-quoted-string > ) > > ) > > > > (I think you said that there can be whitespace around + but not > comments.) > > > > single-quoted-string =3D SQUOTE *sq-char SQUOTE > > > > sq-char =3D < any character matching yang-char, except = > > > < SQUOTE > > > > > double-quoted-string =3D DQUOTE *dq-item DQUOTE > > > > dq-item =3D dq-char / > > "\n" / > > "\t" / > > "\" DQUOTE / > > "\\" > > > > dq-char =3D < any character matching yang-char, except = > > > < DQUOTE and backslash > > > > > (The existing production for yang-string is removed.) > > > > ;; any Unicode or ISO/IEC 10646 character including tab, carriage > > ;; return, and line feed, but excluding the other C0 control > > ;; characters, the surrogate blocks, and the noncharacters. > > yang-char =3D %x09 / %x0A / %x0D / %x20-D7FF / > > [continuing as before] > > > > Dale > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jun 10 02:18:14 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1324112D149; Fri, 10 Jun 2016 02:18:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610091814.15367.70801.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 02:18:14 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-13.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:18:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : The YANG 1.1 Data Modeling Language Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc6020bis-13.txt Pages : 209 Date : 2016-06-10 Abstract: YANG is a data modeling language used to model configuration data, state data, remote procedure calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 10 03:07:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1DA12D155; Fri, 10 Jun 2016 03:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 cnsC8iaYZhLR; Fri, 10 Jun 2016 03:07:17 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E340128E18; Fri, 10 Jun 2016 03:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5239; q=dns/txt; s=iport; t=1465553236; x=1466762836; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=1zeYw++2Klr2KvA1Z8x3NqYI/AZpQbNDzC1f5QHP7b8=; b=lQcs9tfEM2KtVC94rrOoEd/qAVgAxV+6D7pTmobQRglnjaJxXz1UAOC1 Iq9uOH7M4LVWZLvE6e1icYaL5A2BRQVH0anRpyFEFU7l6/ZicrhFJ4sqW hIVDfzODJDyVxmqpvP1p42M98t7ukBjmGeS0h4vAnYD+mq7Ncft/hvOnY o=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBACnkFpX/xbLJq1ehD+9b4YTAoF/A?= =?us-ascii?q?QEBAQEBZieERQEBAQMBI0gHFwsOCioCAlcGAQwIAQGIJAitP5BlAQEBAQEBBAE?= =?us-ascii?q?BAQEBAQESDoYngXcIgUuBA4dBgloBBI1uhVOFHoMugWmJEYFphFKDCYVcj2tUg?= =?us-ascii?q?gccgU06iHgrgRcBAQE?= X-IronPort-AV: E=Sophos;i="5.26,449,1459814400"; d="asc'?scan'208";a="637935954" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2016 10:07:14 +0000 Received: from [10.61.94.166] (ams3-vpn-dhcp7847.cisco.com [10.61.94.166]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5AA7E6s018502; Fri, 10 Jun 2016 10:07:14 GMT To: Cullen Jennings , opsawg@ietf.org, netmod@ietf.org References: From: Eliot Lear Message-ID: <2c4e6e62-cf41-d689-3046-1854d2f2385c@cisco.com> Date: Fri, 10 Jun 2016 12:07:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UKIc9Db4uHwCK7jDA58DXXVK6m5iOIBD7" Archived-At: Subject: Re: [netmod] Comments on draft-lear-ietf-netmod-mud-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:07:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UKIc9Db4uHwCK7jDA58DXXVK6m5iOIBD7 Content-Type: multipart/mixed; boundary="J1hSMRA0skBGc6qhCK2rQfULFIKMPogEE" From: Eliot Lear To: Cullen Jennings , opsawg@ietf.org, netmod@ietf.org Message-ID: <2c4e6e62-cf41-d689-3046-1854d2f2385c@cisco.com> Subject: Re: Comments on draft-lear-ietf-netmod-mud-02 References: In-Reply-To: --J1hSMRA0skBGc6qhCK2rQfULFIKMPogEE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Cullen, Generic answer to your message: please send text. More specifics below. On 6/7/16 11:57 PM, Cullen Jennings wrote: > I like how this is evolving ... few things=20 > > Few small things .... > > If you use CMS, I think you need to deal with how the JSON in canonical= ized before being signed. I will suggest that the standards the IETF crea= ted for signing JSON would be a better choice for signing JSON than CMS -= that's how most other JSON based stuff does it.=20 Within the bounds of widely available tooling I'm open to it, but would need to be convinced. I am somewhat comfortable with the CMS approach in which what we are signing is a file =E2=80=93 the fact that it is JSON= in incidental. What I would want see is a tool that can sign a JSON object and another one that can validate a signature through a chain of trust.=20 In addition, there is a relationship between the signer of the MUD file and, if 802.1AR is in play, the signer of that certificate that should =E2= =80=93 somehow=E2=80=93 be demonstrated. Ptrs welcome. > > Putting the last updated and cache validity in the file may not be a go= od plan. More importantly putting it inside the stuff that is singed seem= s problematic.=20 "Cache Validity" may be a misnomer here. The intent is that because there may be millions of Things out there in tens of thousands of deployment, the manufacturers can hint at how long they do NOT wish to hear from a requester. View this as a minimum validity period, but by no means a maximum. Last-updated is just that, but I don't understand your concern. > > The "ietf-mud:direction" stuff seems a bit under specified. Does from-= device mean that if the device imitates the flow, responses to the flow a= lso need to flow to the device? It seems like the ietf-netmod-acl-model d= raft might be a better place to specify this.=20 Personally I would be happy for it to go into the ACL model, if that is netmod's wish. The only issue with that, and it is not a big issue, is that we chose terminology that was slightly mud-oriented so as to avoid confusion as to what "in" and "out" might mean. This can also be included as a separate augmentation in a separate module if people think that's appropriate but it is necessary for MUD, and so that's why it is where it is at the moment. Again, happy to go with other approaches so long as the WG is okay with them. > > Use of "ietf-mud" as prefix in the JSON for "ietf-mud:direction" is not= how JSON typically does this. You don't need a namespace because we know= this is a mud file thus know the namespace. A big reason some people mov= ed from XML to JSON was exactly to get rid of namespace.=20 What's in there is what validates against pyang and yang2xml. No namespace is assumed on the outside, but rather the outer is ACL, and then on use where inner comes in, you need to name the namespace, or the tools will assume that MUD is invalid, as I understand it. Again, I am not a YANG expert. If the YANG people tell me I'm off base, I'd be happy to fix what's there. > > It's not a great practice to put ":" in the names of json attributes be= cause the way people use them in some languages often have them unquoted = which you can't do if there is a : in the name. You can do it, but "-" or= "_" might be better than ":" here.=20 I'm concerned about tool breakage as well, then. However, this is how things are specified in draft-ietf-netmod-yang-json-10. We would need to revisit that there, and I'm happy with whatever outcome of that discussion would be. > > It would be great to have an simple example JSON file in the introducti= on instead of (as well as a complete example in section 6) Good idea. Eliot --J1hSMRA0skBGc6qhCK2rQfULFIKMPogEE-- --UKIc9Db4uHwCK7jDA58DXXVK6m5iOIBD7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXWpFSAAoJEIe2a0bZ0nozL/EH/jmcVEXB7FSamVGkWkFdnlX9 fYnYVATjGkX4KGc+YAR9IfhwITEO3bPNWFkX3zC8RWkgWVYYgcG5Lo7Yzo+WyQfs larWEwx8hjser48OAF8MzEBPLxch38znY8qEgP7EQ1R9XyonyFgias1Dv0lF3joU LwIEx001aAvdwj+GhIrwOghrDbWY+EQxvDOr9qhFThyBfEzYdQ75yHVBA5OY1VM8 jpqimPsiyK+tziVJIzXLfD/9dur7WKCEJKtOjBhcZYnib+084RS+kuLK0PEFnhaS X6LiWEMjOkt+IYsduJOvkz5HsZPIBH5jjRXZREEeOu5v3NiIKfYZ0rbg+KtVgKk= =ck4I -----END PGP SIGNATURE----- --UKIc9Db4uHwCK7jDA58DXXVK6m5iOIBD7-- From nobody Fri Jun 10 04:06:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A00512D0A0 for ; Fri, 10 Jun 2016 04:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 eiCXaEUPLPKy for ; Fri, 10 Jun 2016 04:06:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5986612D09C for ; Fri, 10 Jun 2016 04:06:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 283CFFE4; Fri, 10 Jun 2016 13:06:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aVIJ05k0Dn3T; Fri, 10 Jun 2016 13:06:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Jun 2016 13:06:45 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F0742004E; Fri, 10 Jun 2016 13:06:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e41Dvkgu0mXv; Fri, 10 Jun 2016 13:06:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F32ED20047; Fri, 10 Jun 2016 13:06:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0DBD03B1B40E; Fri, 10 Jun 2016 13:06:42 +0200 (CEST) Date: Fri, 10 Jun 2016 13:06:42 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20160610110640.GA16061@elstar.local> Mail-Followup-To: netmod@ietf.org, Benoit Claise MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [netmod] YANG 1.1 final review of the edits resulting from the IESG process X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:06:49 -0000 Hi, Martin has posted revision -13 of the YANG 1.1 specification. This revision incorporates all comments that we have received during the IESG process. A big thanks in particular to our gen-art and ops-dir reviewers and to Martin for following up on the issues. Please check the edits do make sure that nothing broke. The diff can be found here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-13.txt Note that this is _not_ the time to raise new issues or to suggest alternate resolutions to issues discussed before. This is only a check to verify that the edits were done correctly. Please check the edits as soon as possible, any errors found must be raised by Thursday 2016-06-16. /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 Jun 10 04:37:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C754812B05E for ; Fri, 10 Jun 2016 04:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQaiMAF9dSNf for ; Fri, 10 Jun 2016 04:37:53 -0700 (PDT) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420C412D907 for ; Fri, 10 Jun 2016 04:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:Date:Subject:From:To:MIME-Version: Sender:Reply-To:Message-ID:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=mMQXUSnO7QQr+KfWG1pmiP9jniWc1G6b2+6UdcUD9Nk=; b=TxMfMRHvjNcC7YmzasVAlRbdH4 76BFhwdW8X6L3EqWfPc9FwCwHl2MOV4DB1cOO8LtOvOKyYhw3YlK2NxFxW71m/MVXgOBGvCIKdXju EFqIUcwLMbi+ngCPjaaDsvziQYiCRcrXxRHkvZqoNGtW0wXja4J36N+F3GuVPrkJ3QpYRokf+F83B SkTjSMcKu8u9SNtKEUdNXcfGtcR66mO+s2MaUw5Ybo4aQZ/6/gBul/rh39g1qWa5xTKnnVqix+gQD pazerPopRvDsYHbnoW73lXmSCkZHhASLtZWoHYQoFTEe4p3MRPLP7ydT06dO18Qm6+tnLeAiy+Y/E r8qovYMA==; Received: from host-212-159-131-153.static.as13285.net ([212.159.131.153]:53981 helo=[IPv6:::ffff:192.168.1.163]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bBKl2-000zzn-M0; Fri, 10 Jun 2016 12:37:48 +0100 MIME-Version: 1.0 To: netmod WG , Juergen Schoenwaelder From: Jonathan Hansford Date: Fri, 10 Jun 2016 12:45:17 +0100 Importance: normal X-Priority: 3 Content-Type: multipart/alternative; boundary="_83439902-81B5-4BF4-A2A2-66B18EEA1FD3_" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Message-Id: <20160610113752.420C412D907@ietfa.amsl.com> Archived-At: Subject: [netmod] draft-schoenw-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 11:37:55 -0000 --_83439902-81B5-4BF4-A2A2-66B18EEA1FD3_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Juergen, Page 6 s/have proprietary mechanism/have proprietary mechanisms Page 9 s/in a configuration datastores/in a configuration datastore s/An example are/An example is Section 6.2 I have not been following developments with RESTCONF, but could the =E2=80= =9Ccontent=E2=80=9D query parameter also be used to allow writes to datasto= res other than running? This is not central to the purpose of the document, but on page 5 you state= =E2=80=9Cthe datastore can only be modified by copying = to in NETCONF=E2=80=9D. If you wanted to startup datastore to di= ffer from the running datastore (e.g. you needed to make changes to the run= ning datastore but didn=E2=80=99t want those changes to persist beyond a re= start or you wanted to make changes that would only apply after a restart) = couldn=E2=80=99t you copy the startup datastore to the candidate datastore,= make the changes then copy the candidate back to the startup? Jonathan =3DO) --_83439902-81B5-4BF4-A2A2-66B18EEA1FD3_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Juergen,

 

Page 6

s/have proprietary mecha= nism/have proprietary mechanisms

&n= bsp;

Page 9

s/in a configuration datastores/in a configuration datastore

s/An example are/An example is

 

Section 6.2

I have not been following developments with RES= TCONF, but could the =E2=80=9Ccontent=E2=80=9D query parameter also be used= to allow writes to datastores other than running?


This is not central to the purpose of the document, but on= page 5 you state =E2=80=9Cthe <startup> datastore can only be modifi= ed by copying <running> to <startup> in NETCONF=E2=80=9D. If yo= u wanted to startup datastore to differ from the running datastore (e.g. yo= u needed to make changes to the running datastore but didn=E2=80=99t want t= hose changes to persist beyond a restart or you wanted to make changes that= would only apply after a restart) couldn=E2=80=99t you copy the startup da= tastore to the candidate datastore, make the changes then copy the candidat= e back to the startup?

 =

Jonathan

=3DO)

 = ;

= --_83439902-81B5-4BF4-A2A2-66B18EEA1FD3_-- From nobody Fri Jun 10 05:12:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923B212B008 for ; Fri, 10 Jun 2016 05:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.948 X-Spam-Level: X-Spam-Status: No, score=-15.948 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 ZH8CfyYIsXJw for ; Fri, 10 Jun 2016 05:12:21 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE36F12D907 for ; Fri, 10 Jun 2016 05:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=848; q=dns/txt; s=iport; t=1465560740; x=1466770340; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6C48b0jk+qgPdBz1UaNcgeRrCTZsKyWakH2kNbg+EFo=; b=EDTNYBT2eLuvSiAuFWq/MwnBVyPqnTOBctVFji9gFmFSypXhd64C5DO3 j+1rUgA6kePHhcUFN/Rj977Jg2yw7RYzNrcfcs4wZCyboOs5mGck+bq3Q wk4hA13tZENOojJfUT2OKQZ3sCthFYHvTHbiIWetC92Iwy0ofrl+xZ+ON g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQCprVpX/xbLJq1dhBQrUrkTgg+Be?= =?us-ascii?q?iKFcQKBaxQBAQEBAQEBZSeERgEBBDIBBUEQCw44VwYNCAEBiCwOvg8BAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEaBYYngXcIgk6KGwEEmF+GBIgkgWmEUoMJhEKBGo9rHjaDc?= =?us-ascii?q?DoyAYoHAQEB?= X-IronPort-AV: E=Sophos;i="5.26,449,1459814400"; d="scan'208";a="677649872" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2016 12:12:18 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5ACCIxj020396; Fri, 10 Jun 2016 12:12:18 GMT To: Juergen Schoenwaelder References: <20160610110640.GA16061@elstar.local> From: Benoit Claise Message-ID: Date: Fri, 10 Jun 2016 14:12:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160610110640.GA16061@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] YANG 1.1 final review of the edits resulting from the IESG process X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 12:12:22 -0000 Thank you Jürgen and Martin. The document really improved IMO. Regards, Benoit > Hi, > > Martin has posted revision -13 of the YANG 1.1 specification. This > revision incorporates all comments that we have received during the > IESG process. A big thanks in particular to our gen-art and ops-dir > reviewers and to Martin for following up on the issues. Please check > the edits do make sure that nothing broke. The diff can be found > here: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-13.txt > > Note that this is _not_ the time to raise new issues or to suggest > alternate resolutions to issues discussed before. This is only a check > to verify that the edits were done correctly. Please check the edits > as soon as possible, any errors found must be raised by Thursday > 2016-06-16. > > /js > From nobody Fri Jun 10 05:53:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A84212D16C for ; Fri, 10 Jun 2016 05:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 XIcAvWeG1u8X for ; Fri, 10 Jun 2016 05:53:33 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3FB12B027 for ; Fri, 10 Jun 2016 05:53:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2DFA2129C; Fri, 10 Jun 2016 14:53:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SkC-o3qKUlzy; Fri, 10 Jun 2016 14:53:26 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Jun 2016 14:53:30 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDD942004E; Fri, 10 Jun 2016 14:53:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QX89slSO8LNr; Fri, 10 Jun 2016 14:53:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8205220047; Fri, 10 Jun 2016 14:53:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 55FEA3B1B6FE; Fri, 10 Jun 2016 14:53:29 +0200 (CEST) Date: Fri, 10 Jun 2016 14:53:29 +0200 From: Juergen Schoenwaelder To: Jonathan Hansford Message-ID: <20160610125329.GA16283@elstar.local> Mail-Followup-To: Jonathan Hansford , netmod WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod WG Subject: Re: [netmod] draft-schoenw-netmod-revised-datastores-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 12:53:35 -0000 On Fri, Jun 10, 2016 at 12:45:17PM +0100, Jonathan Hansford wrote: > Juergen, > > Page 6 > s/have proprietary mechanism/have proprietary mechanisms > > Page 9 > s/in a configuration datastores/in a configuration datastore > s/An example are/An example is Thanks. > Section 6.2 > I have not been following developments with RESTCONF, but could the “content” query parameter also be used to allow writes to datastores other than running? Perhaps it could be extended in this way but I am not sure this is what the designers had in mind. > This is not central to the purpose of the document, but on page 5 > you state “the datastore can only be modified by copying > to in NETCONF”. If you wanted to startup > datastore to differ from the running datastore (e.g. you needed to > make changes to the running datastore but didn’t want those changes > to persist beyond a restart or you wanted to make changes that would > only apply after a restart) couldn’t you copy the startup datastore > to the candidate datastore, make the changes then copy the candidate > back to the startup? The regular copies the content of the candidate datastore to the datastore. Note that validation happens during the commit. So the standardized commit model is really to . That said, in principle could be used to copy to but then this is not clearly defined (e.g., it is not spelled out that validation should happen in this case much as in the commit case; I think a silent assumption is that assumes to copy valid datastore content - and the content of may be invalid. Similarly, the operation really is at a semantic level a copy of to (of course an implementation may not do a full copy). So yes, an implementation may support other editing models but given the way the RFC is written, I think you can't rely on other editing models to be supported and to work in an interoperable way. /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 Jun 10 06:00:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D709D12D565 for ; Fri, 10 Jun 2016 06:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 EFDdoPtdMtP1 for ; Fri, 10 Jun 2016 06:00:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7EF12D100 for ; Fri, 10 Jun 2016 06:00:22 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:e4c4:5f88:4a1e:72d9] (unknown [IPv6:2001:718:1a02:1:e4c4:5f88:4a1e:72d9]) by mail.nic.cz (Postfix) with ESMTPSA id E765861699; Fri, 10 Jun 2016 15:00:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465563620; bh=GDVpomlixddrOyPDOmxc/L9WJofWrZztR0B+bm+qgKg=; h=From:Date:To; b=reUvqW7YfNVyHjmZeFX6TEpLnODYIpVthDi03mxx9+ZbrHLGqWR5OdggyPzstth1U tMQfO7L3ARMzT07pjqvMtyeTAMl5Znhku5Z7clgLfCCEQgPPSkuJbQ0986spmSPyuV TDLE4wATvJWeoVbXHnU7EKIAcmMdrbGxRORlXBBA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160610110640.GA16061@elstar.local> Date: Fri, 10 Jun 2016 15:00:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44045A0D-6C6F-49CE-B21C-E29EBA37BB21@nic.cz> References: <20160610110640.GA16061@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 final review of the edits resulting from the IESG process X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 13:00:29 -0000 Hi, I don't want to open a new round of discussion about the leafref issue, = but I think the text in sec. 9.9 isn't correct: - The first paragraph says that "path" refers to a leaf or leaf-list = schema node - OK. - The second paragraph then says: If the "require-instance" property (Section 9.9.3) is "true", there MUST exist an node in the data tree, or a node with a default value in use (see Section 7.6.1 and Section 7.7.2), of the referred schema tree leaf or leaf-list node with the same value as the leafref value in a valid data tree. IMO this means that *any* instance of the referred leaf or leaf-list = schema node would do, whereas in fact the instance must belong to the = node set resulting from the "path" expression (evaluated as XPath). In = other words, if the "path" statement selects a specific list entry via = path predicate, the required instance must be in this entry. Lada =20 > On 10 Jun 2016, at 13:06, Juergen Schoenwaelder = wrote: >=20 > Hi, >=20 > Martin has posted revision -13 of the YANG 1.1 specification. This > revision incorporates all comments that we have received during the > IESG process. A big thanks in particular to our gen-art and ops-dir > reviewers and to Martin for following up on the issues. Please check > the edits do make sure that nothing broke. The diff can be found > here: >=20 > = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6020bis-13.txt >=20 > Note that this is _not_ the time to raise new issues or to suggest > alternate resolutions to issues discussed before. This is only a check > to verify that the edits were done correctly. Please check the edits > as soon as possible, any errors found must be raised by Thursday > 2016-06-16. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jun 10 06:48:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4D12D5E3 for ; Fri, 10 Jun 2016 06:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 6BT9upmi5tQ2 for ; Fri, 10 Jun 2016 06:48:31 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 13BC012D53B for ; Fri, 10 Jun 2016 06:48:30 -0700 (PDT) Received: from localhost (h-155-4-131-90.na.cust.bahnhof.se [155.4.131.90]) by mail.tail-f.com (Postfix) with ESMTPSA id 35C2E1AE0312; Fri, 10 Jun 2016 15:48:28 +0200 (CEST) Date: Fri, 10 Jun 2016 15:48:27 +0200 (CEST) Message-Id: <20160610.154827.552634417076173871.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <44045A0D-6C6F-49CE-B21C-E29EBA37BB21@nic.cz> References: <20160610110640.GA16061@elstar.local> <44045A0D-6C6F-49CE-B21C-E29EBA37BB21@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 final review of the edits resulting from the IESG process X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 13:48:32 -0000 Ladislav Lhotka wrote: > Hi, > > I don't want to open a new round of discussion about the leafref > issue, but I think the text in sec. 9.9 isn't correct: > > - The first paragraph says that "path" refers to a leaf or leaf-list > - schema node - OK. > > - The second paragraph then says: > > If the "require-instance" property (Section 9.9.3) is "true", > there MUST exist an node in the data tree, or a node with a > default value in use (see Section 7.6.1 and Section 7.7.2), > of the referred schema tree leaf or leaf-list node with the > same value as the leafref value in a valid data tree. > > IMO this means that *any* instance of the referred leaf or leaf-list > schema node would do, whereas in fact the instance must belong to the > node set resulting from the "path" expression (evaluated as XPath). In > other words, if the "path" statement selects a specific list entry via > path predicate, the required instance must be in this entry. Note that the text for "path" provides further details: The "path" expression evaluates to a node set consisting of zero, one, or more nodes. If the leaf with the leafref type represents configuration data, this node set MUST be non-empty. However, this part is not correct in YANG 1.1 :( It would be more correct to say: NEW: The "path" expression evaluates to a node set consisting of zero, one, or more nodes. If the "require-instance" property is "true", this node set MUST be non-empty. /martin > > Lada > > > > On 10 Jun 2016, at 13:06, Juergen Schoenwaelder > > wrote: > > > > Hi, > > > > Martin has posted revision -13 of the YANG 1.1 specification. This > > revision incorporates all comments that we have received during the > > IESG process. A big thanks in particular to our gen-art and ops-dir > > reviewers and to Martin for following up on the issues. Please check > > the edits do make sure that nothing broke. The diff can be found > > here: > > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-13.txt > > > > Note that this is _not_ the time to raise new issues or to suggest > > alternate resolutions to issues discussed before. This is only a check > > to verify that the edits were done correctly. Please check the edits > > as soon as possible, any errors found must be raised by Thursday > > 2016-06-16. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Jun 10 07:02:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4002012B005 for ; Fri, 10 Jun 2016 07:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 ubm3CsuS-QmN for ; Fri, 10 Jun 2016 07:02:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FB912D0B5 for ; Fri, 10 Jun 2016 07:02:50 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:e4c4:5f88:4a1e:72d9] (unknown [IPv6:2001:718:1a02:1:e4c4:5f88:4a1e:72d9]) by mail.nic.cz (Postfix) with ESMTPSA id C2BE660844; Fri, 10 Jun 2016 16:02:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465567368; bh=8U9Sn7LRXhsQmM+qpgtcZk1bTzByaAS5Sqi4wZdsUhA=; h=From:Date:To; b=KeisJT87AKmGwmXTaPgKaICd6yXXTGdXzcl7ToZjFa/o4WHwWHY3JAar6wLP7iCRE Y+6ewahUmvUJRP4OsyTw8HYdNccN8JqeDgistL6b/oIy4rW92hKofnA5C8y35TprNd wThiN0I6pxLk0E9sr7yQZhVtC9Mx+wnmlJ07yKQo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160610.154827.552634417076173871.mbj@tail-f.com> Date: Fri, 10 Jun 2016 16:02:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160610110640.GA16061@elstar.local> <44045A0D-6C6F-49CE-B21C-E29EBA37BB21@nic.cz> <20160610.154827.552634417076173871.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 final review of the edits resulting from the IESG process X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 14:02:53 -0000 > On 10 Jun 2016, at 15:48, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> I don't want to open a new round of discussion about the leafref >> issue, but I think the text in sec. 9.9 isn't correct: >>=20 >> - The first paragraph says that "path" refers to a leaf or leaf-list >> - schema node - OK. >>=20 >> - The second paragraph then says: >>=20 >> If the "require-instance" property (Section 9.9.3) is "true", >> there MUST exist an node in the data tree, or a node with a >> default value in use (see Section 7.6.1 and Section 7.7.2), >> of the referred schema tree leaf or leaf-list node with the >> same value as the leafref value in a valid data tree. >>=20 >> IMO this means that *any* instance of the referred leaf or leaf-list >> schema node would do, whereas in fact the instance must belong to the >> node set resulting from the "path" expression (evaluated as XPath). = In >> other words, if the "path" statement selects a specific list entry = via >> path predicate, the required instance must be in this entry. >=20 > Note that the text for "path" provides further details: >=20 > The "path" expression evaluates to a node set consisting of zero, > one, or more nodes. If the leaf with the leafref type represents > configuration data, this node set MUST be non-empty. >=20 > However, this part is not correct in YANG 1.1 :( It would be more > correct to say: >=20 > NEW: >=20 > The "path" expression evaluates to a node set consisting of zero, > one, or more nodes. If the "require-instance" property is "true", > this node set MUST be non-empty. Right, and then the second paragraph from the beginning of sec. 9.9 = should be removed because it says something else. Also, shouldn't the text about "path" statement in the first paragraph = of 9.9 ('The "path" substatement ... is the value space of the referred = node.') be moved to 9.9.2? Lada >=20 >=20 > /martin >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >> Lada >>=20 >>=20 >>> On 10 Jun 2016, at 13:06, Juergen Schoenwaelder >>> wrote: >>>=20 >>> Hi, >>>=20 >>> Martin has posted revision -13 of the YANG 1.1 specification. This >>> revision incorporates all comments that we have received during the >>> IESG process. A big thanks in particular to our gen-art and ops-dir >>> reviewers and to Martin for following up on the issues. Please check >>> the edits do make sure that nothing broke. The diff can be found >>> here: >>>=20 >>> = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6020bis-13.txt >>>=20 >>> Note that this is _not_ the time to raise new issues or to suggest >>> alternate resolutions to issues discussed before. This is only a = check >>> to verify that the edits were done correctly. Please check the edits >>> as soon as possible, any errors found must be raised by Thursday >>> 2016-06-16. >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jun 10 09:04:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E006712D5CD; Fri, 10 Jun 2016 09:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, UNPARSEABLE_RELAY=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 BDcectcr2ypp; Fri, 10 Jun 2016 09:04:35 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9F65512D7CF; Fri, 10 Jun 2016 09:04:35 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u5AG2GOl042589; Fri, 10 Jun 2016 12:02:16 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Eliot Lear , Cullen Jennings , "opsawg@ietf.org" , "netmod@ietf.org" Thread-Topic: [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02 Thread-Index: AdHDL4kpW8AS7YjqckuQ9S2y/iP9Ww== Date: Fri, 10 Jun 2016 15:48:30 +0000 Message-ID: <20160610154838.18296913.36394.73505@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0222592839==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-10_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606100178 Archived-At: Subject: Re: [netmod] [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:04:38 -0000 --===============0222592839== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Canonicalization is the way to avoid file content being mangled or represen= ted differently by different (software) entities that try to create or veri= fy digital signature over it. It doesn't matter if your file is binary or n= ot. And CMS by itself won't save you either.=E2=80=8E This problem (ensurin= g there is only one way to represent the contents of the file in question) = is what you need to show that you solved. Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Eliot Lear Sent: Friday, June 10, 2016 06:08 To: Cullen Jennings; opsawg@ietf.org; netmod@ietf.org Subject: Re: [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02 Hi Cullen, Generic answer to your message: please send text. More specifics below. On 6/7/16 11:57 PM, Cullen Jennings wrote: > I like how this is evolving ... few things=20 > > Few small things .... > > If you use CMS, I think you need to deal with how the JSON in canonicaliz= ed before being signed. I will suggest that the standards the IETF created = for signing JSON would be a better choice for signing JSON than CMS - that'= s how most other JSON based stuff does it.=20 Within the bounds of widely available tooling I'm open to it, but would need to be convinced. I am somewhat comfortable with the CMS approach in which what we are signing is a file =E2=80=93 the fact that it is JSON in incidental. What I would want see is a tool that can sign a JSON object and another one that can validate a signature through a chain of trust.=20 In addition, there is a relationship between the signer of the MUD file and, if 802.1AR is in play, the signer of that certificate that should =E2= =80=93 somehow=E2=80=93 be demonstrated. Ptrs welcome. > > Putting the last updated and cache validity in the file may not be a good= plan. More importantly putting it inside the stuff that is singed seems pr= oblematic.=20 "Cache Validity" may be a misnomer here. The intent is that because there may be millions of Things out there in tens of thousands of deployment, the manufacturers can hint at how long they do NOT wish to hear from a requester. View this as a minimum validity period, but by no means a maximum. Last-updated is just that, but I don't understand your concern. > > The "ietf-mud:direction" stuff seems a bit under specified. Does from-dev= ice mean that if the device imitates the flow, responses to the flow also n= eed to flow to the device? It seems like the ietf-netmod-acl-model draft mi= ght be a better place to specify this.=20 Personally I would be happy for it to go into the ACL model, if that is netmod's wish. The only issue with that, and it is not a big issue, is that we chose terminology that was slightly mud-oriented so as to avoid confusion as to what "in" and "out" might mean. This can also be included as a separate augmentation in a separate module if people think that's appropriate but it is necessary for MUD, and so that's why it is where it is at the moment. Again, happy to go with other approaches so long as the WG is okay with them. > > Use of "ietf-mud" as prefix in the JSON for "ietf-mud:direction" is not h= ow JSON typically does this. You don't need a namespace because we know thi= s is a mud file thus know the namespace. A big reason some people moved fro= m XML to JSON was exactly to get rid of namespace.=20 What's in there is what validates against pyang and yang2xml. No namespace is assumed on the outside, but rather the outer is ACL, and then on use where inner comes in, you need to name the namespace, or the tools will assume that MUD is invalid, as I understand it. Again, I am not a YANG expert. If the YANG people tell me I'm off base, I'd be happy to fix what's there. > > It's not a great practice to put ":" in the names of json attributes beca= use the way people use them in some languages often have them unquoted whic= h you can't do if there is a : in the name. You can do it, but "-" or "_" m= ight be better than ":" here.=20 I'm concerned about tool breakage as well, then. However, this is how things are specified in draft-ietf-netmod-yang-json-10. We would need to revisit that there, and I'm happy with whatever outcome of that discussion would be. > > It would be great to have an simple example JSON file in the introduction= instead of (as well as a complete example in section 6) Good idea. Eliot --===============0222592839== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDYxMDE1NDgzNVowLwYJKoZIhvcNAQkEMSIEIN9hUmLNHJbf iddeeW4gUXj5rV8weckTLqWcHRyXgg8RMAsGCSqGSIb3DQEBCwSCAQArkhLVsdiLnPbdqQ1UUGTo OKL7hK5sR4ZVpvAUmHtg3WKkZBbs9mt1OUMadDl9sptgF4XuW8rE5xAkswtkL5Kuk3eVnfsHgb0K LaZpBjuxzGT8VSbresErYX9CnbT408s+7cpAJjIuExgBcZe8u/jhpadUktcyTsU/g4qj590lIg48 5kb+PX/GnZh1+pXFLfzj8A3/g6iNUu4VK630QGwCHtk0etLQxnYO2EVXrTgygPx52Q62r0sLgt6C rhkC/om+QQFtQ3ZGnbdLmuoYy7x7XQy6lOiySwqf3xVh9JCtc4QImyV8cJyN0qmt8ckOc+DHdrqx ut2NjmXh0a3gK4e3AAAAAAAA --===============0222592839==-- From nobody Fri Jun 10 10:04:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F56B12D5B0; Fri, 10 Jun 2016 10:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.948 X-Spam-Level: X-Spam-Status: No, score=-15.948 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 C8Q0eGXrdLcX; Fri, 10 Jun 2016 10:03:55 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23D112D11A; Fri, 10 Jun 2016 10:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2260; q=dns/txt; s=iport; t=1465578235; x=1466787835; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=eq7JYEQG19OAJf6aZakVPNR/qE0vruB3vVJHyvb67Uw=; b=dWe+WAOYjdC77RK8iRRnHX9p2+BYTPPQZ8Lwv011+724uvjiy9tGSsnq Lm0He2TCYm66utHU5SJckMpaJXr5U4eWWdFK4GgDxaw7nOXmXyAWvEjQ4 lh/KI0s1a7KZfbJQ3zteGTfPygbNlJnl5J5BYIVAHOnS1FK2YNb7S8byH w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrBADf8VpX/xbLJq1eDoQGK7lnhAmCY?= =?us-ascii?q?IMzAoFlEQEBAQEBAQFlJ4RGAQEEI2YLGCoCAlcGAQwIAQGILK01kGABAQEBAQE?= =?us-ascii?q?EAQEBAQEBARIOhieBd4JWh0GCWgEEmF+DLoFpiRGJRIVcj2s0IIMzPTqKOgEBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.26,451,1459814400"; d="asc'?scan'208";a="677654892" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2016 17:03:52 +0000 Received: from [10.61.103.52] (dhcp-10-61-103-52.cisco.com [10.61.103.52]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5AH3q6F005993; Fri, 10 Jun 2016 17:03:52 GMT To: "Blumenthal, Uri - 0553 - MITLL" , Cullen Jennings , "opsawg@ietf.org" , "netmod@ietf.org" References: <20160610154838.18296913.36394.73505@ll.mit.edu> From: Eliot Lear Message-ID: Date: Fri, 10 Jun 2016 19:03:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160610154838.18296913.36394.73505@ll.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ttoK74putASSqjjFb3KjVwexc9PmgM00m" Archived-At: Subject: Re: [netmod] [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 17:03:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ttoK74putASSqjjFb3KjVwexc9PmgM00m Content-Type: multipart/mixed; boundary="29nW0rbrWiK5bQPwPhlJ5oNkGoR77Jgm8" From: Eliot Lear To: "Blumenthal, Uri - 0553 - MITLL" , Cullen Jennings , "opsawg@ietf.org" , "netmod@ietf.org" Message-ID: Subject: Re: [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02 References: <20160610154838.18296913.36394.73505@ll.mit.edu> In-Reply-To: <20160610154838.18296913.36394.73505@ll.mit.edu> --29nW0rbrWiK5bQPwPhlJ5oNkGoR77Jgm8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Uri, On 6/10/16 5:48 PM, Blumenthal, Uri - 0553 - MITLL wrote: > Canonicalization is the way to avoid file content being mangled or repr= esented differently by different (software) entities that try to create o= r verify digital signature over it. It doesn't matter if your file is bin= ary or not. And CMS by itself won't save you either.=E2=80=8E This proble= m (ensuring there is only one way to represent the contents of the file i= n question) is what you need to show that you solved. I totally get it. From a MIME perspective it'll be something like application/mud+json, encoded in UTF-8, and transported accordingly (HTTPS is 8-bit clean). This is not going to be our problem. Eliot --29nW0rbrWiK5bQPwPhlJ5oNkGoR77Jgm8-- --ttoK74putASSqjjFb3KjVwexc9PmgM00m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXWvL3AAoJEIe2a0bZ0nozyicH/2E3bMysXRZib5sdramtl3YC PbG6mj7I/o6lRv60cGlCsbZXArG+vKCqB8I9KiGLFykgkW4Z73Djb/Z5Qth6av/x TBC7g5qqJE0vvGfI7QRkA4OS3KP1jYy6RTcqFfpX4KMj5VwIs0ILce+G/HHRKObZ /6n1b6wyy9I6Rw8Dv2y37UHEZXm/PpmZtGrzHrrvzsv8cyefi5g9crlG1JfRGTLk IdEDmpamXjnpUHCQxUiHTnAIU2vPgQMOyyRvIhZsCrTdG6tjp3esJ602crURK0j1 g+051edkMUQxWBHVQclAun2xbnCj4iZ2MbrnZ0upzwzen05WRE/nr2CKhoWiT/Y= =+BTt -----END PGP SIGNATURE----- --ttoK74putASSqjjFb3KjVwexc9PmgM00m-- From nobody Fri Jun 10 10:14:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80A412D821; Fri, 10 Jun 2016 10:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, UNPARSEABLE_RELAY=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 gODerPHAuQVi; Fri, 10 Jun 2016 10:14:34 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id BCB0A12D81E; Fri, 10 Jun 2016 10:14:34 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u5AHC1iC041123; Fri, 10 Jun 2016 13:12:15 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Eliot Lear , Cullen Jennings , "opsawg@ietf.org" , "netmod@ietf.org" Thread-Topic: [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02 Thread-Index: AdHDL4kpW8AS7YjqckuQ9S2y/iP9WwALA2mAAABRzwA= Date: Fri, 10 Jun 2016 17:12:51 +0000 Message-ID: <20160610171236.18296913.45232.73529@ll.mit.edu> References: <20160610154838.18296913.36394.73505@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0278999567==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606100191 Archived-At: Subject: Re: [netmod] [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 17:14:37 -0000 --===============0278999567== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Just "encoding" is not enough - it's *how exactly*=E2=80=8E the file is enc= oded. Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Eliot Lear Sent: Friday, June 10, 2016 13:04 To: Blumenthal, Uri - 0553 - MITLL; Cullen Jennings; opsawg@ietf.org; netmo= d@ietf.org Subject: Re: [OPSAWG] Comments on draft-lear-ietf-netmod-mud-02 Hi Uri, On 6/10/16 5:48 PM, Blumenthal, Uri - 0553 - MITLL wrote: > Canonicalization is the way to avoid file content being mangled or repres= ented differently by different (software) entities that try to create or ve= rify digital signature over it. It doesn't matter if your file is binary or= not. And CMS by itself won't save you either.=E2=80=8E This problem (ensur= ing there is only one way to represent the contents of the file in question= ) is what you need to show that you solved. I totally get it. From a MIME perspective it'll be something like application/mud+json, encoded in UTF-8, and transported accordingly (HTTPS is 8-bit clean). This is not going to be our problem. Eliot --===============0278999567== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDYxMDE3MTIzNFowLwYJKoZIhvcNAQkEMSIEIPlL0XlIGaJR 1RX3UNubg0iYUJOHhydvrnyGpbPCDwCBMAsGCSqGSIb3DQEBCwSCAQBb1enEyKDvc5xq0JcbcA+D 6jNiG4hVjP8OnMBYY1lRAyD8qjis0IqNVKaQGnPVljXUCDQ7zdfxvi35uTtEXKh2cJhFx1jqpie0 BTLWGlpLwTsHGeW97eVCYW1YQ37IfAJBSB14AE0ZI9/x2jR3Ejn/fv65Q4NzDsDmZzODp4r6E+aJ 1By/+tdgoh+j5GjaUHaM4o3HhubP1Zb314HSSKhrPNOIg+zPOnmP5hRAts8EiR3w4Sno+TSPhe2L 8CHv5NzE3EkoQMIcXYM5I/Ep1KazKpeXd7YI9n7/4Hwts+b/YzWqQCkG5VGMcnejhO7ldFWKtprZ omzdEbX3cIjWdyFKAAAAAAAA --===============0278999567==-- From nobody Fri Jun 10 19:21:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7F412D671 for ; Fri, 10 Jun 2016 19:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhrXTzib3roi for ; Fri, 10 Jun 2016 19:21:48 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 44FD612D5B0 for ; Fri, 10 Jun 2016 19:21:48 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id v48so26753709qgd.2 for ; Fri, 10 Jun 2016 19:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=tMdFgkrtJ3OrU3OKFIe7DSyj7/brq6rKZWffD1ue/XI=; b=ykxtByRGAf5CWGSBhmBA7KceCLsmGIeIAPene5IvjoYXNS3faQD8oeB66m7K4e18Fm 83lEdvFr5LA9WyNJT/5MVlRVmyItcZabFWaRrk3E4ZHTsW3brhaiYmkNnY9/abK6uqQ4 rcPptHSwU1WbLwBuPxyDrT9tTC2pom7KTLXr0dnA+TSEea/RGgem5O1TqQqJmlzyQvc6 +wnO5BFP8b9m9PmtA8qOG0vqJglLlDvk2KZSgX4pemU7nogMNB3BIHgHZr8/ICMuCGMg JwRMrUj9CxxqflrkSzKglnWUKRfOWPW7eMiaiVhrbxKuqCbovexgC3jQgoEvaeE6g37c TNow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=tMdFgkrtJ3OrU3OKFIe7DSyj7/brq6rKZWffD1ue/XI=; b=ag39TWc/c9C/wcJ3S8LUd57VSHcFHUxZe9anabetMBf7LST1G8so8qfn/LxOpbcVwP fE35Cwc/2pu8AtJV+Qsb85vW5nQel9dQ0jNcuYQ4Vd3tA2xAee55iHi1o+n1N4HPuNs8 XnW8H+ZH/bUOsvo2cNDwXKF21PcqpIT3oSqVBt/+SeRoakFwi4dVbvWYsPJAaDhnK6nz QRYwAeSplCFzH1YYAlhibW7FJNDNqFY14ddJ7BST+IoHci4SF5p251HGEif4wdpLxh8F e7AKH8XahWPmZXTwdz29k4LhN1WALJerrARGIGMAVAzdEvkySnVl0R68FM5mMviYdbz3 AdOw== X-Gm-Message-State: ALyK8tIOcuhOLWPyhmBkstDdL+EYKRCIHu7PTd5oPFdhSxv8ZAU1nIBaJ+BxhnvI946i7CFJlz+sQfCuPSvrhA== MIME-Version: 1.0 X-Received: by 10.140.203.213 with SMTP id y204mr4875611qha.45.1465611707386; Fri, 10 Jun 2016 19:21:47 -0700 (PDT) Received: by 10.200.56.16 with HTTP; Fri, 10 Jun 2016 19:21:47 -0700 (PDT) Date: Fri, 10 Jun 2016 19:21:47 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114f411832aacf0534f7514e Archived-At: Subject: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 02:21:50 -0000 --001a114f411832aacf0534f7514e Content-Type: text/plain; charset=UTF-8 Hi, I am trying to implement YANG 1.1 must-stmt extensions. They appear to be under-specified. In sec. 7.5.3 The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1 : o The context node is the node in the accessible tree for which the "must" statement is defined. The problem for input/output is that these nodes are not encoded in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines the XPath context for input and output, so 7.5.3 is incorrect. 7.5.3 should say the context node for input/output is the node representing the RPC operation. This would be the same for NETCONF encoding of action. The RESTCONF encoding for RPC and action is completely different but the definition in 7.5.3 is actually correct for RESTCONF. The problem for notification is not that is not in the instance document, but rather that it is not part of the XPath context: o If the XPath expression is defined in a substatement to a "notification" statement, the accessible tree is the notification instance, all state data in the server, and the running configuration datastore. * If the notification is defined on the top-level in a module, then the root node has the node representing the notification being defined* and all top-level data nodes in all modules as children. Otherwise, the root node has all top-level data nodes in all modules as children. The context node for should be the node representing the notification. Andy --001a114f411832aacf0534f7514e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am trying to implement YANG 1.1 m= ust-stmt extensions.
They appear to be under-specified.

In sec. 7.5.3

   The XPath expression is conceptually evaluated in the f=
ollowing
   context, in addition to the definition in Section 6.4.1:

   o  The context node is the node in the accessible tree for which the
      "must" statement is defined.

The problem for input/output is that these nodes are not encoded<= br>in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines the<= br>XPath context for input and output, so 7.5.3 is incorrect.

7.5.3 = should say the context node for input/output is the node representing
th= e RPC operation. This would be the same for NETCONF encoding of action.
= The RESTCONF encoding for RPC and action is completely different
but the= definition in 7.5.3 is actually correct for RESTCONF.


The probl= em for notification is not that <notification> is not in the
insta= nce document, but rather that it is not part of the XPath context:

   o  If the XPath expression is defi=
ned in a substatement to a
      "notification" statement, the accessible tree is the notifi=
cation
      instance, all state data in the server, and the running
      configuration datastore.  If the notification is defined on the
      top-level in a module, then the root node has the node
      representing the notification being defined and all top-level dat=
a
      nodes in all modules as children.  Otherwise, the root node has
      all top-level data nodes in all modules as children.

The con= text node for <notification> should be the node representing the noti= fication.



Andy
=

--001a114f411832aacf0534f7514e-- From nobody Sun Jun 12 17:52:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCF912D1D2 for ; Sun, 12 Jun 2016 17:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.766 X-Spam-Level: X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 YWB0BxmOyxiS for ; Sun, 12 Jun 2016 17:52:45 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 B0E2E12D0A8 for ; Sun, 12 Jun 2016 17:52:44 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-04v.sys.comcast.net with SMTP id CG73bZmja8RcDCG7Pbkjts; Mon, 13 Jun 2016 00:52:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465779163; bh=0Zv3FC74mKut+eT7t5RgCrDxstqAaNHHiwNNnuGwOoY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=qWE2pUNFR/KzODnipUh7ieK2hmIbgsEDtwre/KoiNVamObSZPdK4ylmrcEIUNpwqN 7uZJtQidWpe31j7h8insL4VNgN4FVpEUY5loTZPukXyN7CqyihwpoA1n1Wlc1lEspl lVtf4U5fyZQJTPbv+zc3YnFbyPR2fjrB9+B13O7rtpFh6uRltb1NR+Buqc0slnrT6F 8nBQ2J4RCmOg9tvcAlYVM653FSl/5N9fDItbKZ4mmOtHkCEgh3C3GwXqcf/Z1U3cWA fowqufQs4angspsXZ04NaElBdAXxUM1OLTNAQNN0Rn+qRfgtQS/ID3KeG3vGPOfB5g T/vsDngFye/oQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id 60si1t00T1nMCLR010sjls; Mon, 13 Jun 2016 00:52:43 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5D0qg7r029425; Sun, 12 Jun 2016 20:52:42 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5D0qfkB029422; Sun, 12 Jun 2016 20:52:41 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Jernej Tuljak" In-Reply-To: <023801d1c2f4$8268cc90$873a65b0$@mg-soft.si> (jernej.tuljak@mg-soft.si) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 12 Jun 2016 20:52:41 -0400 Message-ID: <87shwhzz8m.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Tokenizing and strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 00:52:47 -0000 "Jernej Tuljak" writes: > You are also forgetting the fact that the existing 'string' production > expects an "unquoted string as returned by the scanner" (no quotes, > no concats, no pretty printing whitespace). I must admit I've never understood what that bit of the text means. Dale From nobody Sun Jun 12 18:27:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8120012D127 for ; Sun, 12 Jun 2016 18:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.766 X-Spam-Level: X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 pzrbnYCG7BgH for ; Sun, 12 Jun 2016 18:27:48 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 827BB12D0AA for ; Sun, 12 Jun 2016 18:27:46 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-04v.sys.comcast.net with SMTP id CGeJbZonE8RcDCGfJbkobF; Mon, 13 Jun 2016 01:27:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465781265; bh=Rn4MVEThPOR+sqAZCCj/prxwTRJgBWZ/xCK9EfeSiwk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=nze8QD7oTkGwUIR1osvTwvattj0Xz2FL+0tU62u0IuDkWfohGdMc/haaCaQeGNEfP zRNjuWMr+fbBZ9FNItFuaLd/w15W5NhD1yKBsmdplzOp4JEvPAG0df8NTZevGFb0ay IpRAljm76JQzMH5n1wo/KXLrYTLzvNnNGhae9uPfe/5kiuFdagQGMuo3F7Lm34Gllr 6E4hcrRwLb37MjPtWlgq1l+002zIt5LRX8fOHDWH7rTvCrNTrt7w+w7Oe2HxTtm7Hh vYUt2Nc7aQQMq2QI9NJwFgiW3cBha4d+0fmrOZ9deDb7eI23kIyuiM7HwET6ZlN2r1 Y0iMIHAYIV3mw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-13v.sys.comcast.net with comcast id 61Tk1t00N1nMCLR011TlQm; Mon, 13 Jun 2016 01:27:45 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5D1Rj3N000604 for ; Sun, 12 Jun 2016 21:27:45 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5D1Riue000597; Sun, 12 Jun 2016 21:27:44 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org In-Reply-To: (ichen@kuatrotech.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 12 Jun 2016 21:27:44 -0400 Message-ID: <87fushzxm7.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [netmod] update on "rdns" URN for enterprise YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 01:27:49 -0000 When I see a requirement for globally unique names, I always think fondly of the "oid" series of URNs, which are based on the ITU object identifiers. See RFC 3001. You write to IANA to get an assignment of a "private enterprise number", which you can use to coin object identifiers which are guaranteed to be unique. For instance, I've been assigned OID 1.3.6.1.4.1.14490. So I can use urn:oid:1.3.6.1.4.1.14490.1, urn:oid:1.3.6.1.4.1.14490.2, urn:oid:1.3.6.1.4.1.14490.3, etc., and be assured that they're globally unique. (If you want a subtree to experiment with, I can allocate on to you!) Sadly, nobody else seems to be taken with the extreme elegance of the OID system. Dale From nobody Sun Jun 12 19:14:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE1012B00D for ; Sun, 12 Jun 2016 19:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 XN7OkmUOXhjm for ; Sun, 12 Jun 2016 19:14:18 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 9F86C12D53A for ; Sun, 12 Jun 2016 19:14:18 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-07v.sys.comcast.net with SMTP id CHNYbxxYLrtfLCHOLbVWj8; Mon, 13 Jun 2016 02:14:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465784057; bh=cWq4q6lGkcVFoE0mip/tbDvaSvRMiZWMha72+/qNG3E=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Ef8MWqQg/SRY9hKqxJozdjYTp4kci5VjGa2L/+rP7bSq/VNlSYcT7c8OkqzEfQuRI 6Rlhnipxcj7yR8Qg7cFvMncJ461yRjVami4dIyIXzPkMRoN2sFiXgnD1zKEEZSlbck Yqf0mRbMPYdbwJph32BGcJb8lht0svkoBEUn5HUN9JZgDm1aG8pLJKVgTIqldIeeiC zuBA3Nd4LGBZzUAJy4fwR4C5Dkxtvqg2g6xppSt2W+P7mhyYvvxqdisoYXkYpVM+fU klQ+zW7XKYCl8Pwv2G2txIrPPzgc39kPc2YPN09uIgJWFIabSW8ZbKWdh4pHbgxhjM /bQ6js1nWsFig== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-12v.sys.comcast.net with comcast id 62EH1t0051nMCLR012EHyC; Mon, 13 Jun 2016 02:14:17 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5D2EIBb005859 for ; Sun, 12 Jun 2016 22:14:18 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5D2EHLI005856; Sun, 12 Jun 2016 22:14:17 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 12 Jun 2016 22:14:17 -0400 Message-ID: <874m8xzvgm.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [netmod] The Restconf root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 02:14:20 -0000 Looking at draft-ietf-netconf-restconf-13, it looks like the RFC 7320 mechanism is used to find the root URL, from which all the Restconf URLs are derived by appending path components as specified in the draft. But looking at RFC 6570, which is referenced by both 7320 and the draft, it seems like appending path components to a configured base URL is no longer best practice, because it requires the HTTP server to be able to connect all those URLs to the Restconf server despite their different paths. It seems like the new, improved method is for a URL template to be advertised, and the Restconf client should use the template and the Restconf specification to construct the URL to be used. E.g., now, the example in section 3.1 shows how the Restconf root is obtained: Request ------- GET /.well-known/host-meta HTTP/1.1 Host: example.com Accept: application/xrd+xml Response -------- HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn and used, with the sub-URL "operations": Request ------- GET /top/restconf/operations HTTP/1.1 Host: example.com Accept: application/yang.api+json RFC 6570 seems to suggest that the first lookup should return a URL template: Request ------- GET /.well-known/host-meta HTTP/1.1 Host: example.com Accept: application/xrd+xml Response -------- HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn The value of this being that a different server might return the template 'http://example.com{?resource}', causing the second request to use the URL 'http://example.com?resource=operations'. Although this probably requires a redefinition of the href attribute of the Link element. Dale From nobody Sun Jun 12 23:34:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAD4128E19 for ; Sun, 12 Jun 2016 23:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 9jrX4GedpJDT for ; Sun, 12 Jun 2016 23:34:31 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6886127078 for ; Sun, 12 Jun 2016 23:34:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 363638EE; Mon, 13 Jun 2016 08:34:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7DNpWJqoCgX1; Mon, 13 Jun 2016 08:34:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 13 Jun 2016 08:34:27 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2EEA2004E; Mon, 13 Jun 2016 08:34:27 +0200 (CEST) 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 x-VnZsk4TJtN; Mon, 13 Jun 2016 08:34:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C8B120047; Mon, 13 Jun 2016 08:34:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8792E3B1DB75; Mon, 13 Jun 2016 08:34:25 +0200 (CEST) Date: Mon, 13 Jun 2016 08:34:25 +0200 From: Juergen Schoenwaelder To: "Dale R. Worley" Message-ID: <20160613063425.GA20531@elstar.local> Mail-Followup-To: "Dale R. Worley" , netmod@ietf.org References: <874m8xzvgm.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874m8xzvgm.fsf@hobgoblin.ariadne.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] The Restconf root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 06:34:33 -0000 Hi, this comment seems to be long to NETCONF and not NETMOD. /js On Sun, Jun 12, 2016 at 10:14:17PM -0400, Dale R. Worley wrote: > Looking at draft-ietf-netconf-restconf-13, it looks like the RFC 7320 > mechanism is used to find the root URL, from which all the Restconf URLs > are derived by appending path components as specified in the draft. > > But looking at RFC 6570, which is referenced by both 7320 and the draft, > it seems like appending path components to a configured base URL is no > longer best practice, because it requires the HTTP server to be able to > connect all those URLs to the Restconf server despite their different > paths. It seems like the new, improved method is for a URL template to > be advertised, and the Restconf client should use the template and the > Restconf specification to construct the URL to be used. > > E.g., now, the example in section 3.1 shows how the Restconf root is > obtained: > > Request > ------- > GET /.well-known/host-meta HTTP/1.1 > Host: example.com > Accept: application/xrd+xml > > Response > -------- > HTTP/1.1 200 OK > Content-Type: application/xrd+xml > Content-Length: nnn > > > > > > and used, with the sub-URL "operations": > > Request > ------- > GET /top/restconf/operations HTTP/1.1 > Host: example.com > Accept: application/yang.api+json > > RFC 6570 seems to suggest that the first lookup should return a URL > template: > > Request > ------- > GET /.well-known/host-meta HTTP/1.1 > Host: example.com > Accept: application/xrd+xml > > Response > -------- > HTTP/1.1 200 OK > Content-Type: application/xrd+xml > Content-Length: nnn > > > > > > The value of this being that a different server might return the > template 'http://example.com{?resource}', causing the second request to > use the URL 'http://example.com?resource=operations'. > > Although this probably requires a redefinition of the href attribute of > the Link element. > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 13 05:42:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2235C12D635 for ; Mon, 13 Jun 2016 05:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9t0lbARXIGU for ; Mon, 13 Jun 2016 05:42:17 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE3912D0C0 for ; Mon, 13 Jun 2016 05:42:16 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 907A51CC02A9; Mon, 13 Jun 2016 14:42:19 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 13 Jun 2016 14:42:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 12:42:19 -0000 Andy Bierman writes: > Hi, > > I am trying to implement YANG 1.1 must-stmt extensions. > They appear to be under-specified. > > In sec. 7.5.3 > > The XPath expression is conceptually evaluated in the following > context, in addition to the definition in Section 6.4.1 > : > > o The context node is the node in the accessible tree for which the > "must" statement is defined. > > > The problem for input/output is that these nodes are not encoded > in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines the > XPath context for input and output, so 7.5.3 is incorrect. > > 7.5.3 should say the context node for input/output is the node representing > the RPC operation. This would be the same for NETCONF encoding of action. > The RESTCONF encoding for RPC and action is completely different > but the definition in 7.5.3 is actually correct for RESTCONF. This should not depend on any encoding, an XPath expression is evaluated on a conceptual data tree, and this tree is defined for operations, too. > > > The problem for notification is not that is not in the > instance document, but rather that it is not part of the XPath context: > > o If the XPath expression is defined in a substatement to a > "notification" statement, the accessible tree is the notification > instance, all state data in the server, and the running > configuration datastore. * If the notification is defined on the > top-level in a module, then the root node has the node > representing the notification being defined* and all top-level data > nodes in all modules as children. Otherwise, the root node has > all top-level data nodes in all modules as children. > This is indeed quite incomprehensible. What's the idea here? Lada > > The context node for should be the node representing the > notification. > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jun 13 07:39:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB0112D1E4 for ; Mon, 13 Jun 2016 07:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPjCaSK4kKTr for ; Mon, 13 Jun 2016 07:39:06 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d: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 7689212B051 for ; Mon, 13 Jun 2016 07:39:06 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id p10so39901749qke.3 for ; Mon, 13 Jun 2016 07:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7qS6qSCoXsYpvSGaocPnwXNXSNvKlwbQVfoTYPFBup8=; b=hZWk1nNv1MWjk0nrdxnmageQcrOFA1OKRpTXr4B9TfiduyC+KkN8zDd4M5MJvd37u5 syjj9adENXSSWOzJbUnaOiOvxHP4vDhKJUmx5R5suhp4kZkb8NhjOP5jmgwAlrC3p64z HqfgyBEn6/NN8mH9tIF5k0P05clLaA+x5l960EP9hO+geMuHw1be9EdhjRYLRpswRhXD z0HwNCqgP2j3WkBAueHxWGPDMdWOLskMGYoyoYKysXxgR7kgwk+hVKydvcLvwaoTOqmn EhugadHNy5QMqvY13JRa33RwKSdpz31dMgeaJD6NlAnoW5xeCrXjPH/+DvKa4qB0VbZp 1Q7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7qS6qSCoXsYpvSGaocPnwXNXSNvKlwbQVfoTYPFBup8=; b=OVtf1RtjCb0MmuA4ZDkWCxcEFGe0ECh07kFqrUwy/Wn+ETZsgFDqAJ6Mr/cS5hyDXa /ZTpWddj2pSipv00OzkldGNWRll5NXwzQetoMiQ1WgD8xKva0lMuTGhRf7l4Hvxq4H+N yDx10qxYAG0IdmaRsjzpZuYKlaQcmv7IjJleJ0gQ2oky99XT4bR48SocVRoAWhihP6OY C4xOYNHBl8WIazWXvC2QVRtjANanxKSJBWMLlkAB+3UU6X9pLNsxqRwHWgMhcmOaC3ut TIKvD/6yHN88n7hGIMdyaGFNFotg1gUpvuDfQsKG3y85hVrshgA9qGp4T9oJU1Y05bvx ZV2w== X-Gm-Message-State: ALyK8tIZ7B/ZIvfqDMc6UUcnjpy2efOx034T72M+1P01q7Fu0djrsV/k2Eyx7/IvABZQBa+f1jySYjei1D5CGQ== MIME-Version: 1.0 X-Received: by 10.55.26.94 with SMTP id a91mr15236299qka.26.1465828745566; Mon, 13 Jun 2016 07:39:05 -0700 (PDT) Received: by 10.200.56.16 with HTTP; Mon, 13 Jun 2016 07:39:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 13 Jun 2016 07:39:05 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1146eb62ae7cda053529d936 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 14:39:09 -0000 --001a1146eb62ae7cda053529d936 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > Hi, > > > > I am trying to implement YANG 1.1 must-stmt extensions. > > They appear to be under-specified. > > > > In sec. 7.5.3 > > > > The XPath expression is conceptually evaluated in the following > > context, in addition to the definition in Section 6.4.1 > > < > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-13#section-6.4.1 > >: > > > > o The context node is the node in the accessible tree for which the > > "must" statement is defined. > > > > > > The problem for input/output is that these nodes are not encoded > > in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines the > > XPath context for input and output, so 7.5.3 is incorrect. > > > > 7.5.3 should say the context node for input/output is the node > representing > > the RPC operation. This would be the same for NETCONF encoding of action. > > The RESTCONF encoding for RPC and action is completely different > > but the definition in 7.5.3 is actually correct for RESTCONF. > > This should not depend on any encoding, an XPath expression is evaluated > on a conceptual data tree, and this tree is defined for operations, too. > > The and nodes do not appear at all in the instance document for NETCONF so this bullet in 7.5.3 is wrong for those nodes. For , the child of is already specified as the child of docroot. > > > > > > The problem for notification is not that is not in the > > instance document, but rather that it is not part of the XPath context: > > > > o If the XPath expression is defined in a substatement to a > > "notification" statement, the accessible tree is the notification > > instance, all state data in the server, and the running > > configuration datastore. * If the notification is defined on the > > top-level in a module, then the root node has the node > > representing the notification being defined* and all top-level data > > nodes in all modules as children. Otherwise, the root node has > > all top-level data nodes in all modules as children. > > > > This is indeed quite incomprehensible. What's the idea here? > > Lada > > Andy > > > > The context node for should be the node representing the > > notification. > > > > > > > > Andy > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a1146eb62ae7cda053529d936 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> Hi,
>
> I am trying to implement YANG 1.1 must-stmt extensions.
> They appear to be under-specified.
>
> In sec. 7.5.3
>
>=C2=A0 =C2=A0 The XPath expression is conceptually evaluated in the fol= lowing
>=C2=A0 =C2=A0 context, in addition to the definition in Section 6.4.1 > <https://tools.ietf= .org/html/draft-ietf-netmod-rfc6020bis-13#section-6.4.1>:
>
>=C2=A0 =C2=A0 o=C2=A0 The context node is the node in the accessible tr= ee for which the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"must" statement is defined.
>
>
> The problem for input/output is that these nodes are not encoded
> in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines th= e
> XPath context for input and output, so 7.5.3 is incorrect.
>
> 7.5.3 should say the context node for input/output is the node represe= nting
> the RPC operation. This would be the same for NETCONF encoding of acti= on.
> The RESTCONF encoding for RPC and action is completely different
> but the definition in 7.5.3 is actually correct for RESTCONF.

This should not depend on any encoding, an XPath expression is evaluated on a conceptual data tree, and this tree is defined for operations, too.


The <input> and &= lt;output> nodes do not appear at all
in the instance document= for NETCONF so this bullet in 7.5.3 is wrong
for those nodes.

For <notiofication>, the child of <notifica= tion> is already specified
as the child of docroot.
=
=C2=A0
>
>
> The problem for notification is not that <notification> is not i= n the
> instance document, but rather that it is not part of the XPath context= :
>
>=C2=A0 =C2=A0 o=C2=A0 If the XPath expression is defined in a substatem= ent to a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"notification" statement, the acce= ssible tree is the notification
>=C2=A0 =C2=A0 =C2=A0 =C2=A0instance, all state data in the server, and = the running
>=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration datastore. * If the notificati= on is defined on the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0top-level in a module, then the root node ha= s the node
>=C2=A0 =C2=A0 =C2=A0 =C2=A0representing the notification being defined*= and all top-level data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0nodes in all modules as children.=C2=A0 Othe= rwise, the root node has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0all top-level data nodes in all modules as c= hildren.
>

This is indeed quite incomprehensible. What's the idea here?

Lada



Andy
=C2=A0
>
> The context node for <notification> should be the node represent= ing the
> notification.
>
>
>
> Andy
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--001a1146eb62ae7cda053529d936-- From nobody Mon Jun 13 08:30:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C93F12D805 for ; Mon, 13 Jun 2016 08:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 rH9pWke3tQTn for ; Mon, 13 Jun 2016 08:30:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2C712D800 for ; Mon, 13 Jun 2016 08:30:37 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:48e:b278:ca88:3eca] (unknown [IPv6:2a01:5e0:29:ffff:48e:b278:ca88:3eca]) by mail.nic.cz (Postfix) with ESMTPSA id DF5BF6111D; Mon, 13 Jun 2016 17:30:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1465831834; bh=TE+Gv9uEwGvZzSu4N+/Ah5KLLIQ//Th/mvmCJaURYA0=; h=From:Date:To; b=jyhxqlFFGzzFCRIst9B7HA3rDurqlxY72m1Hmj2MjX5gYvwtUls4svNR+0vUqSeky fCCw0mdjl0l7RvWzR87bH5W+wsErnjpsKiSYBlFRYJq/+Xmp7CuosjA3aWMP/Z2jiI ENOFuyUr8p61ne8y3zV8YdkpOzf0x/T/3NfQgNRA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 13 Jun 2016 17:30:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 15:30:40 -0000 > On 13 Jun 2016, at 16:39, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > Hi, > > > > I am trying to implement YANG 1.1 must-stmt extensions. > > They appear to be under-specified. > > > > In sec. 7.5.3 > > > > The XPath expression is conceptually evaluated in the following > > context, in addition to the definition in Section 6.4.1 > > = : > > > > o The context node is the node in the accessible tree for which = the > > "must" statement is defined. > > > > > > The problem for input/output is that these nodes are not encoded > > in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines = the > > XPath context for input and output, so 7.5.3 is incorrect. > > > > 7.5.3 should say the context node for input/output is the node = representing > > the RPC operation. This would be the same for NETCONF encoding of = action. > > The RESTCONF encoding for RPC and action is completely different > > but the definition in 7.5.3 is actually correct for RESTCONF. >=20 > This should not depend on any encoding, an XPath expression is = evaluated > on a conceptual data tree, and this tree is defined for operations, = too. >=20 >=20 >=20 > The and nodes do not appear at all > in the instance document for NETCONF so this bullet in 7.5.3 is wrong > for those nodes. >=20 > For , the child of is already specified > as the child of docroot. OK, so this is about "must" statements specified directly under = input/output and notification statements, right? I had the same comment = previously: https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html My understanding is that in the former case the context node is the root = of the input/output data tree, and in the latter case it is the node = with the same name as the notification. I agree it should be better explained. Lada =20 >=20 > =20 > > > > > > The problem for notification is not that is not in = the > > instance document, but rather that it is not part of the XPath = context: > > > > o If the XPath expression is defined in a substatement to a > > "notification" statement, the accessible tree is the = notification > > instance, all state data in the server, and the running > > configuration datastore. * If the notification is defined on = the > > top-level in a module, then the root node has the node > > representing the notification being defined* and all top-level = data > > nodes in all modules as children. Otherwise, the root node = has > > all top-level data nodes in all modules as children. > > >=20 > This is indeed quite incomprehensible. What's the idea here? >=20 > Lada >=20 >=20 >=20 > Andy > =20 > > > > The context node for should be the node representing = the > > notification. > > > > > > > > Andy > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jun 13 08:55:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A058E12D84B for ; Mon, 13 Jun 2016 08:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 plAvibmXlaZT for ; Mon, 13 Jun 2016 08:54:59 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207: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 522D512D84A for ; Mon, 13 Jun 2016 08:54:59 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-05v.sys.comcast.net with SMTP id CUCJbcLPy8JCNCUCYbGWgA; Mon, 13 Jun 2016 15:54:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465833298; bh=2W2OYtha/AkmI2dOswBkMriUV4rpV8fk49esYsAIUds=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=DyIf/dsKUe4STPzCos86U9XVQ/Cd0O8pQBGlzML3i6jpzESGAFiAyli+eKlLK066e 41G3A2R7Fm889l+c8XaRJNCPCpADyYWT+i0KPMWRvuhqGu5Kn0wNm0fw7jimY7hx3T tGLZ2/LnBLf9wCt3xACTmSBu+42x2XZ4KYThrTYG5gUb5R5Dkb9yhbzLNpAY1eXajX mT3+pNVbM7VsboDNHu7K4NOsDfguNyntT3D+lThCF7at71vjcSaGEI3HKdv5zqCNQW ulULPWd5MhjSZWMOGbwe6J0uMEfCzP3+NMK1pr+ZVNoXzON21AadDZzUobTHoiZvqm +EV6VCRIiBOrA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-13v.sys.comcast.net with comcast id 6Fux1t0021nMCLR01Fux4T; Mon, 13 Jun 2016 15:54:58 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5DFsu7X025594; Mon, 13 Jun 2016 11:54:56 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5DFstp7025590; Mon, 13 Jun 2016 11:54:55 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Juergen Schoenwaelder In-Reply-To: <20160610073529.GA15538@elstar.local> (j.schoenwaelder@jacobs-university.de) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 13 Jun 2016 11:54:55 -0400 Message-ID: <87h9cxxewg.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Tokenizing and strings (was: Gen-ART IETF Last Call review of draft-ietf-netmod-rfc6020bis-12 (part 2)) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 15:55:00 -0000 Juergen Schoenwaelder writes: > I think we should consider this for a future version of YANG but not > now. I am not aware what implementors had problems to implement YANG > strings in YANG 1 or YANG 1.1 and we are at a point in the process > where I like to not run the risk to make bigger changes to the > specification that may turn out to introduce incompabilities. I've written an issue about it (https://github.com/netmod-wg/yang-next/issues/6), so it can be considered for the next revision. Dale From nobody Mon Jun 13 09:22:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5101F12D858 for ; Mon, 13 Jun 2016 09:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 o96UlSi4lhkq for ; Mon, 13 Jun 2016 09:21:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A76112D5D5 for ; Mon, 13 Jun 2016 09:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7yNXMSiLxYZk5WYGHZc8LHYiBlBWxnGxD3tbbAHTGDM=; b=N0OjGtqcSPjG0ZYVAopAq9WUwJt+vCsUJmfeZYZzIvT4qjXXWItia14kvZ/IvPqC7uGUM07n+Qcdy/PjBJmo8wpl/mnJfAx3stZ6qC6U3Y/j42oUubcMlir1hNLMz34B0Uro7uRGb8lA53Nbyo+NsL3GmJ3bsd41KXr4+T5PDsA= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.517.8; Mon, 13 Jun 2016 16:21:38 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0517.009; Mon, 13 Jun 2016 16:21:37 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Dale R. Worley" Thread-Topic: [netmod] The Restconf root Thread-Index: AQHRxRlP44R7rwxBiU6Oun6aaWNAcJ/m8Q6AgABhAQA= Date: Mon, 13 Jun 2016 16:21:37 +0000 Message-ID: <37560F6C-FD8F-462B-92A6-1071CFA277A9@juniper.net> References: <874m8xzvgm.fsf@hobgoblin.ariadne.com> <20160613063425.GA20531@elstar.local> In-Reply-To: <20160613063425.GA20531@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 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: facf24b0-80c8-4692-da61-08d393a6cb87 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:Hj/i5GXpXMYdqu/tdOklJDiMmYDc2BtgPS/ocAWaOX2vCx3bcUJdyIcPyKYuDdnEzq8ZwCV/STS9AFfHgPa2zPY1Dz3uLAjGvzOXSaYucCNLy6lMTPw8d5bur1OY8Pnh1PTG126C2TA1Ey/wwwCxzA5VtjY8zwiI4ocC/CvsUZ70MFO8D3iXlEcUC6pBl/y1HoGG5g3ljtC9iehmT1t863Zej0Nmh/Fm53rNq7exkBSOQKWe+KcdHVq6Qt+igywJdJSWAw4O5/a04Yj43BGdn882OiCtIdTpEDr1e0f1+Mea9jaFiFAqEWQjwf/swbeG; 5:MU6uWbssX7B+YgptB/gLFzqwjdZsOPwnetaDIO/XpNzh9kQr5FgGrVTjB7AglwLMQzRRHiHvE8c6kHeBsOF9xQpIgoSEybKNh0SIYAPYmcjEuM+800oqGrbEHe0dlHRxbm/aRPzB5Iv8fcYmmhmSnw==; 24:SV6sQSa88T3Hu3N8u7a9JN/G96xdQWonNggvCbTzpNZxvUJnWD82fzOYv/TX11lsEChNnv/3H1vew2KTSJ6P+KXJD2B9lGdEB2svKv4o0rk=; 7:Dec3LH/aguGJH+q0v9v1zdHxgSMLbGXTvmSorxUFbX+AzSI8hjZv4tjGIHTQ8G4wJ5Jnyx1kpTPczlT7tWowRXK3DF3roQHxUBw4CWW+YLY3JlTkt6vuyIscMr2nLB5QtBOXUIFz0Ff9/Qp8Uf9NCc/WCnpdVIQjQcBhTpEhkcoWVsIAc4bVn30PVVtXa/zFqTFpNvjKSIqP+iunTY850w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(38170694233816)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(24454002)(377454003)(66066001)(102836003)(3280700002)(3846002)(6116002)(31430400001)(106116001)(3660700001)(68736007)(81156014)(8676002)(101416001)(106356001)(5001770100001)(50986999)(83506001)(122556002)(4326007)(7906002)(81166006)(15975445007)(77096005)(92566002)(19617315012)(586003)(10400500002)(2900100001)(8936002)(5008740100001)(86362001)(36756003)(99286002)(2950100001)(83716003)(2906002)(15395725005)(87936001)(4001350100001)(33656002)(76176999)(54356999)(105586002)(5004730100002)(97736004)(82746002)(5002640100001)(19580395003)(189998001)(19580405001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; 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: <1734F69C5BC84E449FFF3BE5FDB1537D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 16:21:37.7303 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] The Restconf root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 16:21:58 -0000 DQpZZXMsIHBsZWFzZSByZS1wb3N0IHRvIHRoZSBuZXRjb25mIE1MLg0KDQpBbHNvLCB0aG91Z2gg bm90IHlvdXIgcHJpbWFyeSBwb2ludCwgeW91IG1pc3F1b3RlZCB0aGUgZXhhbXBsZS4gIFRoZSAy bmQgZXhhbXBsZSBpbiBTZWN0aW9uIDMuMSByZXR1cm5zIOKAnC90b3AvcmVzdGNvbmbigJ0gKG5v dCDigJwvcmVzdGNvbmbigJ0pLCB3aGljaCBpcyBjb25zaXN0ZW50IHdpdGggaXQgc3Vic2VxdWVu dCB1c2UtZXhhbXBsZSBxdW90ZWQgYmVsb3cuDQoNCktlbnQNCg0KDQpPbiA2LzEzLzE2LCAyOjM0 IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIiIDxuZXRtb2Qt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPiB3cm90ZToNCg0KPkhpLA0KPg0KPnRoaXMgY29tbWVudCBzZWVtcyB0byBiZSBs b25nIHRvIE5FVENPTkYgYW5kIG5vdCBORVRNT0QuDQo+DQo+L2pzDQo+DQo+T24gU3VuLCBKdW4g MTIsIDIwMTYgYXQgMTA6MTQ6MTdQTSAtMDQwMCwgRGFsZSBSLiBXb3JsZXkgd3JvdGU6DQo+PiBM b29raW5nIGF0IGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi0xMywgaXQgbG9va3MgbGlrZSB0 aGUgUkZDIDczMjANCj4+IG1lY2hhbmlzbSBpcyB1c2VkIHRvIGZpbmQgdGhlIHJvb3QgVVJMLCBm cm9tIHdoaWNoIGFsbCB0aGUgUmVzdGNvbmYgVVJMcw0KPj4gYXJlIGRlcml2ZWQgYnkgYXBwZW5k aW5nIHBhdGggY29tcG9uZW50cyBhcyBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0Lg0KPj4gDQo+PiBC dXQgbG9va2luZyBhdCBSRkMgNjU3MCwgd2hpY2ggaXMgcmVmZXJlbmNlZCBieSBib3RoIDczMjAg YW5kIHRoZSBkcmFmdCwNCj4+IGl0IHNlZW1zIGxpa2UgYXBwZW5kaW5nIHBhdGggY29tcG9uZW50 cyB0byBhIGNvbmZpZ3VyZWQgYmFzZSBVUkwgaXMgbm8NCj4+IGxvbmdlciBiZXN0IHByYWN0aWNl LCBiZWNhdXNlIGl0IHJlcXVpcmVzIHRoZSBIVFRQIHNlcnZlciB0byBiZSBhYmxlIHRvDQo+PiBj b25uZWN0IGFsbCB0aG9zZSBVUkxzIHRvIHRoZSBSZXN0Y29uZiBzZXJ2ZXIgZGVzcGl0ZSB0aGVp ciBkaWZmZXJlbnQNCj4+IHBhdGhzLiAgSXQgc2VlbXMgbGlrZSB0aGUgbmV3LCBpbXByb3ZlZCBt ZXRob2QgaXMgZm9yIGEgVVJMIHRlbXBsYXRlIHRvDQo+PiBiZSBhZHZlcnRpc2VkLCBhbmQgdGhl IFJlc3Rjb25mIGNsaWVudCBzaG91bGQgdXNlIHRoZSB0ZW1wbGF0ZSBhbmQgdGhlDQo+PiBSZXN0 Y29uZiBzcGVjaWZpY2F0aW9uIHRvIGNvbnN0cnVjdCB0aGUgVVJMIHRvIGJlIHVzZWQuDQo+PiAN Cj4+IEUuZy4sIG5vdywgdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiAzLjEgc2hvd3MgaG93IHRoZSBS ZXN0Y29uZiByb290IGlzDQo+PiBvYnRhaW5lZDoNCj4+IA0KPj4gICAgICAgUmVxdWVzdA0KPj4g ICAgICAgLS0tLS0tLQ0KPj4gICAgICAgR0VUIC8ud2VsbC1rbm93bi9ob3N0LW1ldGEgSFRUUC8x LjENCj4+ICAgICAgIEhvc3Q6IGV4YW1wbGUuY29tDQo+PiAgICAgICBBY2NlcHQ6IGFwcGxpY2F0 aW9uL3hyZCt4bWwNCj4+IA0KPj4gICAgICAgUmVzcG9uc2UNCj4+ICAgICAgIC0tLS0tLS0tDQo+ PiAgICAgICBIVFRQLzEuMSAyMDAgT0sNCj4+ICAgICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRp b24veHJkK3htbA0KPj4gICAgICAgQ29udGVudC1MZW5ndGg6IG5ubg0KPj4gDQo+PiAgICAgICA8 WFJEIHhtbG5zPSdodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy9ucy94cmkveHJkLTEuMCc+DQo+ PiAgICAgICAgICAgPExpbmsgcmVsPSdyZXN0Y29uZicgaHJlZj0nL3Jlc3Rjb25mJy8+DQo+PiAg ICAgICA8L1hSRD4NCj4+IA0KPj4gYW5kIHVzZWQsIHdpdGggdGhlIHN1Yi1VUkwgIm9wZXJhdGlv bnMiOg0KPj4gDQo+PiAgICAgICBSZXF1ZXN0DQo+PiAgICAgICAtLS0tLS0tDQo+PiAgICAgICBH RVQgL3RvcC9yZXN0Y29uZi9vcGVyYXRpb25zICBIVFRQLzEuMQ0KPj4gICAgICAgSG9zdDogZXhh bXBsZS5jb20NCj4+ICAgICAgIEFjY2VwdDogYXBwbGljYXRpb24veWFuZy5hcGkranNvbg0KPj4g DQo+PiBSRkMgNjU3MCBzZWVtcyB0byBzdWdnZXN0IHRoYXQgdGhlIGZpcnN0IGxvb2t1cCBzaG91 bGQgcmV0dXJuIGEgVVJMDQo+PiB0ZW1wbGF0ZToNCj4+IA0KPj4gICAgICAgUmVxdWVzdA0KPj4g ICAgICAgLS0tLS0tLQ0KPj4gICAgICAgR0VUIC8ud2VsbC1rbm93bi9ob3N0LW1ldGEgSFRUUC8x LjENCj4+ICAgICAgIEhvc3Q6IGV4YW1wbGUuY29tDQo+PiAgICAgICBBY2NlcHQ6IGFwcGxpY2F0 aW9uL3hyZCt4bWwNCj4+IA0KPj4gICAgICAgUmVzcG9uc2UNCj4+ICAgICAgIC0tLS0tLS0tDQo+ PiAgICAgICBIVFRQLzEuMSAyMDAgT0sNCj4+ICAgICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRp b24veHJkK3htbA0KPj4gICAgICAgQ29udGVudC1MZW5ndGg6IG5ubg0KPj4gDQo+PiAgICAgICA8 WFJEIHhtbG5zPSdodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9yZy9ucy94cmkveHJkLTEuMCc+DQo+ PiAgICAgICAgICAgPExpbmsgcmVsPSdyZXN0Y29uZicgaHJlZj0naHR0cDovL2V4YW1wbGUuY29t L3tyZXNvdXJjZX0nLz4NCj4+ICAgICAgIDwvWFJEPg0KPj4gDQo+PiBUaGUgdmFsdWUgb2YgdGhp cyBiZWluZyB0aGF0IGEgZGlmZmVyZW50IHNlcnZlciBtaWdodCByZXR1cm4gdGhlDQo+PiB0ZW1w bGF0ZSAnaHR0cDovL2V4YW1wbGUuY29tez9yZXNvdXJjZX0nLCBjYXVzaW5nIHRoZSBzZWNvbmQg cmVxdWVzdCB0bw0KPj4gdXNlIHRoZSBVUkwgJ2h0dHA6Ly9leGFtcGxlLmNvbT9yZXNvdXJjZT1v cGVyYXRpb25zJy4NCj4+IA0KPj4gQWx0aG91Z2ggdGhpcyBwcm9iYWJseSByZXF1aXJlcyBhIHJl ZGVmaW5pdGlvbiBvZiB0aGUgaHJlZiBhdHRyaWJ1dGUgb2YNCj4+IHRoZSBMaW5rIGVsZW1lbnQu DQo+PiANCj4+IERhbGUNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCj4t LSANCj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy ZW1lbiBnR21iSA0KPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcg MSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj5GYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAg ICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QN Cj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldG1vZA0KDQo= From nobody Mon Jun 13 10:11:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296A912D8B9 for ; Mon, 13 Jun 2016 10:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=randy_presuhn@mindspring.com header.d=mindspring.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 9WmCw1x9omp3 for ; Mon, 13 Jun 2016 10:11:22 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id E202612D8B4 for ; Mon, 13 Jun 2016 10:11:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=WzOvSDEXwK/fGfbpKh3CL/2LgYjZXyqh0nxVeFML3ZlPHKm8BA5UF+hhuh0smHAp; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1bCVON-0002wF-BS for netmod@ietf.org; Mon, 13 Jun 2016 13:11:15 -0400 Received: from 76.254.49.9 by webmail.earthlink.net with HTTP; Mon, 13 Jun 2016 13:11:14 -0400 Message-ID: <22539057.1465837875344.JavaMail.wam@elwamui-milano.atl.sa.earthlink.net> Date: Mon, 13 Jun 2016 10:11:14 -0700 (GMT-07:00) From: Randy Presuhn To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b484d7840976cb7e56e17408c07e408c50d2011bd920c715350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.40 Archived-At: Subject: Re: [netmod] Tokenizing and strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:11:23 -0000 Hi - >From: "Dale R. Worley" >Sent: Jun 12, 2016 5:52 PM >To: Jernej Tuljak >Cc: netmod@ietf.org >Subject: Re: [netmod] Tokenizing and strings > >"Jernej Tuljak" writes: >> You are also forgetting the fact that the existing 'string' production >> expects an "unquoted string as returned by the scanner" (no quotes, >> no concats, no pretty printing whitespace). > >I must admit I've never understood what that bit of the text means. Likewise. Randy From nobody Mon Jun 13 10:58:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4A512D8DC for ; Mon, 13 Jun 2016 10:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 uNKUlALHloR0 for ; Mon, 13 Jun 2016 10:58:38 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 4AA3312D8DD for ; Mon, 13 Jun 2016 10:57:54 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-07v.sys.comcast.net with SMTP id CW2hbzE3OrtfLCW7VbXg8D; Mon, 13 Jun 2016 17:57:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465840673; bh=E3t0ralUfK2rW6YyH056rLZoIkhk83vimKs5kPZKvTE=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=M8CthHiv1blKqi5I1jr0buHDSmFIJqpA+SwaRdc+pWHJb9cido9u0vh0lWR01ergA raFmpeaKkW0C4rrH8JLeFaHsSlH/DvEC2XNRQD9enCy0H5lStmkHJ/Lgw8GLzRIxC9 Cek6mM43hU4cv5wWYxEnK3+dK4z4cp7nMR0mUF9fGO8ucwYYVerPnlAtrYiFXh9c+0 TWSKvBS/M+tBsa/BzNdpm3JoJurojw0D+qHcPgodck4AhZuYSLXykeciIV7t8lplYA y9SMqGv9M1u5zzI1A26knb3Kt7vZzrtmOTWgodQgFK2EBAA2nktClaNAdaBSePMlW/ Mu3LYQJUL4CEA== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-15v.sys.comcast.net with comcast id 6Hxs1t00c1nMCLR01Hxtmi; Mon, 13 Jun 2016 17:57:53 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5DHvqh9006052 for ; Mon, 13 Jun 2016 13:57:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5DHvq27006049; Mon, 13 Jun 2016 13:57:52 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 13 Jun 2016 13:57:52 -0400 Message-ID: <877fdtx97j.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [netmod] The Restconf root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:58:40 -0000 (I'm new to the Netconf mailing list, so it's possible that this issue has already been disposed of.) Looking at draft-ietf-netconf-restconf-13, it looks like the RFC 7320 mechanism is used to find the root URL, from which all the Restconf URLs are derived by appending path components as specified in the draft. But looking at RFC 6570, which is referenced by both 7320 and the draft, it seems that specifying path components to be appended a configured base URL is no longer best practice, because it requires the HTTP server to be able to connect all those URLs to the Restconf server despite their different paths. It seems that the new, improved method is to advertise a URL template, and the client should use the template and the Restconf "additional path" to construct the URL to be used. E.g., now, the second example in section 3.1 shows how the Restconf root is obtained: Request ------- GET /.well-known/host-meta HTTP/1.1 Host: example.com Accept: application/xrd+xml Response -------- HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn and used, with the sub-URL "operations": Request ------- GET /top/restconf/operations HTTP/1.1 Host: example.com Accept: application/yang.api+json RFC 6570 seems to suggest that the first lookup should return a URL template: Request ------- GET /.well-known/host-meta HTTP/1.1 Host: example.com Accept: application/xrd+xml Response -------- HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn The value of this being that a different server might return the template 'http://example.com/top/restconf{?resource}', causing the second request to use the URL 'http://example.com/top/restconf?resource=operations'. Although this probably requires a revision of the href attribute of the Link element, since it now carries a URL template rather than a URL. Dale From nobody Mon Jun 13 12:50:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96B612D60F for ; Mon, 13 Jun 2016 12:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_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 eFgcejcGX1C3 for ; Mon, 13 Jun 2016 12:50:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.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 F2BD712D0D8 for ; Mon, 13 Jun 2016 12:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P2CSZauryaAqFsvIt8kJMc6rwZWClSPOBnBcgreLtDE=; b=YlfQkKOP/M/W4CiC03nZEUhOwITJvbZ4cszQLK+lqp1+gDFJWT14KYm6eAiXUN6uaXbRtvyj+eIRgU/Ooq1+r1c5RywaJg07L4m5xapWBTeLzcHOHxZX8n7NRgpIc76xB4wW436J6YGWq2XXuOF4R+5ipA/FPhTYnsuo9xjZQt8= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (TLS) id 15.1.517.8; Mon, 13 Jun 2016 19:50:39 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0517.009; Mon, 13 Jun 2016 19:50:39 +0000 From: Kent Watsen To: "Dale R. Worley" , "netmod@ietf.org" Thread-Topic: [netmod] The Restconf root Thread-Index: AQHRxZ1C0kBX7ncE3kSA1002lJSqOp/ni2+A Date: Mon, 13 Jun 2016 19:50:39 +0000 Message-ID: References: <877fdtx97j.fsf@hobgoblin.ariadne.com> In-Reply-To: <877fdtx97j.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 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: aa8dd8be-6f5a-4d97-b0c4-08d393c3ff33 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 6:93IFCrkzXNSEoxRyrSDnfPWPVni7dc9492RoF4SqU26noqdOmn7KVrqmCrxIwrX0lF7vfpE39+QN3JfgmjwPyiEgHKydgp/TXD7j7JzT1hJMnN+sQCgA2dlxFU55Sh9daxxrs6HXZwxmJq9JREnniVb31ORoBV78Knl9tYKQztzowV8BAVXBvS7TRFsn3P0WV9SIY0rQ7uMaWml1AJuaBAj7V+NM7y8ZakLDu9Z3FrbWh+LJIGIEL/F3rlKcrQMjOS9vjQv0Gmx4rw+6tv/Nf6ih+sBdTozF8i0gmfvIWkS7UYc8KeVteF0K0MdHGsw5; 5:djqgeWFkT3enKfePhaGrVO5C1GllQS9PP+Qkz1y9Ly14S1BrgOiec2xaQlmBxR3hXjelBnjr0l2WmXVkGAlmJmx8lxNtAKJ9q5TAEyZiEx9GWPUvdO0dS6aJHRx7j6SZGGUGk5GXKqRAarB8u70YlQ==; 24:9fxpnUVJF/Ny9R0Yl+49nLI9k8yLm/veNCZYwpiyM9pb1PhhWuqZLGeMxnMMbJuO3AYaJubRJXxM3rLtOfqMyqAXwrHngSlVi8F7VfouTBw=; 7:nfMQnL+GGnTE9mZGpsAXCCCwyxpfGSCMZI5qZtXRP19lXkH3PYS4m57j91IY5Ni39Qfvpuje3thLZtI6ALkhxl/s3YJg5sjXZZv+XAPbta1j8Q5UtCMl98Tj+lSBD0RAdEuW1IMcqu5j1k7VXZgT9kR39jR6bevBWGESyNaQu4FWVKOBZ/UDlrNuaejqgWzBw7b/FjIwjyuIrjDPlKZWpg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(38170694233816)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(189002)(199003)(82746002)(11100500001)(76176999)(122556002)(36756003)(54356999)(101416001)(106356001)(87936001)(83506001)(77096005)(50986999)(92566002)(2950100001)(2501003)(107886002)(83716003)(106116001)(10400500002)(81156014)(15975445007)(86362001)(15395725005)(81166006)(8936002)(19300405004)(3660700001)(4001350100001)(5008740100001)(97736004)(2906002)(68736007)(8676002)(19580395003)(66066001)(189998001)(19580405001)(5002640100001)(33656002)(31430400001)(586003)(102836003)(6116002)(5004730100002)(105586002)(99286002)(3280700002)(19617315012)(2900100001)(3846002)(5001770100001)(7906002)(104396002)(562404015); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; 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: 13 Jun 2016 19:50:39.8084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450 Archived-At: Subject: Re: [netmod] The Restconf root X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 19:50:43 -0000 DQpJIHRoaW5rIERhbGUgYWNjaWRlbnRhbGx5IHNlbnQgdGhpcyBtZXNzYWdlIHRvIHRoZSBORVRN T0QgYWdhaW4uICANCkkganVzdCBub3cgZm9yd2FyZGVkIHRoaXMgbWVzc2FnZSB0byB0aGUgTkVU Q09ORiBsaXN0IOKAkyBwbGVhc2UgZGlzY3VzcyBpdCB0aGVyZS4NCg0KS2VudA0KDQoNCk9uIDYv MTMvMTYsIDE6NTcgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIERhbGUgUi4gV29ybGV5IiA8bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHdvcmxleUBhcmlhZG5lLmNvbT4gd3Jv dGU6DQoNCj4oSSdtIG5ldyB0byB0aGUgTmV0Y29uZiBtYWlsaW5nIGxpc3QsIHNvIGl0J3MgcG9z c2libGUgdGhhdCB0aGlzIGlzc3VlDQo+aGFzIGFscmVhZHkgYmVlbiBkaXNwb3NlZCBvZi4pDQo+ DQo+TG9va2luZyBhdCBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtMTMsIGl0IGxvb2tzIGxp a2UgdGhlIFJGQyA3MzIwDQo+bWVjaGFuaXNtIGlzIHVzZWQgdG8gZmluZCB0aGUgcm9vdCBVUkws IGZyb20gd2hpY2ggYWxsIHRoZSBSZXN0Y29uZiBVUkxzDQo+YXJlIGRlcml2ZWQgYnkgYXBwZW5k aW5nIHBhdGggY29tcG9uZW50cyBhcyBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0Lg0KPg0KPkJ1dCBs b29raW5nIGF0IFJGQyA2NTcwLCB3aGljaCBpcyByZWZlcmVuY2VkIGJ5IGJvdGggNzMyMCBhbmQg dGhlIGRyYWZ0LA0KPml0IHNlZW1zIHRoYXQgc3BlY2lmeWluZyBwYXRoIGNvbXBvbmVudHMgdG8g YmUgYXBwZW5kZWQgYSBjb25maWd1cmVkDQo+YmFzZSBVUkwgaXMgbm8gbG9uZ2VyIGJlc3QgcHJh Y3RpY2UsIGJlY2F1c2UgaXQgcmVxdWlyZXMgdGhlIEhUVFAgc2VydmVyDQo+dG8gYmUgYWJsZSB0 byBjb25uZWN0IGFsbCB0aG9zZSBVUkxzIHRvIHRoZSBSZXN0Y29uZiBzZXJ2ZXIgZGVzcGl0ZQ0K PnRoZWlyIGRpZmZlcmVudCBwYXRocy4gIEl0IHNlZW1zIHRoYXQgdGhlIG5ldywgaW1wcm92ZWQg bWV0aG9kIGlzIHRvDQo+YWR2ZXJ0aXNlIGEgVVJMIHRlbXBsYXRlLCBhbmQgdGhlIGNsaWVudCBz aG91bGQgdXNlIHRoZSB0ZW1wbGF0ZSBhbmQgdGhlDQo+UmVzdGNvbmYgImFkZGl0aW9uYWwgcGF0 aCIgdG8gY29uc3RydWN0IHRoZSBVUkwgdG8gYmUgdXNlZC4NCj4NCj5FLmcuLCBub3csIHRoZSBz ZWNvbmQgZXhhbXBsZSBpbiBzZWN0aW9uIDMuMSBzaG93cyBob3cgdGhlIFJlc3Rjb25mIHJvb3QN Cj5pcyBvYnRhaW5lZDoNCj4NCj4gICAgICBSZXF1ZXN0DQo+ICAgICAgLS0tLS0tLQ0KPiAgICAg IEdFVCAvLndlbGwta25vd24vaG9zdC1tZXRhIEhUVFAvMS4xDQo+ICAgICAgSG9zdDogZXhhbXBs ZS5jb20NCj4gICAgICBBY2NlcHQ6IGFwcGxpY2F0aW9uL3hyZCt4bWwNCj4NCj4gICAgICBSZXNw b25zZQ0KPiAgICAgIC0tLS0tLS0tDQo+ICAgICAgSFRUUC8xLjEgMjAwIE9LDQo+ICAgICAgQ29u dGVudC1UeXBlOiBhcHBsaWNhdGlvbi94cmQreG1sDQo+ICAgICAgQ29udGVudC1MZW5ndGg6IG5u bg0KPg0KPiAgICAgIDxYUkQgeG1sbnM9J2h0dHA6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL25zL3hy aS94cmQtMS4wJz4NCj4gICAgICAgICAgPExpbmsgcmVsPSdyZXN0Y29uZicgaHJlZj0nL3RvcC9y ZXN0Y29uZicvPg0KPiAgICAgIDwvWFJEPg0KPg0KPmFuZCB1c2VkLCB3aXRoIHRoZSBzdWItVVJM ICJvcGVyYXRpb25zIjoNCj4NCj4gICAgICBSZXF1ZXN0DQo+ICAgICAgLS0tLS0tLQ0KPiAgICAg IEdFVCAvdG9wL3Jlc3Rjb25mL29wZXJhdGlvbnMgIEhUVFAvMS4xDQo+ICAgICAgSG9zdDogZXhh bXBsZS5jb20NCj4gICAgICBBY2NlcHQ6IGFwcGxpY2F0aW9uL3lhbmcuYXBpK2pzb24NCj4NCj5S RkMgNjU3MCBzZWVtcyB0byBzdWdnZXN0IHRoYXQgdGhlIGZpcnN0IGxvb2t1cCBzaG91bGQgcmV0 dXJuIGEgVVJMDQo+dGVtcGxhdGU6DQo+DQo+ICAgICAgUmVxdWVzdA0KPiAgICAgIC0tLS0tLS0N Cj4gICAgICBHRVQgLy53ZWxsLWtub3duL2hvc3QtbWV0YSBIVFRQLzEuMQ0KPiAgICAgIEhvc3Q6 IGV4YW1wbGUuY29tDQo+ICAgICAgQWNjZXB0OiBhcHBsaWNhdGlvbi94cmQreG1sDQo+DQo+ICAg ICAgUmVzcG9uc2UNCj4gICAgICAtLS0tLS0tLQ0KPiAgICAgIEhUVFAvMS4xIDIwMCBPSw0KPiAg ICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veHJkK3htbA0KPiAgICAgIENvbnRlbnQtTGVu Z3RoOiBubm4NCj4NCj4gICAgICA8WFJEIHhtbG5zPSdodHRwOi8vZG9jcy5vYXNpcy1vcGVuLm9y Zy9ucy94cmkveHJkLTEuMCc+DQo+ICAgICAgICAgIDxMaW5rIHJlbD0ncmVzdGNvbmYnIGhyZWY9 J2h0dHA6Ly9leGFtcGxlLmNvbS90b3AvcmVzdGNvbmYve3Jlc291cmNlfScvPg0KPiAgICAgIDwv WFJEPg0KPg0KPlRoZSB2YWx1ZSBvZiB0aGlzIGJlaW5nIHRoYXQgYSBkaWZmZXJlbnQgc2VydmVy IG1pZ2h0IHJldHVybiB0aGUNCj50ZW1wbGF0ZSAnaHR0cDovL2V4YW1wbGUuY29tL3RvcC9yZXN0 Y29uZns/cmVzb3VyY2V9JywgY2F1c2luZyB0aGUNCj5zZWNvbmQgcmVxdWVzdCB0byB1c2UgdGhl IFVSTA0KPidodHRwOi8vZXhhbXBsZS5jb20vdG9wL3Jlc3Rjb25mP3Jlc291cmNlPW9wZXJhdGlv bnMnLg0KPg0KPkFsdGhvdWdoIHRoaXMgcHJvYmFibHkgcmVxdWlyZXMgYSByZXZpc2lvbiBvZiB0 aGUgaHJlZiBhdHRyaWJ1dGUgb2YgdGhlDQo+TGluayBlbGVtZW50LCBzaW5jZSBpdCBub3cgY2Fy cmllcyBhIFVSTCB0ZW1wbGF0ZSByYXRoZXIgdGhhbiBhIFVSTC4NCj4NCj5EYWxlDQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFp bGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Tue Jun 14 03:23:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B4C12D61F for ; Tue, 14 Jun 2016 03:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 044xTD2xn0Dy for ; Tue, 14 Jun 2016 03:23:36 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0AC12D1A2 for ; Tue, 14 Jun 2016 03:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1389; q=dns/txt; s=iport; t=1465899815; x=1467109415; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=Y9TPIn3nyaEkVLScSACdAatRRMs8ftWm9+aVyMN8sao=; b=bT2luiWORFYNOyBsb76uKhZoSJuTKYnSeCd0OZpwHGnuGfaohw1v9saj CV5erEcv6Ze71ShtheLVK71QgAfwc3djoennIXZh6/s0H/d4V+HPZf1Hg yk+fFSNsYvcMHG7GU9+Bjw6STBEbjSfNoflP1isFyyY91pnVDA8FC/FDt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQDp2V9X/xbLJq1chD+8CIF5iAAUA?= =?us-ascii?q?QEBAQEBAWUcC4R1FXYCJgJfDQgBAYgsmhGPYpExAQEIAiWBAYUmgXcIig+CWgW?= =?us-ascii?q?YY4ExjHiJRYVdj3QeNoNvO4o6AQEB?= X-IronPort-AV: E=Sophos;i="5.26,470,1459814400"; d="scan'208";a="635163786" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 10:23:33 +0000 Received: from [10.63.23.88] (dhcp-ensft1-uk-vla370-10-63-23-88.cisco.com [10.63.23.88]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5EANXvi001528 for ; Tue, 14 Jun 2016 10:23:33 GMT From: Robert Wilton To: "netmod@ietf.org" Message-ID: <7cadc53f-9a53-7303-f20e-cfcd5dea5919@cisco.com> Date: Tue, 14 Jun 2016 11:23:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Submodule import of the same module with different prefixes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 10:23:38 -0000 Hi, In YANG 1.1, are modules and related sub-modules allowed to import the same module with different prefixes? is the following example sane? I.e. where the ietf-yang-types module is being imported with 3 different prefixes: module example-system { yang-version 1.1; namespace "urn:example:system"; prefix "sys"; import ietf-yang-types { prefix "yang"; } include example-types; include example-types-2; description "The module for entities implementing the Example system."; revision 2007-06-09 { description "Initial revision."; } // definitions follow... } submodule example-types { yang-version 1.1; belongs-to "example-system" { prefix "sys"; } import ietf-yang-types { prefix "yang-types"; } description "This submodule defines common Example types."; revision "2007-06-09" { description "Initial revision."; } // definitions follows... } submodule example-types-2 { yang-version 1.1; belongs-to "example-system" { prefix "sys"; } import ietf-yang-types { prefix "ietf-types"; } description "Also imports ietf-yang-types but with a different prefix"; revision "2007-06-09" { description "Initial revision."; } // definitions follows... } Thanks, Rob From nobody Tue Jun 14 03:29:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1211512D5FC for ; Tue, 14 Jun 2016 03:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 oAet7CBYz1jl for ; Tue, 14 Jun 2016 03:29:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 90F7712D1BD for ; Tue, 14 Jun 2016 03:29:25 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id BC6591AE01AA; Tue, 14 Jun 2016 12:29:24 +0200 (CEST) Date: Tue, 14 Jun 2016 12:29:48 +0200 (CEST) Message-Id: <20160614.122948.727158061855155249.mbj@tail-f.com> To: rwilton@cisco.com From: Martin Bjorklund In-Reply-To: <7cadc53f-9a53-7303-f20e-cfcd5dea5919@cisco.com> References: <7cadc53f-9a53-7303-f20e-cfcd5dea5919@cisco.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Submodule import of the same module with different prefixes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 10:29:27 -0000 Robert Wilton wrote: > Hi, > > In YANG 1.1, are modules and related sub-modules allowed to import the > same module with different prefixes? Yes. /martin > > is the following example sane? I.e. where the ietf-yang-types module > is being imported with 3 different prefixes: > > module example-system { > yang-version 1.1; > namespace "urn:example:system"; > prefix "sys"; > > import ietf-yang-types { > prefix "yang"; > } > > include example-types; > include example-types-2; > > description > "The module for entities implementing the Example system."; > > revision 2007-06-09 { > description "Initial revision."; > } > > // definitions follow... > } > > submodule example-types { > yang-version 1.1; > belongs-to "example-system" { > prefix "sys"; > } > > import ietf-yang-types { > prefix "yang-types"; > } > > description > "This submodule defines common Example types."; > > revision "2007-06-09" { > description "Initial revision."; > } > > // definitions follows... > } > > submodule example-types-2 { > yang-version 1.1; > belongs-to "example-system" { > prefix "sys"; > } > > import ietf-yang-types { > prefix "ietf-types"; > } > > description > "Also imports ietf-yang-types but with a different prefix"; > > revision "2007-06-09" { > description "Initial revision."; > } > > // definitions follows... > } > > Thanks, > Rob > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Jun 15 01:22:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6806D12D150; Wed, 15 Jun 2016 01:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 W_gR2FNGqk_l; Wed, 15 Jun 2016 01:22:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3580D12D0DC; Wed, 15 Jun 2016 01:22:01 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id AF8062DC39E; Wed, 15 Jun 2016 10:21:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8B78C35C045; Wed, 15 Jun 2016 10:21:59 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0294.000; Wed, 15 Jun 2016 10:21:59 +0200 From: To: Lou Berger , netmod WG Thread-Topic: [netmod] Opstate solutions discussions: update and request for WG input Thread-Index: AQHRwMeryY8MgJBTQEykBoRF6CHPKJ/qO8xA Date: Wed, 15 Jun 2016 08:21:58 +0000 Message-ID: <4625_1465978919_57611027_4625_9236_1_9E32478DFA9976438E7A22F69B08FF921BC5E7FD@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> In-Reply-To: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.15.73317 Archived-At: Cc: "netmod-chairs@ietf.org" Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 08:22:03 -0000 Hi Lou, chairs,=20 Based on the feedback on the list, could we conclude that we go to B) or do= you want to wait more ? We would like to close work on multiple YANG models, and today ops state ar= e blocking ... would be good to close it asap. Best Regards, Stephane -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger Sent: Tuesday, June 07, 2016 16:20 To: netmod WG Cc: netmod-chairs@ietf.org Subject: [netmod] Opstate solutions discussions: update and request for WG = input All, We want to provide an update based on the off line discussions related to O= pState Solutions that we have been having and solicit input from the WG. All authors of current solution drafts [1,2,3] together with those who help= ed conduct the solutions analysis* were invited to the these discussions --= with the objective of coming up with a single consolidated proposal to bri= ng to the WG. (I/Lou acted as facilitator as Kent and Juergen were and are = involved with the technical details.) The discussions have yielded some results but, unfortunately, not a single = consolidated proposal as hoped, but rather two alternate directions -- and = clearly we need to choose one: 1) Adopt the conventions for representing state/config based on Section 6 of [1]. From a model definition perspective, these conventions impact every model and every model writer. 2) Model OpState using a revised logical datastore definition as introduced in [4] and also covered in [5]. There is also a variant of this that we believe doesn't significantly impact this choice. With this approach, model definitions need no explicit changes to support applied configuration. >From a technology/WG standpoint, we believe an approach that doesn't impact every model written (i.e., #2) is superior. The counterpoint to this is that the conventions based approach (i.e., #1) = is available today and being followed in OpenConfig defined models. We would like to hear opinions on this from the WG before declaring one of = the following as the WG direction: A) models that wish to support applied configuration MUST follow conventions based on [1] -- and the WG needs to formalize these conventions. or B) no explicit support is required for models to support applied configuration -- and that the WG needs to formalize an opstate solution based on the approach discussed in [4] and [5]. We intend to close on this choice before Berlin. Thank you, Lou (and co-chairs) [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 * - Chris H. and Acee L. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jun 15 03:37:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B33B12D575 for ; Wed, 15 Jun 2016 03:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U688IK6Wzzv7 for ; Wed, 15 Jun 2016 03:37:28 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id B6CC412D572 for ; Wed, 15 Jun 2016 03:37:28 -0700 (PDT) Received: (qmail 21845 invoked by uid 0); 15 Jun 2016 10:37:26 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 15 Jun 2016 10:37:26 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 6ydL1t00P2SSUrH01ydPZ2; Wed, 15 Jun 2016 04:37:24 -0600 X-Authority-Analysis: v=2.1 cv=OPe0g0qB 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=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=oK_VWpv5GtAA:10 a=pD_ry4oyNxEA:10 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=4x6f1OGFN8XGkTC79f0A:9 a=EYG0rMam1Hl6zxom:21 a=ENQFW-kLOQn5G8-b:21 a=CjuIK1q_8ugA:10 a=RmrFvp9qXTL7MAzcxlte: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; bh=zdECQ9VKNa49NrksKeocg6ziPTFSh6kpLEcHCZEGUjg=; b=pd/J8hQ1USd4TNePab+CcjQ7dv mDMD6yDJ2v22M9Y482+MP11PP8dUU581hjA7mV4kfCmqaK+Hry/4p8MZQwwAtrkcTVAkmmpa2UaCH 5N0oK5jP0nQP6rSLRn70u/4y+; Received: from [100.15.89.178] (port=40582 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.86_2) (envelope-from ) id 1bD8CH-0003Ar-Mx; Wed, 15 Jun 2016 04:37:21 -0600 From: Lou Berger To: , netmod WG Date: Wed, 15 Jun 2016 06:37:16 -0400 Message-ID: <15553a2f360.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <4625_1465978919_57611027_4625_9236_1_9E32478DFA9976438E7A22F69B08FF921BC5E7FD@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <4625_1465978919_57611027_4625_9236_1_9E32478DFA9976438E7A22F69B08FF921BC5E7FD@OPEXCLILMA4.corporate.adroot.infra.ftgroup> User-Agent: AquaMail/1.6.2.3 (build: 27000203) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.89.178 authed with lberger@labn.net} Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 10:37:30 -0000 Stephane, Response has been a bit light, albeit all for (B). I'm hoping we'd here from some additional WG participants - so we need a little bit more time. I'm still expecting for this discussion to be closed before Berlin. Also, can we infer from you message that you are also in favor of (B)? Thanks, Lou On June 15, 2016 4:22:27 AM wrote: > Hi Lou, chairs, > > Based on the feedback on the list, could we conclude that we go to B) or do > you want to wait more ? > We would like to close work on multiple YANG models, and today ops state > are blocking ... would be good to close it asap. > > Best Regards, > > Stephane > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, June 07, 2016 16:20 > To: netmod WG > Cc: netmod-chairs@ietf.org > Subject: [netmod] Opstate solutions discussions: update and request for WG > input > > All, > > We want to provide an update based on the off line discussions related to > OpState Solutions that we have been having and solicit input from the WG. > > All authors of current solution drafts [1,2,3] together with those who > helped conduct the solutions analysis* were invited to the these > discussions -- with the objective of coming up with a single consolidated > proposal to bring to the WG. (I/Lou acted as facilitator as Kent and > Juergen were and are involved with the technical details.) > > The discussions have yielded some results but, unfortunately, not a single > consolidated proposal as hoped, but rather two alternate directions -- and > clearly we need to choose one: > > 1) Adopt the conventions for representing state/config > based on Section 6 of [1]. > > From a model definition perspective, these conventions > impact every model and every model writer. > > 2) Model OpState using a revised logical datastore definition > as introduced in [4] and also covered in [5]. There is > also a variant of this that we believe doesn't significantly > impact this choice. > > With this approach, model definitions need no explicit > changes to support applied configuration. > >>From a technology/WG standpoint, we believe an approach > that doesn't impact every model written (i.e., #2) is superior. > The counterpoint to this is that the conventions based approach (i.e., #1) > is available today and being followed in OpenConfig defined models. > > We would like to hear opinions on this from the WG before declaring one of > the following as the WG direction: > > A) models that wish to support applied configuration MUST > follow conventions based on [1] -- and the WG needs to > formalize these conventions. > or > B) no explicit support is required for models to support > applied configuration -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. > > We intend to close on this choice before Berlin. > > Thank you, > Lou (and co-chairs) > > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > * - Chris H. and Acee L. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > From nobody Wed Jun 15 04:28:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C725D12D091 for ; Wed, 15 Jun 2016 04:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 uUnVbNpUm5cH for ; Wed, 15 Jun 2016 04:28:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1ED812B064 for ; Wed, 15 Jun 2016 04:28:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3CC26A53; Wed, 15 Jun 2016 13:28:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ot2qIJXsmiaC; Wed, 15 Jun 2016 13:28:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 15 Jun 2016 13:28:06 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FD7B20047; Wed, 15 Jun 2016 13:28:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xuZWBFWSoe1f; Wed, 15 Jun 2016 13:28:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB7AF2005E; Wed, 15 Jun 2016 13:28:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A12423B247E6; Wed, 15 Jun 2016 13:28:02 +0200 (CEST) Date: Wed, 15 Jun 2016 13:28:01 +0200 From: Juergen Schoenwaelder To: "EXT Clyde Wildes (cwildes)" Message-ID: <20160615112801.GA30742@elstar.local> Mail-Followup-To: "EXT Clyde Wildes (cwildes)" , "netmod@ietf.org" , Dan Romascanu References: <20160510211427.390.80951.idtracker@ietfa.amsl.com> <3BC3991A-615F-47CE-A567-721C8272404E@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: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 11:28:11 -0000 On Fri, May 27, 2016 at 07:30:43PM +0000, Sterne, Jason (Nokia - CA) wrote: > In any case the pyang tree has log-input-transports but it doesn't > seem to be down in the actual model itself. I just did run into this while trying to review the document. Apparently, the tree is not in sync with the YANG module. Will there be a new version where this is fixed? /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 Jun 15 05:22:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D525312D0EE; Wed, 15 Jun 2016 05:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 J3pPse4yxGMx; Wed, 15 Jun 2016 05:22:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD3612D1B1; Wed, 15 Jun 2016 05:22:00 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 259E53B4206; Wed, 15 Jun 2016 14:21:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0010227C066; Wed, 15 Jun 2016 14:21:58 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0294.000; Wed, 15 Jun 2016 14:21:58 +0200 From: To: Lou Berger , netmod WG Thread-Topic: [netmod] Opstate solutions discussions: update and request for WG input Thread-Index: AQHRxvHqBNMrYXI/iU6nuQ6LtfSl15/qcwWw Date: Wed, 15 Jun 2016 12:21:58 +0000 Message-ID: <21864_1465993319_57614867_21864_5897_1_9E32478DFA9976438E7A22F69B08FF921BC5F5BA@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <4625_1465978919_57611027_4625_9236_1_9E32478DFA9976438E7A22F69B08FF921BC5E7FD@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <15553a2f360.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <15553a2f360.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.6.15.104517 Archived-At: Cc: "netmod-chairs@ietf.org" Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 12:22:04 -0000 Yes, I'm in favor of B, I already expressed it on the list. Thanks -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Wednesday, June 15, 2016 12:37 To: LITKOWSKI Stephane OBS/OINIS; netmod WG Cc: netmod-chairs@ietf.org Subject: RE: [netmod] Opstate solutions discussions: update and request for= WG input Stephane, Response has been a bit light, albeit all for (B). I'm hoping we'd here fr= om some additional WG participants - so we need a little bit more time.=20= =20 I'm still expecting for this discussion to be closed before Berlin. Also, can we infer from you message that you are also in favor of (B)? Thanks, Lou On June 15, 2016 4:22:27 AM wrote: > Hi Lou, chairs, > > Based on the feedback on the list, could we conclude that we go to B)=20 > or do you want to wait more ? > We would like to close work on multiple YANG models, and today ops=20 > state are blocking ... would be good to close it asap. > > Best Regards, > > Stephane > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, June 07, 2016 16:20 > To: netmod WG > Cc: netmod-chairs@ietf.org > Subject: [netmod] Opstate solutions discussions: update and request=20 > for WG input > > All, > > We want to provide an update based on the off line discussions related=20 > to OpState Solutions that we have been having and solicit input from the = WG. > > All authors of current solution drafts [1,2,3] together with those who=20 > helped conduct the solutions analysis* were invited to the these=20 > discussions -- with the objective of coming up with a single=20 > consolidated proposal to bring to the WG. (I/Lou acted as facilitator=20 > as Kent and Juergen were and are involved with the technical details.) > > The discussions have yielded some results but, unfortunately, not a=20 > single consolidated proposal as hoped, but rather two alternate=20 > directions -- and clearly we need to choose one: > > 1) Adopt the conventions for representing state/config > based on Section 6 of [1]. > > From a model definition perspective, these conventions > impact every model and every model writer. > > 2) Model OpState using a revised logical datastore definition > as introduced in [4] and also covered in [5]. There is > also a variant of this that we believe doesn't significantly > impact this choice. > > With this approach, model definitions need no explicit > changes to support applied configuration. > >>From a technology/WG standpoint, we believe an approach > that doesn't impact every model written (i.e., #2) is superior. > The counterpoint to this is that the conventions based approach (i.e.,=20 > #1) is available today and being followed in OpenConfig defined models. > > We would like to hear opinions on this from the WG before declaring=20 > one of the following as the WG direction: > > A) models that wish to support applied configuration MUST > follow conventions based on [1] -- and the WG needs to > formalize these conventions. > or > B) no explicit support is required for models to support > applied configuration -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. > > We intend to close on this choice before Berlin. > > Thank you, > Lou (and co-chairs) > > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > [4]=20 > https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > [5]=20 > https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > * - Chris H. and Acee L. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete=20 > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jun 15 05:41:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCEE12B03D; Wed, 15 Jun 2016 05:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 HxjyUndMtKnb; Wed, 15 Jun 2016 05:41:19 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095EA12D0FC; Wed, 15 Jun 2016 05:41:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BEF30FC6; Wed, 15 Jun 2016 14:41:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hzOxcW8I87iE; Wed, 15 Jun 2016 14:41:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 15 Jun 2016 14:41:16 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA11920054; Wed, 15 Jun 2016 14:41:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hk7pRl1Q9TGn; Wed, 15 Jun 2016 14:41:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 134B420055; Wed, 15 Jun 2016 14:41:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 131CA3B24C3B; Wed, 15 Jun 2016 14:41:04 +0200 (CEST) Date: Wed, 15 Jun 2016 14:41:04 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160615124104.GC30783@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod-chairs@ietf.org, netmod@ietf.org References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <20160608.094518.235671744205955797.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160608.094518.235671744205955797.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 12:41:20 -0000 On Wed, Jun 08, 2016 at 09:45:18AM +0200, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I prefer (B). > > For the record, I also prefer B. > Same here. /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 Jun 15 06:27:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8F812D587; Wed, 15 Jun 2016 06:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x92w1tmREgLa; Wed, 15 Jun 2016 06:27:23 -0700 (PDT) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C4312D0F1; Wed, 15 Jun 2016 06:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:References:In-Reply-To:Date: Subject:From:Cc:To:MIME-Version:Sender:Reply-To:Message-ID: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=K0c1nCpGbmPjm+vu4Lhf81OwVfcjl0XVOTB5lTbXMf4=; b=yXa/842Cy6Z5aPQyYfCX2tlRm rqumwxCgYr4RSBO18GowzRzN2D7RXHClZxz59YUSurfTITYG4Oa/kvvEZmEFaawLpF2eLmz9oGkD4 hIhNQ3uS0nQj5xsIu7moRBJYUNYUUzJ53K7+J0m6EnEvCODXYwoLWVXnjvxJVTecCHx6z2ioWMkIX JvMkW85aYWqRbgXnc9Qm1cORIwuLLBw5bJP2QKdUiNXYbU5lHwqQlIpD9VGkyCrEp5+QCRjElRrjc GU/mRmXNSggs/NW2e8Y9sbaUJfk7B+pqkDpLgANTU2/3gMlDkMARrjzY9bBp4W74iJQn48KiWtc4D USNJ7WqIw==; Received: from host-92-19-235-91.static.as13285.net ([92.19.235.91]:60476 helo=[IPv6:::ffff:192.168.1.81]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bDAqk-001XtC-Jq; Wed, 15 Jun 2016 14:27:19 +0100 MIME-Version: 1.0 To: Juergen Schoenwaelder , Martin Bjorklund From: Jonathan Hansford Date: Wed, 15 Jun 2016 14:34:52 +0100 Importance: normal X-Priority: 3 In-Reply-To: <20160615124104.GC30783@elstar.local> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <20160608.094518.235671744205955797.mbj@tail-f.com> <20160615124104.GC30783@elstar.local> Content-Type: multipart/alternative; boundary="_FFE0B7FB-3537-42B7-935A-E6641A33D5B2_" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Message-Id: <20160615132722.E4C4312D0F1@ietfa.amsl.com> Archived-At: Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Opstate solutions discussions: update and request forWG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 13:27:29 -0000 --_FFE0B7FB-3537-42B7-935A-E6641A33D5B2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I also prefer B. Jonathan From: Juergen Schoenwaelder Sent: 15 June 2016 13:41 To: Martin Bjorklund Cc: netmod-chairs@ietf.org; netmod@ietf.org Subject: Re: [netmod] Opstate solutions discussions: update and request for= WG input On Wed, Jun 08, 2016 at 09:45:18AM +0200, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > >=20 > > I prefer (B). >=20 > For the record, I also prefer B. > Same here. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_FFE0B7FB-3537-42B7-935A-E6641A33D5B2_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I also prefer B.


Jonathan

 

From: Juergen Schoenwaelder
Sent: 15 June 2016 13:41
To: Martin Bjorklund
Cc: netmod-chairs@ietf.org; netmod@ietf.org
Subject: Re: [netmod= ] Opstate solutions discussions: update and request forWG input

 

On Wed, Jun 0= 8, 2016 at 09:45:18AM +0200, Martin Bjorklund wrote:

> Andy Bierman <andy@yumaworks.com> wrote:

> > Hi,

> >

> > I prefer (B).

>

> For the record, I also prefer B.

>=  

 

Same here.

 

/js

 

--

Juergen Schoenwaelder=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Jacobs University Bremen gGmbH

Phone: +49 421 200 3587=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Campus Ring 1 | 28759 Bremen | Germany

Fax:=C2=A0=C2=A0 +49 421 200 3103=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 <http://www.jacobs-university.de/>

 

______________________________= _________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/m= ailman/listinfo/netmod

 

<= /body>= --_FFE0B7FB-3537-42B7-935A-E6641A33D5B2_-- From nobody Wed Jun 15 08:29:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27E812D731 for ; Wed, 15 Jun 2016 08:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 vQ2gIaSonUO1 for ; Wed, 15 Jun 2016 08:29:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2548E12D68B for ; Wed, 15 Jun 2016 08:29:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E8653740 for ; Wed, 15 Jun 2016 17:29:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4p_JqJ_a4Uwo for ; Wed, 15 Jun 2016 17:29:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 15 Jun 2016 17:29:37 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16EFB20054 for ; Wed, 15 Jun 2016 17:29:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xa-b0ru-JmIk; Wed, 15 Jun 2016 17:29:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD9E720031; Wed, 15 Jun 2016 17:29:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B9FA73B25306; Wed, 15 Jun 2016 17:29:33 +0200 (CEST) Date: Wed, 15 Jun 2016 17:29:32 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20160615152932.GA31216@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:29:44 -0000 Hi, Dan Romascanu encouraged me to look at this I-D as part of his efforts to organize YANG document reviews. Since the YANG definitions are not consistent with the tree diagram, I have not really looked at the YANG definitions yet. So the comments below are essentially about the surrounding document structure, terminology, etc. - Abstract: The 'which is used to convey event notification messages' may relate to 'the Syslog protocol' or 'a data model' and hence the sentence is I think potentially confusing. Perhaps simply remove the phrase altogether? Readers who do not know what SYSLOG is should stop reading here anyway. Or break the sentence into two to make the structure clearer. Perhaps add one more sentence describing what the scope of the data model is. - The text uses Syslog, syslog, and SYSLOG. It is not clear what the difference is (if any). If there is no semantic difference, I suggest to pick one writing style (and 5424 seems to prefer all lowercase except in cases where a sentence starts etc). - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 to 'The ietf-syslog Module' or something similar and consider changing the title of section 4 to "Syslog YANG Modules" since it contains the definitions of the modules themselves. - In section 2, should 'monitor and control' be 'configure and monitor' in section 2? Are there actually definitions that support monitoring? Perhaps the scope is just configuration? Otherwise, I would have expected to see a bunch of basic counters (messages received, forwarded, dropped, the usual monitoring stuff). - In section 2, s/network management agents such as NETCONF/network management protocols such as NETCONF/ - In section 2, the phrase 'This module' is a hanging reference. There is no prior text talking about a module. Perhaps replace with 'The data model' - I did not find the term 'message distributor' in RFC 5424. The figure first made me assume that only a console, log buffers, or log files are message distributors but later it was stated that relays and collectors (RFC 5424 defined terms) are also 'message distributors'. Perhaps it helps to clearly spell out terms imported from RFC 5424 and to clearly define any additional terms that go beyond what is defined in RFC 5424. - Is it possible to shorten 'log-input-transports' to simply 'log-inputs' (en par with log-actions)? And since both containers are under syslog, perhaps even the 'log-' prefix is not needed and all we have are /syslog/inputs and /syslog/actions? (I generally find it useful to look at the resulting paths and whether they are 'engineer friendly'. - I guess I have to define multiple /syslog/input/receiver in order to listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and [::]:514? This may be just find - just checking that this is the idea. - I actually do not find the definition of log-input-transports in the YANG model. It seems the tree diagram is not consistent with the YANG model. So I can't judge what the structured-data boolean flag is doing or what the syslog-sign presence container would do for inputs. - The security considerations are quite generic; I think the template asks for a more specific discussion. - I am not sure why RFC 6020 is an informative reference and why all the normative references are actually normative. It might be useful to go over the list to make sure we get the normative / informative distinction right. - My understanding is that RFC 5424 numbers facilities and there is a hard limit on the number of facilities that the protocol can distinguish. RFC 5424 says: Facility values MUST be in the range of 0 to 23 inclusive. Given this, the 'extending facilities' appendix does not make much sense to me. And given the fact that the number of facilities is fixed (which is due to the way things are encoded in RFC 5424), I am not even sure that using an identity instead of an enumeration is useful (except if we expect a future version of SYSLOG to use a very different encoding of facilities). I mean, to stay within the bounds of RFC 5424, all one can do is to add an identity that maps to an already allocated code point. - Do not use 1.1.1.1 as an example IP address, consider using an IPv6 address from the IPv6 example address space. - Section 4.3 should not be in Section 4 and the title 'A Syslog Example' is kind of misleading since the text shows NETCONF messages operating on the SYSLOG YANG data model. I suggest to move 4.3 to a new top-level section 5 "Usage Examples". Does it make sense to show some complete example configs for typical use cases? - Before the YANG model definitions, it is a common idea to describe what is imported from which RFCs. For example, one of the YANG modules imports ietf-interfaces but there is no (normative) reference to the relevant RFC. See the first sentence in section 4 of RFC 7277 for an example how to do this. - I suggest to remove the subsection title 3.1. or to change the title to "SYSLOG Data Model" and lifting it up to the top-level so that it becomes section 4. As said above, I have not reviewed the YANG definitions yet since apparently it is not in sync with the rest of the document. But I thought I send these comments now anyway so that they can already be taken into account. /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 Jun 15 08:48:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E06112D78A; Wed, 15 Jun 2016 08:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=kuatrotechnology.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 utgbn_-cbvDV; Wed, 15 Jun 2016 08:48:37 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::625]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDE512D8FB; Wed, 15 Jun 2016 08:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EVK0bS0UcdxVTov9BS3g+i8W77uhrr9hf6jubpXGCWY=; b=dobJRRWWnRSW2nIIRCk+nKLqrctMBtiGXOS4m7eWG6Urj6rkBCVUCs0Y0ZmqMehKU7Nggb+flkYJKc3PfovXbesrn05WCE2yqcgOZKkcEdxYTQ/d8t2w0/djKq5sG1wH9t62B3Z/DJp3ujOG28jJkuQRsez0DZXsOUea5nKIbJM= Received: from VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) by VI1PR06MB1488.eurprd06.prod.outlook.com (10.164.86.30) with Microsoft SMTP Server (TLS) id 15.1.517.2; Wed, 15 Jun 2016 15:46:39 +0000 Received: from VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) by VI1PR06MB1488.eurprd06.prod.outlook.com ([10.164.86.30]) with mapi id 15.01.0517.014; Wed, 15 Jun 2016 15:46:39 +0000 From: Xufeng Liu To: Lou Berger , netmod WG Thread-Topic: [netmod] Opstate solutions discussions: update and request for WG input Thread-Index: AQH5OFvhp0hvxO8+SMw1aajlqpN6I5+bws7A Date: Wed, 15 Jun 2016 15:46:39 +0000 Message-ID: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> In-Reply-To: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> 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=xliu@kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: e2db80c6-d29d-44bf-3f4f-08d395343df2 x-microsoft-exchange-diagnostics: 1; VI1PR06MB1488; 6:kHoFjuF0pbloBEiQyPP2VUOKGw5oXGeWPgbaSV7uT0xDoCb33LWaYASpRcKwPmR5d+MIJTC1/IMt1AzaDjdBhcJ5LFbgvv//ypHdbnsGqD6SSYvBTmJkjcT2sexUK6u8Pqu1LTlHGX7Gksz4Q0TJSJ9SvY6q6gHqlYA6wuPqSGaCRoYhy3ouyQiH8bA7gBl8Zp7vbAwGBzQnW4juw9TR1aeeRlWFcedk3wpdNkam/zBE0O5Fc5KdwJNTrUi2LO3Cc/0WSjlJ3wFI+Ysop0vYAFWxW5YTExDiAtlOiQfQ+CA=; 5:axgAX2ep3OwF/d0fEeOq+wcSgM5ztGmoGtuAvDuFE5hBl/QgO8ls/xBYTRg94WN6/E00dFgLb3VRDUWRznDaEVVlTw0A4lRvvnZeJFk6oxIVUYa34pLTTvVYJ5uUGtIpmvWqcXimOPMi7pWBTjnnzw==; 24:Oe8Uv63IDyN4giltuHN1Q5WL9RCXOtSFzbBlD1+4iSOcewjeVTIFhuWro5N1ys6B9L6ejd9s4pJs8DyEOn5tpTjgUIti1gzzstpsAsyQhNk=; 7:EKPEC93IJrJf33vfjvci2CPTYqpCDVzEw2oYzC7O+WTVoyXnnAJmn4KpO0cEG8QBT3l72tKqon18lbSDYYRG7LZiLXnAWwWpfTdrTdP+4X1tXlxET26vw21JnT3PIJHxVqTN9ZD7KcNEu5nTwf7x+P0sGXfOt+ZmOHfzaWqs954dzoboy04E64T9zhKqO47Wax2jG7LwmiAdxTaj46/w3Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR06MB1488; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046); SRVR:VI1PR06MB1488; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1488; x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(189002)(199003)(377454003)(122556002)(11100500001)(106356001)(561944003)(101416001)(10400500002)(33656002)(106116001)(105586002)(15650500001)(74316001)(92566002)(5004730100002)(86362001)(77096005)(19580405001)(15975445007)(76576001)(5008740100001)(2950100001)(2900100001)(19580395003)(3280700002)(3660700001)(68736007)(87936001)(4326007)(8936002)(76176999)(54356999)(81166006)(81156014)(50986999)(9686002)(586003)(97736004)(5002640100001)(5003600100002)(2906002)(189998001)(66066001)(6116002)(102836003)(3846002)(5001770100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR06MB1488; H:VI1PR06MB1488.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: kuatrotech.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: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2016 15:46:39.5442 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1488 Archived-At: Cc: "netmod-chairs@ietf.org" Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 15:48:39 -0000 For applied configuration, I'd also prefer [B], especially [4], which clari= fies datastores in a better way. [4] also paves a way for better modeling o= f derived state. Once the approach for applied configuration is formalized= , the derived state, as a part of OpState modeling, will need to be formali= zed. At that time, the modeling ideas from [1] could be applied, to re-cons= ider the top-level branch for config-false tree. In this regard, 1) and 2) = can be combined. Thanks, - Xufeng > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, June 7, 2016 10:20 AM > To: netmod WG > Cc: netmod-chairs@ietf.org > Subject: [netmod] Opstate solutions discussions: update and request for W= G > input >=20 > All, >=20 > We want to provide an update based on the off line discussions related to > OpState Solutions that we have been having and solicit input from the WG. >=20 > All authors of current solution drafts [1,2,3] together with those who he= lped > conduct the solutions analysis* were invited to the these discussions -- = with the > objective of coming up with a single consolidated proposal to bring to th= e WG. > (I/Lou acted as facilitator as Kent and Juergen were and are involved wit= h the > technical details.) >=20 > The discussions have yielded some results but, unfortunately, not a singl= e > consolidated proposal as hoped, but rather two alternate directions -- an= d > clearly we need to choose one: >=20 > 1) Adopt the conventions for representing state/config > based on Section 6 of [1]. >=20 > From a model definition perspective, these conventions > impact every model and every model writer. >=20 > 2) Model OpState using a revised logical datastore definition > as introduced in [4] and also covered in [5]. There is > also a variant of this that we believe doesn't significantly > impact this choice. >=20 > With this approach, model definitions need no explicit > changes to support applied configuration. >=20 > >From a technology/WG standpoint, we believe an approach > that doesn't impact every model written (i.e., #2) is superior. > The counterpoint to this is that the conventions based approach (i.e., #1= ) is > available today and being followed in OpenConfig defined models. >=20 > We would like to hear opinions on this from the WG before declaring one o= f the > following as the WG direction: >=20 > A) models that wish to support applied configuration MUST > follow conventions based on [1] -- and the WG needs to > formalize these conventions. > or > B) no explicit support is required for models to support > applied configuration -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. >=20 > We intend to close on this choice before Berlin. >=20 > Thank you, > Lou (and co-chairs) >=20 > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-0= 0 > [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > * - Chris H. and Acee L. >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jun 15 09:09:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FAA12D7AD for ; Wed, 15 Jun 2016 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 bQYbaef-0qwV for ; Wed, 15 Jun 2016 09:09:03 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C0212D501 for ; Wed, 15 Jun 2016 09:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1052; q=dns/txt; s=iport; t=1466006943; x=1467216543; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cqnJeoASvontNyc1WT71NoWPjXA381mgvpXAiOEijRA=; b=clm1F5rTqZVAdXfbBIBkEB4J77kH7c0l8TW+KVo0yp+6nhJU7pfM+fQ2 LxazhNZKKGBLbWi2xKJLlHaqdbARlE+11RCzqFOybvUJ43kfLsq9Im8Il wYNH8iZsowGGsqHvFxdlZkqRARG8YPWQ5f3ebv9lur5gVvpw3D752yQrA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgA5fWFX/5JdJa1aA4M+Vn0GumaBe?= =?us-ascii?q?R6FeQIcgRY4FAEBAQEBAQFlJ4RMAQEEIxFFDgICAQgOAggCAiYCAgIZFxUQAgQ?= =?us-ascii?q?OBYgwrjSQfgEBAQEBAQEBAQEBAQEBAQEBAQEBARwFfIUmgXeCVoRAFwomgjorg?= =?us-ascii?q?i8FmGkBjiiPIo9zAR42ggccgUxuiQkBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,476,1459814400"; d="scan'208";a="286025651" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2016 16:09:02 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5FG92BS010403 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2016 16:09:02 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 15 Jun 2016 11:09:02 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1104.009; Wed, 15 Jun 2016 11:09:01 -0500 From: "Clyde Wildes (cwildes)" To: Juergen Schoenwaelder Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt Thread-Index: AQHRqwEIoPXkjp2l/k2OqqhnpwdmNZ+yjKoAgBqvymCAHbNOgP//2UeA Date: Wed, 15 Jun 2016 16:09:01 +0000 Message-ID: References: <20160510211427.390.80951.idtracker@ietfa.amsl.com> <3BC3991A-615F-47CE-A567-721C8272404E@cisco.com> <20160615112801.GA30742@elstar.local> In-Reply-To: <20160615112801.GA30742@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: [128.107.151.26] Content-Type: text/plain; charset="utf-8" Content-ID: <7C231BC252DA454C8C2F69B47F007996@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 16:09:05 -0000 SnVyZ2VuLA0KDQpUaGVyZSB3aWxsIGJlIGEgbmV3IHZlcnNpb24gc29vbi4NCg0KVGhhbmtzLA0K DQpDbHlkZQ0KDQpPbiA2LzE1LzE2LCA0OjI4IEFNLCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIiA8 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPk9uIEZyaSwg TWF5IDI3LCAyMDE2IGF0IDA3OjMwOjQzUE0gKzAwMDAsIFN0ZXJuZSwgSmFzb24gKE5va2lhIC0g Q0EpIHdyb3RlOg0KPg0KPj4gSW4gYW55IGNhc2UgdGhlIHB5YW5nIHRyZWUgaGFzIGxvZy1pbnB1 dC10cmFuc3BvcnRzIGJ1dCBpdCBkb2Vzbid0DQo+PiBzZWVtIHRvIGJlIGRvd24gaW4gdGhlIGFj dHVhbCBtb2RlbCBpdHNlbGYuDQo+DQo+SSBqdXN0IGRpZCBydW4gaW50byB0aGlzIHdoaWxlIHRy eWluZyB0byByZXZpZXcgdGhlIGRvY3VtZW50LiBBcHBhcmVudGx5LA0KPnRoZSB0cmVlIGlzIG5v dCBpbiBzeW5jIHdpdGggdGhlIFlBTkcgbW9kdWxlLiBXaWxsIHRoZXJlIGJlIGEgbmV3IHZlcnNp b24NCj53aGVyZSB0aGlzIGlzIGZpeGVkPw0KPg0KPi9qcw0KPg0KPi0tIA0KPkp1ZXJnZW4gU2No b2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+UGhv bmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVu IHwgR2VybWFueQ0KPkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cu amFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQo= From nobody Wed Jun 15 09:45:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCC012D5BE; Wed, 15 Jun 2016 09:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4GnkhfLooyj; Wed, 15 Jun 2016 09:45:26 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 395C412D1D1; Wed, 15 Jun 2016 09:45:26 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id i123so6672372pfg.0; Wed, 15 Jun 2016 09:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=oslWmABxe5V8sWf9DL4+zOEACOPQhGRyi5ucqxuSfUI=; b=XofJEy9+0u6/aljUYKxDUmh4pRYacAlZ2yzC4m1lu6cb/vBEJBqP174BC+toKnDtBU KmtHpepUuSiDmlYzR1WdZsVtLGPUIAZetl2JxFoN0tw34PZMJVugAerc/myhNrwAOu89 x0LRAzH/Wr7ugjHRMG9CdyOLISmOUhg8X5VaoC6lPd+FZQP/PzKI/L6LEe/I3CTJXbre fae+ehyuByzHuGogb+6ABtnEnEhxwE/1Xp0dz8UtVLS2iE2q+eOZlI61NgtQCTyb6Dwr RjS2Z6G2cCiWYhYUAEnQs59IThRiBiCJELO8va6a77MJD73s4Ae/FB1W8LNmiu7teggu YGfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=oslWmABxe5V8sWf9DL4+zOEACOPQhGRyi5ucqxuSfUI=; b=UxWS74FC+U+sgoE2wRaMw6crerwHB2aAwo98fFxAeZvgTko80egfys6QiHrBIoYao9 jrRt2O9o6E5qDfbwEgmKqan1X51oQ+Y3kVq9bVCPdBw3JCu8nDKTKqKOMD2uQZcs0Q63 44qFDJEXYAGZ5l3Duu0YeyJWIyS0xecrQDgzhE8T9cmxrMtTHiRByZWehK/H/NEO6NFv FnOXEEUt9E7eSdz7+YvbyrFIvBwquJk36nLyWTjNX6rz7idMYZ3JYkDHmcFVFQGlRXrR m3n6Fr+YY8aukBGOOR0pR8XDpGcgt+apZsxMYzkqMMHcZHB7O03443XHaHdGgE85RiZs rjSA== X-Gm-Message-State: ALyK8tLKJ/4Ddm4dsicQl4LhV28ewsa5mlyu30hpGeuS6HEgPwVQrKip7WawHvDDxl5W9g== X-Received: by 10.98.98.6 with SMTP id w6mr4888920pfb.0.1466009125790; Wed, 15 Jun 2016 09:45:25 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1006::49b? ([2001:420:c0c8:1006::49b]) by smtp.gmail.com with ESMTPSA id g8sm27142760pag.30.2016.06.15.09.45.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2016 09:45:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_629A6F6B-7FBE-4B31-B5FA-C6F0AD72AFB1" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 15 Jun 2016 09:45:22 -0700 Message-Id: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> To: Andy Bierman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 16:45:29 -0000 --Apple-Mail=_629A6F6B-7FBE-4B31-B5FA-C6F0AD72AFB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 (a.k.a. support option B) > On Jun 7, 2016, at 9:23 AM, Andy Bierman wrote: >=20 > Hi, >=20 > I prefer (B). > I do not think it is realistic that vendors will rewrite their IETF > modules and vendor modules and all the associated client/server = instrumentation. > This is expensive at many levels. Stability is important for an API. >=20 > So if we do (A), there will be some modules following the convention > and the rest using proprietary RPC-based solutions. > But if we do (B), vendors can integrate the standard RPC-based = solution > into their existing running code with zero disturbance. >=20 >=20 > Andy >=20 >=20 >=20 > On Tue, Jun 7, 2016 at 7:19 AM, Lou Berger > wrote: > All, >=20 > We want to provide an update based on the off line discussions > related to OpState Solutions that we have been having and solicit > input from the WG. >=20 > All authors of current solution drafts [1,2,3] together with those > who helped conduct the solutions analysis* were invited to the these > discussions -- with the objective of coming up with a single > consolidated proposal to bring to the WG. (I/Lou acted as facilitator > as Kent and Juergen were and are involved with the technical details.) >=20 > The discussions have yielded some results but, unfortunately, > not a single consolidated proposal as hoped, but rather two > alternate directions -- and clearly we need to choose one: >=20 > 1) Adopt the conventions for representing state/config > based on Section 6 of [1]. >=20 > =46rom a model definition perspective, these conventions > impact every model and every model writer. >=20 > 2) Model OpState using a revised logical datastore definition > as introduced in [4] and also covered in [5]. There is > also a variant of this that we believe doesn't significantly > impact this choice. >=20 > With this approach, model definitions need no explicit > changes to support applied configuration. >=20 > >=46rom a technology/WG standpoint, we believe an approach > that doesn't impact every model written (i.e., #2) is superior. > The counterpoint to this is that the conventions based > approach (i.e., #1) is available today and being followed in > OpenConfig defined models. >=20 > We would like to hear opinions on this from the WG before > declaring one of the following as the WG direction: >=20 > A) models that wish to support applied configuration MUST > follow conventions based on [1] -- and the WG needs to > formalize these conventions. > or > B) no explicit support is required for models to support > applied configuration -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. >=20 > We intend to close on this choice before Berlin. >=20 > Thank you, > Lou (and co-chairs) >=20 > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 = > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 = > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 = > [4] = https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 = > [5] = https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 = > * - Chris H. and Acee L. >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_629A6F6B-7FBE-4B31-B5FA-C6F0AD72AFB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 (a.k.a. support option B)

On = Jun 7, 2016, at 9:23 AM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

I prefer (B).
I do not think it is = realistic that vendors will rewrite their IETF
modules and vendor modules and all the associated = client/server instrumentation.
This is expensive at = many levels. Stability is important for an API.

So if we do (A), there will be some = modules following the convention
and the rest using = proprietary RPC-based solutions.
But if we do (B), = vendors can integrate the standard RPC-based solution
into their existing running code with zero = disturbance.

Andy



On Tue, = Jun 7, 2016 at 7:19 AM, Lou Berger <lberger@labn.net> wrote:
All,

We want to provide an update based on the off line discussions
related to OpState Solutions that we have been having and solicit
input from the WG.

All authors of current solution drafts [1,2,3] together with those
who helped conduct the solutions analysis* were invited to the these
discussions -- with the objective of coming up with a single
consolidated proposal to bring to the WG. (I/Lou acted as facilitator
as Kent and Juergen were and are involved with the technical = details.)

The discussions have yielded some results but, unfortunately,
not a single consolidated proposal as hoped, but rather two
= alternate directions -- and clearly we need to choose one:

    1) Adopt the conventions for representing state/config
       based on Section 6 of [1].

       =46rom a model definition perspective, these = conventions
       impact every model and every model writer.

    2) Model OpState using a revised logical datastore = definition
       as introduced in [4] and also covered in [5]. = There is
       also a variant of this that we believe = doesn't significantly
       impact this choice.

       With this approach, model definitions need no = explicit
       changes to support applied configuration.

>=46rom a technology/WG standpoint, we believe an approach
that doesn't impact every model written (i.e., #2) is superior.
The counterpoint to this is that the conventions based
approach (i.e., #1) is available today and being followed in
OpenConfig defined models.

We would like to hear opinions on this from the WG before
declaring one of the following as the WG direction:

    A) models that wish to support applied configuration = MUST
       follow conventions based on [1] -- and the WG = needs to
       formalize these conventions.
or
    B) no explicit support is required for models to = support
       applied configuration -- and that the WG = needs to
       formalize an opstate solution based on the = approach
       discussed in [4] and [5].

We intend to close on this choice before Berlin.

Thank you,
Lou (and co-chairs)

[1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01<= /a>
[2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02=
[3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02=
[4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datast= ores-00
[5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datasto= res-00
* - Chris H. and Acee L.


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

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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_629A6F6B-7FBE-4B31-B5FA-C6F0AD72AFB1-- From nobody Wed Jun 15 10:58:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84BE12B00A; Wed, 15 Jun 2016 10:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 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=-1.426, 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=lucidvision.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 TCmrw9rXQt_p; Wed, 15 Jun 2016 10:58:20 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 58A3C12D0B1; Wed, 15 Jun 2016 10:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1466013431; bh=KlkSR/fIsoo4hiMvgUl4ZoDszCXRHlOJ6txKu4u6SE4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=mbsMO0T9ekrXS0rRQTUHFCK6xjFgMsWcqkcWf6MoXvT9potr1/q8n+fnp9DZ+rFYD +wG96m+z0yrW9YXr6aXw87czrRER/KRf6Yjl0gR98ph7q/mO1S1put/TSUKE/+Vnb1 cVMkN87kR7onDFat4H1x8YCLNIQy65Y1UyXq43zQ= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Nadeau Thomas In-Reply-To: <15553a2f360.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Wed, 15 Jun 2016 13:57:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <4625_1465978919_57611027_4625_9236_1_9E32478DFA9976438E7A22F69B08FF921BC5E7FD@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <15553a2f360.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: Berger Lou X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=4 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 397, in=3921, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: netmod-chairs@ietf.org, netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 17:58:22 -0000 Lou, Given the wide-ranging impact of this sort of decision across = not just the IETF, let me suggest that it might be a good idea to get = data points from a sample that is a bit larger than 4 or 5. Forwarding = this query to some other relevant WGs might be in order given the lack = luster responses to-date. =E2=80=94Tom > On Jun 15, 2016:6:37 AM, at 6:37 AM, Lou Berger = wrote: >=20 > Stephane, >=20 > Response has been a bit light, albeit all for (B). I'm hoping we'd = here from some additional WG participants - so we need a little bit more = time. I'm still expecting for this discussion to be closed before = Berlin. >=20 > Also, can we infer from you message that you are also in favor of (B)? >=20 > Thanks, > Lou >=20 >=20 > On June 15, 2016 4:22:27 AM wrote: >=20 >> Hi Lou, chairs, >>=20 >> Based on the feedback on the list, could we conclude that we go to B) = or do you want to wait more ? >> We would like to close work on multiple YANG models, and today ops = state are blocking ... would be good to close it asap. >>=20 >> Best Regards, >>=20 >> Stephane >>=20 >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger >> Sent: Tuesday, June 07, 2016 16:20 >> To: netmod WG >> Cc: netmod-chairs@ietf.org >> Subject: [netmod] Opstate solutions discussions: update and request = for WG input >>=20 >> All, >>=20 >> We want to provide an update based on the off line discussions = related to OpState Solutions that we have been having and solicit input = from the WG. >>=20 >> All authors of current solution drafts [1,2,3] together with those = who helped conduct the solutions analysis* were invited to the these = discussions -- with the objective of coming up with a single = consolidated proposal to bring to the WG. (I/Lou acted as facilitator as = Kent and Juergen were and are involved with the technical details.) >>=20 >> The discussions have yielded some results but, unfortunately, not a = single consolidated proposal as hoped, but rather two alternate = directions -- and clearly we need to choose one: >>=20 >> 1) Adopt the conventions for representing state/config >> based on Section 6 of [1]. >>=20 >> =46rom a model definition perspective, these conventions >> impact every model and every model writer. >>=20 >> 2) Model OpState using a revised logical datastore definition >> as introduced in [4] and also covered in [5]. There is >> also a variant of this that we believe doesn't significantly >> impact this choice. >>=20 >> With this approach, model definitions need no explicit >> changes to support applied configuration. >>=20 >>> =46rom a technology/WG standpoint, we believe an approach >> that doesn't impact every model written (i.e., #2) is superior. >> The counterpoint to this is that the conventions based approach = (i.e., #1) is available today and being followed in OpenConfig defined = models. >>=20 >> We would like to hear opinions on this from the WG before declaring = one of the following as the WG direction: >>=20 >> A) models that wish to support applied configuration MUST >> follow conventions based on [1] -- and the WG needs to >> formalize these conventions. >> or >> B) no explicit support is required for models to support >> applied configuration -- and that the WG needs to >> formalize an opstate solution based on the approach >> discussed in [4] and [5]. >>=20 >> We intend to close on this choice before Berlin. >>=20 >> Thank you, >> Lou (and co-chairs) >>=20 >> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 >> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 >> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 >> [4] = https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 >> [5] = https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 >> * - Chris H. and Acee L. >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> = __________________________________________________________________________= _______________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or = privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >>=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jun 15 14:22:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9278F12DBE5 for ; Wed, 15 Jun 2016 14:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, 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 S4YAIJvZxjgT for ; Wed, 15 Jun 2016 14:22:42 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 6E27C12D9A5 for ; Wed, 15 Jun 2016 14:22:42 -0700 (PDT) Received: (qmail 26757 invoked by uid 0); 15 Jun 2016 21:22:41 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 15 Jun 2016 21:22:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 79Nd1t0142SSUrH019NgUb; Wed, 15 Jun 2016 15:22:41 -0600 X-Authority-Analysis: v=2.1 cv=KpLehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=wU2YTnxGAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8 a=fBlE_gRKDDhd5a5y39wA:9 a=2jhcaZtFbpWcobKp:21 a=1EmJTEYOfYrIgGf7:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=RmrFvp9qXTL7MAzcxlte: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; bh=6EDpAPMCDr9jLxITUyMptIvf1Yk6N7l1OIBnggzjnc4=; b=iNbbHagYWtxpLtvMGfWMGvGqaS +ANmTyG5ZVJ+fK74NN4FnRBa21G+kz6em3jRxc4kcJR7xUX3ToU2wrotImDatDb5WUTUcUcuudaLt tMnhc4WEJJy5XGLJRNAZZE0RH; Received: from box313.bluehost.com ([69.89.31.113]:41148 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bDIGj-0001gv-KC; Wed, 15 Jun 2016 15:22:37 -0600 To: Nadeau Thomas References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <4625_1465978919_57611027_4625_9236_1_9E32478DFA9976438E7A22F69B08FF921BC5E7FD@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <15553a2f360.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Lou Berger Message-ID: <28416dec-1e7c-3840-c189-e6a2f130e3df@labn.net> Date: Wed, 15 Jun 2016 17:22:31 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod-chairs@ietf.org, netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 21:22:45 -0000 Agreed and already forwarded to the routing area yang coordination list. would you suggest any other lists? Lou On 6/15/2016 1:57 PM, Nadeau Thomas wrote: > Lou, > > Given the wide-ranging impact of this sort of decision across not just the IETF, let me suggest that it might be a good idea to get data points from a sample that is a bit larger than 4 or 5. Forwarding this query to some other relevant WGs might be in order given the lack luster responses to-date. > > —Tom > > >> On Jun 15, 2016:6:37 AM, at 6:37 AM, Lou Berger wrote: >> >> Stephane, >> >> Response has been a bit light, albeit all for (B). I'm hoping we'd here from some additional WG participants - so we need a little bit more time. I'm still expecting for this discussion to be closed before Berlin. >> >> Also, can we infer from you message that you are also in favor of (B)? >> >> Thanks, >> Lou >> >> >> On June 15, 2016 4:22:27 AM wrote: >> >>> Hi Lou, chairs, >>> >>> Based on the feedback on the list, could we conclude that we go to B) or do you want to wait more ? >>> We would like to close work on multiple YANG models, and today ops state are blocking ... would be good to close it asap. >>> >>> Best Regards, >>> >>> Stephane >>> >>> -----Original Message----- >>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger >>> Sent: Tuesday, June 07, 2016 16:20 >>> To: netmod WG >>> Cc: netmod-chairs@ietf.org >>> Subject: [netmod] Opstate solutions discussions: update and request for WG input >>> >>> All, >>> >>> We want to provide an update based on the off line discussions related to OpState Solutions that we have been having and solicit input from the WG. >>> >>> All authors of current solution drafts [1,2,3] together with those who helped conduct the solutions analysis* were invited to the these discussions -- with the objective of coming up with a single consolidated proposal to bring to the WG. (I/Lou acted as facilitator as Kent and Juergen were and are involved with the technical details.) >>> >>> The discussions have yielded some results but, unfortunately, not a single consolidated proposal as hoped, but rather two alternate directions -- and clearly we need to choose one: >>> >>> 1) Adopt the conventions for representing state/config >>> based on Section 6 of [1]. >>> >>> From a model definition perspective, these conventions >>> impact every model and every model writer. >>> >>> 2) Model OpState using a revised logical datastore definition >>> as introduced in [4] and also covered in [5]. There is >>> also a variant of this that we believe doesn't significantly >>> impact this choice. >>> >>> With this approach, model definitions need no explicit >>> changes to support applied configuration. >>> >>>> From a technology/WG standpoint, we believe an approach >>> that doesn't impact every model written (i.e., #2) is superior. >>> The counterpoint to this is that the conventions based approach (i.e., #1) is available today and being followed in OpenConfig defined models. >>> >>> We would like to hear opinions on this from the WG before declaring one of the following as the WG direction: >>> >>> A) models that wish to support applied configuration MUST >>> follow conventions based on [1] -- and the WG needs to >>> formalize these conventions. >>> or >>> B) no explicit support is required for models to support >>> applied configuration -- and that the WG needs to >>> formalize an opstate solution based on the approach >>> discussed in [4] and [5]. >>> >>> We intend to close on this choice before Berlin. >>> >>> Thank you, >>> Lou (and co-chairs) >>> >>> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 >>> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 >>> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 >>> [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 >>> [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 >>> * - Chris H. and Acee L. >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> _________________________________________________________________________________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>> Thank you. >>> >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Jun 16 01:33:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AF712B005 for ; Thu, 16 Jun 2016 01:33:38 -0700 (PDT) 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, 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 b8tGLk-ycEfM for ; Thu, 16 Jun 2016 01:33:37 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA18612B018 for ; Thu, 16 Jun 2016 01:33:36 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-16-5762645edf1a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 51.2D.12516.E5462675; Thu, 16 Jun 2016 10:33:34 +0200 (CEST) Received: from [159.107.197.135] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.294.0; Thu, 16 Jun 2016 10:33:33 +0200 To: "netmod@ietf.org" , =?UTF-8?B?QmFsw6F6cyBLb3bDoWNz?= From: Balazs Lengyel Message-ID: <95c39a63-b9ec-e006-87f6-70443c4c726b@ericsson.com> Date: Thu, 16 Jun 2016 10:33:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM2K7q25cSlK4wcRuS4v5FxtZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXfJLOaC22wVPz58Zm9gvMrSxcjJISFgInHndh8bhC0mceHe ejBbSOAIo8Sad3EQ9lpGiXVHfEBsEYEMid+fH7CC2GwCRhJT+8+DzREWsJa4f2QSI4jNK2Av cf/gT7AaFgFVif4vC8BmigrESDTePswOUSMocXLmE7BeZgELiZnzzzNC2PIS29/OYYbYqyHx 8MJf1gmMfLOQtMxC0jILScsCRuZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIEBdXDLb90d jKtfOx5iFOBgVOLhfXA+MVyINbGsuDL3EKMEB7OSCO/GhKRwId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rz+LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYycwZmv/kWZeXx3KU/yf1LaHibYVqd25vz1 JtbiyjbneZXOublnFy79u2xb/obCUwvU3onIstjJ1k01cnuwZoPtP07DL69c6yby3nn0d03d YaPQ+izerA2LrsW/e3Zi3/X7+9m2P50/jdk7TtzIRezUzmrjX6vMLNk79/sdneFlmZu8ZvKS lsdKLMUZiYZazEXFiQDFDUn+JAIAAA== Archived-At: Subject: [netmod] Must on actions without input or output parameters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 08:33:39 -0000 Hello, We have the following model container myThing { leaf enabled { type boolean;} action start { must "../enabled = 'true'"; } } -- or -- container myThing { leaf enabled { type boolean;} action start { input { must "../enabled = 'true'"; } } } We only want to allow starting myThing (calling the start action) if it is enabled. However we - can not put a must under action according to the RFC/draft - while the RFC would allow us to put an empty input under action with only the must statement in it, pyang complains about the absence of data definition nodes. What is the solution? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Jun 16 02:34:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DB612D0E0 for ; Thu, 16 Jun 2016 02:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6K9c0O5UaAU for ; Thu, 16 Jun 2016 02:33:56 -0700 (PDT) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id F140412D19F for ; Thu, 16 Jun 2016 02:33:51 -0700 (PDT) Received: from jernejthpPC (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 6AF80C417621 for ; Thu, 16 Jun 2016 11:33:50 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si 6AF80C417621 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1466069630; bh=Gzeg2X/LmfO7Vo3m7pYgzRP+vxFxOkwbkzfK2gQXAWI=; h=From:To:Subject:Date:From; b=iKAa8NiIHH0YXM3HSy88uqm2Wtrkh/hZic1d0+CohFc1YmZ7IPOQu4cGstwrSYxBx 2dBdA4kpzAZSlZ/f9kUu0Wj6mqW7VwBkkgyAR8z7FgLUDY71Lv4rJHkY0UtL6T2ztV 3Kp0UWxc4+EkRcpNI2yfkqZYtaPrcJZKWVm30BokZEEXtLaROIem4LWpuXZSMbbsHp GTraWkBTjF8vnRL5GqJC0iYBgoHcv98oe6mhZJGlORhaHawL90b5UYl9UsKBKV/+nP /5YEwyVjzKiJIl3Nq7SNn8L832p62gTkS/Vp1Bgr9yoLo1lkFMJdpScMlaTFLRAPaQ 6XHnas/YZp5yQ== From: "Jernej Tuljak" To: Date: Thu, 16 Jun 2016 11:33:49 +0200 Message-ID: <038301d1c7b2$2fdb43a0$8f91cae0$@mg-soft.si> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0384_01D1C7C2.F364AFE0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdHHsdaPNrrT6z2URjGS9HHgwJ60iA== Content-Language: sl Archived-At: Subject: [netmod] Can a grouping be defined to contain a 'list' with a 'key' but no key 'leaf' definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 09:33:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0384_01D1C7C2.F364AFE0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've had an interesting discussion on Stackoverflow whether the = following is a valid grouping definition. =20 grouping my-grouping { container foos { list foo { key name; } } } =20 Note that the key leaf is missing and is neither specified as a direct = child nor via grouping usage inside the list. I argued that it is valid = since the missing key leaf may be augmented at a later time upon = grouping usage, but have failed to produce RFC text that would = explicitly say so. In fact 6020bis-13 says the following in 7.8.2.: =20 Each such leaf identifier MUST refer to a child leaf of the list. The leafs can be defined directly in substatements to the list, or in groupings used in the list. =20 So is this a valid grouping definition or would a compliant YANG = compiler reject it with an error (pyang seems to allow it, so does our = implementation). The same text is in RFC6020 and seems to suggest that = the above is not allowed. Is this intentional? =20 I=E2=80=99m not asking whether doing this is good or bad practice. =20 Jernej ------=_NextPart_000_0384_01D1C7C2.F364AFE0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I've had an interesting discussion = on Stackoverflow whether the following is a valid grouping = definition.

 

=C2=A0 grouping my-grouping {

=C2=A0=C2=A0=C2=A0 container foos = {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 list foo = {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key = name;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0 = }

=C2=A0 = }

 

Note that the key leaf is missing and is neither specified = as a direct child nor via grouping usage inside the list. I argued that = it is valid since the missing key leaf may be augmented at a later time = upon grouping usage, but have failed to produce RFC text that would = explicitly say so. In fact 6020bis-13 says the following in = 7.8.2.:

 

Each =
such leaf identifier MUST refer to a
=C2=A0=C2=A0 child leaf of the list.=C2=A0 The leafs can be =
defined directly in
=C2=A0=C2=A0 substatements to the list, or in groupings =
used in the list.

 

So is this a valid grouping definition or would a compliant = YANG compiler reject it with an error (pyang seems to allow it, so does = our implementation). The same text is in RFC6020 and seems to suggest = that the above is not allowed. Is this = intentional?

 

I=E2=80=99m not asking whether doing this is good or bad = practice.

 

Jernej

------=_NextPart_000_0384_01D1C7C2.F364AFE0-- From nobody Thu Jun 16 02:42:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A25512B007 for ; Thu, 16 Jun 2016 02:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 PQPio2d6MEON for ; Thu, 16 Jun 2016 02:42:21 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7551612D1B1 for ; Thu, 16 Jun 2016 02:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2869; q=dns/txt; s=iport; t=1466069657; x=1467279257; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=6WFwTzJt083GROJNLXSF4FvxBzKuraQaEkpnghULWcg=; b=P6cxlj0mEbfiHI3ng1mdZhvm0u0mIMvaxVq9f2d+uMOsBJphcYoWf9iA nuPONE5Bf4Rafq/vH3fkdSr89bpRMf2RJpJNx10UjZz2n/AR8KdAwLs63 gCk6mux+4K0Fe22W2eQwQsb+aIx0zwLUxRfujxJ/dy1VgrHT0quNfDmM0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAAscWJX/xbLJq1dhBQrUrxVFwuFK?= =?us-ascii?q?0oCgXIBAQEBAQFmJ4RMAQEEAQEBNTYbCw4KLicwBgEMBgIBAReIFQ6/SwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBARoFhieBd4JWgSKIeQWYcIYFiCSBaYdchV2GTYknVINwO?= =?us-ascii?q?zKKBAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,478,1459814400"; d="scan'208";a="638046620" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2016 09:34:15 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u5G9YE64023543; Thu, 16 Jun 2016 09:34:15 GMT To: Lou Berger , netmod WG References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> From: Robert Wilton Message-ID: Date: Thu, 16 Jun 2016 10:34:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 09:42:22 -0000 For the record, I also think that B is the right choice. Rob On 07/06/2016 15:19, Lou Berger wrote: > All, > > We want to provide an update based on the off line discussions > related to OpState Solutions that we have been having and solicit > input from the WG. > > All authors of current solution drafts [1,2,3] together with those > who helped conduct the solutions analysis* were invited to the these > discussions -- with the objective of coming up with a single > consolidated proposal to bring to the WG. (I/Lou acted as facilitator > as Kent and Juergen were and are involved with the technical details.) > > The discussions have yielded some results but, unfortunately, > not a single consolidated proposal as hoped, but rather two > alternate directions -- and clearly we need to choose one: > > 1) Adopt the conventions for representing state/config > based on Section 6 of [1]. > > From a model definition perspective, these conventions > impact every model and every model writer. > > 2) Model OpState using a revised logical datastore definition > as introduced in [4] and also covered in [5]. There is > also a variant of this that we believe doesn't significantly > impact this choice. > > With this approach, model definitions need no explicit > changes to support applied configuration. > > >From a technology/WG standpoint, we believe an approach > that doesn't impact every model written (i.e., #2) is superior. > The counterpoint to this is that the conventions based > approach (i.e., #1) is available today and being followed in > OpenConfig defined models. > > We would like to hear opinions on this from the WG before > declaring one of the following as the WG direction: > > A) models that wish to support applied configuration MUST > follow conventions based on [1] -- and the WG needs to > formalize these conventions. > or > B) no explicit support is required for models to support > applied configuration -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. > > We intend to close on this choice before Berlin. > > Thank you, > Lou (and co-chairs) > > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > * - Chris H. and Acee L. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Thu Jun 16 03:02:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C154612B05D for ; Thu, 16 Jun 2016 03:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 4xbIZiOBkfvE for ; Thu, 16 Jun 2016 03:01:58 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1663112B058 for ; Thu, 16 Jun 2016 03:01:58 -0700 (PDT) Received: from localhost (h-46-190.a165.priv.bahnhof.se [46.59.46.190]) by mail.tail-f.com (Postfix) with ESMTPSA id EEC5B1AE018A; Thu, 16 Jun 2016 12:01:56 +0200 (CEST) Date: Thu, 16 Jun 2016 12:01:56 +0200 (CEST) Message-Id: <20160616.120156.494034726439863633.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <038301d1c7b2$2fdb43a0$8f91cae0$@mg-soft.si> References: <038301d1c7b2$2fdb43a0$8f91cae0$@mg-soft.si> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Can a grouping be defined to contain a 'list' with a 'key' but no key 'leaf' definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 10:02:00 -0000 Ikplcm5laiBUdWxqYWsiIDxqZXJuZWoudHVsamFrQG1nLXNvZnQuc2k+IHdyb3RlOg0KPiBJJ3Zl IGhhZCBhbiBpbnRlcmVzdGluZyBkaXNjdXNzaW9uIG9uIFN0YWNrb3ZlcmZsb3cgd2hldGhlciB0 aGUNCj4gZm9sbG93aW5nIGlzIGEgdmFsaWQgZ3JvdXBpbmcgZGVmaW5pdGlvbi4NCj4gDQo+ICAN Cj4gDQo+ICAgZ3JvdXBpbmcgbXktZ3JvdXBpbmcgew0KPiANCj4gICAgIGNvbnRhaW5lciBmb29z IHsNCj4gDQo+ICAgICAgIGxpc3QgZm9vIHsNCj4gDQo+ICAgICAgICAga2V5IG5hbWU7DQo+IA0K PiAgICAgICB9DQo+IA0KPiAgICAgfQ0KPiANCj4gICB9DQo+IA0KPiAgDQo+IA0KPiBOb3RlIHRo YXQgdGhlIGtleSBsZWFmIGlzIG1pc3NpbmcgYW5kIGlzIG5laXRoZXIgc3BlY2lmaWVkIGFzIGEg ZGlyZWN0DQo+IGNoaWxkIG5vciB2aWEgZ3JvdXBpbmcgdXNhZ2UgaW5zaWRlIHRoZSBsaXN0LiBJ IGFyZ3VlZCB0aGF0IGl0IGlzDQo+IHZhbGlkIHNpbmNlIHRoZSBtaXNzaW5nIGtleSBsZWFmIG1h eSBiZSBhdWdtZW50ZWQgYXQgYSBsYXRlciB0aW1lIHVwb24NCj4gZ3JvdXBpbmcgdXNhZ2UsIGJ1 dCBoYXZlIGZhaWxlZCB0byBwcm9kdWNlIFJGQyB0ZXh0IHRoYXQgd291bGQNCj4gZXhwbGljaXRs eSBzYXkgc28uIEluIGZhY3QgNjAyMGJpcy0xMyBzYXlzIHRoZSBmb2xsb3dpbmcgaW4gNy44LjIu Og0KPiANCj4gIA0KPiANCj4gRWFjaCBzdWNoIGxlYWYgaWRlbnRpZmllciBNVVNUIHJlZmVyIHRv IGENCj4gICAgY2hpbGQgbGVhZiBvZiB0aGUgbGlzdC4gIFRoZSBsZWFmcyBjYW4gYmUgZGVmaW5l ZCBkaXJlY3RseSBpbg0KPiAgICBzdWJzdGF0ZW1lbnRzIHRvIHRoZSBsaXN0LCBvciBpbiBncm91 cGluZ3MgdXNlZCBpbiB0aGUgbGlzdC4NCg0KSSB0aGluayB0aGlzIHRleHQgY2xlYXJseSBzdGF0 ZXMgdGhhdCB0aGUgZXhhbXBsZSBhYm92ZSBpcyBpbGxlZ2FsLg0KDQoNCi9tYXJ0aW4NCg0KDQoN Cj4gDQo+ICANCj4gDQo+IFNvIGlzIHRoaXMgYSB2YWxpZCBncm91cGluZyBkZWZpbml0aW9uIG9y IHdvdWxkIGEgY29tcGxpYW50IFlBTkcNCj4gY29tcGlsZXIgcmVqZWN0IGl0IHdpdGggYW4gZXJy b3IgKHB5YW5nIHNlZW1zIHRvIGFsbG93IGl0LCBzbyBkb2VzIG91cg0KPiBpbXBsZW1lbnRhdGlv bikuIFRoZSBzYW1lIHRleHQgaXMgaW4gUkZDNjAyMCBhbmQgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0 DQo+IHRoZSBhYm92ZSBpcyBub3QgYWxsb3dlZC4gSXMgdGhpcyBpbnRlbnRpb25hbD8NCj4gDQo+ ICANCj4gDQo+IEnigJltIG5vdCBhc2tpbmcgd2hldGhlciBkb2luZyB0aGlzIGlzIGdvb2Qgb3Ig YmFkIHByYWN0aWNlLg0KPiANCj4gIA0KPiANCj4gSmVybmVqDQo+IA0K From nobody Thu Jun 16 05:04:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8C612D532 for ; Thu, 16 Jun 2016 05:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 hAcXvKX3_QKs for ; Thu, 16 Jun 2016 05:04:36 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AE512D531 for ; Thu, 16 Jun 2016 05:04:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B5B3CA99 for ; Thu, 16 Jun 2016 14:04:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yrkLd6z5GN2G for ; Thu, 16 Jun 2016 14:04:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 16 Jun 2016 14:04:32 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B965A20054 for ; Thu, 16 Jun 2016 14:04:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id G8rXFSZoeIu4; Thu, 16 Jun 2016 14:04:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C73D320047; Thu, 16 Jun 2016 14:04:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D87C13B26710; Thu, 16 Jun 2016 14:04:30 +0200 (CEST) Date: Thu, 16 Jun 2016 14:04:30 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20160616120430.GA32909@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20160610110640.GA16061@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160610110640.GA16061@elstar.local> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] YANG 1.1 final review of the edits resulting from the IESG process X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 12:04:38 -0000 On Fri, Jun 10, 2016 at 01:06:42PM +0200, Juergen Schoenwaelder wrote: > Hi, > > Martin has posted revision -13 of the YANG 1.1 specification. This > revision incorporates all comments that we have received during the > IESG process. A big thanks in particular to our gen-art and ops-dir > reviewers and to Martin for following up on the issues. Please check > the edits do make sure that nothing broke. The diff can be found > here: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-13.txt > > Note that this is _not_ the time to raise new issues or to suggest > alternate resolutions to issues discussed before. This is only a check > to verify that the edits were done correctly. Please check the edits > as soon as possible, any errors found must be raised by Thursday > 2016-06-16. I just finished my review of the changes. Things look pretty good to me. I found a little nit though: There is no ambiguity if both modules define the type, since there is no ambiguity. This sentence can likely be removed without loosing anything (but it also does not cause any harm). /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 Jun 16 05:43:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76536128E19 for ; Thu, 16 Jun 2016 05:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 jSn70G1dFu9D for ; Thu, 16 Jun 2016 05:43:16 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 060A312D5AB for ; Thu, 16 Jun 2016 05:43:12 -0700 (PDT) Received: from localhost (h-46-190.a165.priv.bahnhof.se [46.59.46.190]) by mail.tail-f.com (Postfix) with ESMTPSA id 208081AE018A; Thu, 16 Jun 2016 14:43:12 +0200 (CEST) Date: Thu, 16 Jun 2016 14:43:12 +0200 (CEST) Message-Id: <20160616.144312.301635247378980634.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160616120430.GA32909@elstar.local> References: <20160610110640.GA16061@elstar.local> <20160616120430.GA32909@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 final review of the edits resulting from the IESG process X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 12:43:17 -0000 Juergen Schoenwaelder wrote: > On Fri, Jun 10, 2016 at 01:06:42PM +0200, Juergen Schoenwaelder wrote: > > Hi, > > > > Martin has posted revision -13 of the YANG 1.1 specification. This > > revision incorporates all comments that we have received during the > > IESG process. A big thanks in particular to our gen-art and ops-dir > > reviewers and to Martin for following up on the issues. Please check > > the edits do make sure that nothing broke. The diff can be found > > here: > > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-13.txt > > > > Note that this is _not_ the time to raise new issues or to suggest > > alternate resolutions to issues discussed before. This is only a check > > to verify that the edits were done correctly. Please check the edits > > as soon as possible, any errors found must be raised by Thursday > > 2016-06-16. > > I just finished my review of the changes. Things look pretty good to > me. I found a little nit though: > > There is no ambiguity if both modules define the type, since > there is no ambiguity. I'll remove the last part of this sentence. /martin > > This sentence can likely be removed without loosing anything (but it > also does not cause any harm). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Jun 16 05:53:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B053E12D14F for ; Thu, 16 Jun 2016 05:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 ttllX4hJ3EDS for ; Thu, 16 Jun 2016 05:53:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9968112D5AA for ; Thu, 16 Jun 2016 05:53:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 66B32757 for ; Thu, 16 Jun 2016 14:53:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AeqtIV7kylbC for ; Thu, 16 Jun 2016 14:53:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 16 Jun 2016 14:53:14 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71DD720056 for ; Thu, 16 Jun 2016 14:53:14 +0200 (CEST) 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 ybkcdS6fNt0B; Thu, 16 Jun 2016 14:53:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A0B1920047; Thu, 16 Jun 2016 14:53:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 95A0E3B26ADA; Thu, 16 Jun 2016 14:53:13 +0200 (CEST) Date: Thu, 16 Jun 2016 14:53:13 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20160616125313.GA33106@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20160610110640.GA16061@elstar.local> <44045A0D-6C6F-49CE-B21C-E29EBA37BB21@nic.cz> <20160610.154827.552634417076173871.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160610.154827.552634417076173871.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] YANG 1.1 final review of the edits resulting from the IESG process X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 12:53:20 -0000 On Fri, Jun 10, 2016 at 03:48:27PM +0200, Martin Bjorklund wrote: > > - The second paragraph then says: > > > > If the "require-instance" property (Section 9.9.3) is "true", > > there MUST exist an node in the data tree, or a node with a > > default value in use (see Section 7.6.1 and Section 7.7.2), > > of the referred schema tree leaf or leaf-list node with the > > same value as the leafref value in a valid data tree. > > > > IMO this means that *any* instance of the referred leaf or leaf-list > > schema node would do, whereas in fact the instance must belong to the > > node set resulting from the "path" expression (evaluated as XPath). In > > other words, if the "path" statement selects a specific list entry via > > path predicate, the required instance must be in this entry. Perhaps the text is not perfect but since section 9.9.2 clarifies how this works we won't change the paragraph. > Note that the text for "path" provides further details: > > The "path" expression evaluates to a node set consisting of zero, > one, or more nodes. If the leaf with the leafref type represents > configuration data, this node set MUST be non-empty. > > However, this part is not correct in YANG 1.1 :( It would be more > correct to say: > > NEW: > > The "path" expression evaluates to a node set consisting of zero, > one, or more nodes. If the "require-instance" property is "true", > this node set MUST be non-empty. This is indeed a bug and Martin's NEW text will be incorporated to fix the bug. /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 Jun 16 06:09:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF4512B01E for ; Thu, 16 Jun 2016 06:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 6HbnVMM9AXZh for ; Thu, 16 Jun 2016 06:09:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A826612D576 for ; Thu, 16 Jun 2016 06:09:22 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:86c:194f:53da:e4f7] (unknown [IPv6:2001:718:1a02:1:86c:194f:53da:e4f7]) by mail.nic.cz (Postfix) with ESMTPSA id 53DD360964; Thu, 16 Jun 2016 15:09:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466082561; bh=3rc45bUTiVEDlFqVITNHOjIC/k941DJzeRte9W6/Emc=; h=From:Date:To; b=wdYrIjarJWCqyxuwgwi6pR9LxFXDw2XSnJR+NwQhLSe0S194dUUa9D1abebAl3CK1 /Rr7sF6Da2NL2GgRh1vc3eKRYTsfkpMXCW+gqtYYvrYMvkICBSmT57T6kJcQSVGvNW 5L1e56Tux6E+W1xbSIKrNGNMn6aNcAOaEwBFHeeY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160616.120156.494034726439863633.mbj@tail-f.com> Date: Thu, 16 Jun 2016 15:09:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C15C9A8-99F6-4075-9757-3AEF04771122@nic.cz> References: <038301d1c7b2$2fdb43a0$8f91cae0$@mg-soft.si> <20160616.120156.494034726439863633.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Can a grouping be defined to contain a 'list' with a 'key' but no key 'leaf' definition? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 13:09:27 -0000 > On 16 Jun 2016, at 12:01, Martin Bjorklund wrote: >=20 > "Jernej Tuljak" wrote: >> I've had an interesting discussion on Stackoverflow whether the >> following is a valid grouping definition. >>=20 >>=20 >>=20 >> grouping my-grouping { >>=20 >> container foos { >>=20 >> list foo { >>=20 >> key name; >>=20 >> } >>=20 >> } >>=20 >> } >>=20 >>=20 >>=20 >> Note that the key leaf is missing and is neither specified as a = direct >> child nor via grouping usage inside the list. I argued that it is >> valid since the missing key leaf may be augmented at a later time = upon >> grouping usage, but have failed to produce RFC text that would >> explicitly say so. In fact 6020bis-13 says the following in 7.8.2.: >>=20 >>=20 >>=20 >> Each such leaf identifier MUST refer to a >> child leaf of the list. The leafs can be defined directly in >> substatements to the list, or in groupings used in the list. >=20 > I think this text clearly states that the example above is illegal. Then it would perhaps be better to say OLD The leafs can be defined directly in substatements to the list, or in groupings used in the list. NEW The leafs MUST be defined either directly in substatements to the = list, or in groupings used in the list. Lada >=20 > /martin >=20 >=20 >=20 >>=20 >>=20 >>=20 >> So is this a valid grouping definition or would a compliant YANG >> compiler reject it with an error (pyang seems to allow it, so does = our >> implementation). The same text is in RFC6020 and seems to suggest = that >> the above is not allowed. Is this intentional? >>=20 >>=20 >>=20 >> I=E2=80=99m not asking whether doing this is good or bad practice. >>=20 >>=20 >>=20 >> Jernej >>=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 16 06:12:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A7412D5BC for ; Thu, 16 Jun 2016 06:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj8cHc1aLxWj for ; Thu, 16 Jun 2016 06:12:44 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 8343B128E19 for ; Thu, 16 Jun 2016 06:12:40 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id j2so72381079vkg.2 for ; Thu, 16 Jun 2016 06:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5JPQlKOsKoO+TOghYH7YfAqxftqEvqgRhJ5ntOklvd4=; b=Eb3OyZuWWtKcj0F7jhCWHhSlBg57M503xo3PBXcboCcI8uzeSMzcK6tRwPC7NGiEfT ieHJm35/JCdxCZBg5BfcdzFjmhxdcNt+DoHeBNZJAuB6Xb9ixWUl+3Sytod3CWzfUqN3 R+9QBdAiaFnLpYawTR9hvc01xyHVVqF6237HByECsk3y7y8afplEC/V2uS0nhHqzMwpi /DWhXh5SM5pCkQeLa2267j6M84rdIrNozQPBleB7TfCBzhuzy4drT/VKQeN87Pj04mT/ P3qWWvt6h3UxdVv00YWzPZhXyyFpaoGsTQ/Ni+mNtev79SBgeNTHX2Ukmxp/9I5CsMD2 MMwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5JPQlKOsKoO+TOghYH7YfAqxftqEvqgRhJ5ntOklvd4=; b=FyugeSvClWAjVLXcWwpTMD3BHClRwMMBxCPyBv+rVseu0o/b13OgxQmCeDWYvE2dsh LYhSuN1mq6JCpHKHRgTMXVhx74PbgcPl/OikH+/DEBCbhuMBv+De84bN76LLBnhWSVQK aMaqXjmtKUAKFT8bcor579mhvlsmov3y7sWKXLpVmfzEwIJR97VKLLxTtIB/zedIR2j1 cb49e9d8UngKrK+QwDVRKIdr+NELC2u/bmppoXrUTkWkmNWkY0E1GP+gdk5lJ+3ftyom bwNh9C9h3s9laImVP6g6WPFAJRfLpbk4JOp4dBYWnCMehRDJ+cpaQBk4NmY5lC56q0j1 yJYQ== X-Gm-Message-State: ALyK8tI/urtWIHWGbIDPr/JHzzEWkbcOA8aWCXpIRe+QFGJr6J/9LmRq2q2ONIu7oPNp0sPoLwohAxMIO3cdxw== MIME-Version: 1.0 X-Received: by 10.159.35.72 with SMTP id 66mr2062781uae.55.1466082755947; Thu, 16 Jun 2016 06:12:35 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Thu, 16 Jun 2016 06:12:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Jun 2016 06:12:35 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11353092e147cc053564fd4e Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 13:12:46 -0000 --001a11353092e147cc053564fd4e Content-Type: text/plain; charset=UTF-8 On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka wrote: > > > On 13 Jun 2016, at 16:39, Andy Bierman wrote: > > > > > > > > On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > Hi, > > > > > > I am trying to implement YANG 1.1 must-stmt extensions. > > > They appear to be under-specified. > > > > > > In sec. 7.5.3 > > > > > > The XPath expression is conceptually evaluated in the following > > > context, in addition to the definition in Section 6.4.1 > > > < > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-13#section-6.4.1 > >: > > > > > > o The context node is the node in the accessible tree for which the > > > "must" statement is defined. > > > > > > > > > The problem for input/output is that these nodes are not encoded > > > in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines the > > > XPath context for input and output, so 7.5.3 is incorrect. > > > > > > 7.5.3 should say the context node for input/output is the node > representing > > > the RPC operation. This would be the same for NETCONF encoding of > action. > > > The RESTCONF encoding for RPC and action is completely different > > > but the definition in 7.5.3 is actually correct for RESTCONF. > > > > This should not depend on any encoding, an XPath expression is evaluated > > on a conceptual data tree, and this tree is defined for operations, too. > > > > > > > > The and nodes do not appear at all > > in the instance document for NETCONF so this bullet in 7.5.3 is wrong > > for those nodes. > > > > For , the child of is already specified > > as the child of docroot. > > OK, so this is about "must" statements specified directly under > input/output and notification statements, right? I had the same comment > previously: > > https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html > > My understanding is that in the former case the context node is the root > of the input/output data tree, and in the latter case it is the node with > the same name as the notification. > > I agree it should be better explained. > > If you already brought up this issue, then why is the text still incorrect? o The context node is the node in the accessible tree for which the > > "must" statement is defined. This text is clearly wrong for the 3 new nodes that were added (input, output, notification). Why wasn't this text corrected? > Lada > > Andy > > > > > > > > > > > > > The problem for notification is not that is not in the > > > instance document, but rather that it is not part of the XPath context: > > > > > > o If the XPath expression is defined in a substatement to a > > > "notification" statement, the accessible tree is the notification > > > instance, all state data in the server, and the running > > > configuration datastore. * If the notification is defined on the > > > top-level in a module, then the root node has the node > > > representing the notification being defined* and all top-level > data > > > nodes in all modules as children. Otherwise, the root node has > > > all top-level data nodes in all modules as children. > > > > > > > This is indeed quite incomprehensible. What's the idea here? > > > > Lada > > > > > > > > Andy > > > > > > > > The context node for should be the node representing the > > > notification. > > > > > > > > > > > > Andy > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11353092e147cc053564fd4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 13 Jun 2016, at 16:39, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > Hi,
> >
> > I am trying to implement YANG 1.1 must-stmt extensions.
> > They appear to be under-specified.
> >
> > In sec. 7.5.3
> >
> >=C2=A0 =C2=A0 The XPath expression is conceptually evaluated in th= e following
> >=C2=A0 =C2=A0 context, in addition to the definition in Section 6.= 4.1
> > <https://tools= .ietf.org/html/draft-ietf-netmod-rfc6020bis-13#section-6.4.1>:
> >
> >=C2=A0 =C2=A0 o=C2=A0 The context node is the node in the accessib= le tree for which the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"must" statement is defined.<= br> > >
> >
> > The problem for input/output is that these nodes are not encoded<= br> > > in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defin= es the
> > XPath context for input and output, so 7.5.3 is incorrect.
> >
> > 7.5.3 should say the context node for input/output is the node re= presenting
> > the RPC operation. This would be the same for NETCONF encoding of= action.
> > The RESTCONF encoding for RPC and action is completely different<= br> > > but the definition in 7.5.3 is actually correct for RESTCONF.
>
> This should not depend on any encoding, an XPath expression is evaluat= ed
> on a conceptual data tree, and this tree is defined for operations, to= o.
>
>
>
> The <input> and <output> nodes do not appear at all
> in the instance document for NETCONF so this bullet in 7.5.3 is wrong<= br> > for those nodes.
>
> For <notiofication>, the child of <notification> is alread= y specified
> as the child of docroot.

OK, so this is about "must" statements specified directly under i= nput/output and notification statements, right? I had the same comment prev= iously:

https://www.ietf.org/mail-archive/= web/netmod/current/msg14469.html

My understanding is that in the former case the context node is the root of= the input/output data tree, and in the latter case it is the node with the= same name as the notification.

I agree it should be better explained.



If you already brought = up this issue, then why is the text still incorrect?

=C2=A0o=C2=A0 The context node is the node in the accessible tree for wh= ich the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"must" statement i= s defined.

This text is clearly wrong for the = 3 new nodes that were added (input, output, notification).
Why wa= sn't this text corrected?


=C2= =A0
Lada



Andy
=C2=A0
>
>
> >
> >
> > The problem for notification is not that <notification> is = not in the
> > instance document, but rather that it is not part of the XPath co= ntext:
> >
> >=C2=A0 =C2=A0 o=C2=A0 If the XPath expression is defined in a subs= tatement to a
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0"notification" statement, the= accessible tree is the notification
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0instance, all state data in the server,= and the running
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0configuration datastore. * If the notif= ication is defined on the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0top-level in a module, then the root no= de has the node
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0representing the notification being def= ined* and all top-level data
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0nodes in all modules as children.=C2=A0= Otherwise, the root node has
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0all top-level data nodes in all modules= as children.
> >
>
> This is indeed quite incomprehensible. What's the idea here?
>
> Lada
>
>
>
> Andy
>
> >
> > The context node for <notification> should be the node repr= esenting the
> > notification.
> >
> >
> >
> > Andy
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





--001a11353092e147cc053564fd4e-- From nobody Thu Jun 16 06:28:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A33712D5F0 for ; Thu, 16 Jun 2016 06:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 fQTSKKsGo6Gb for ; Thu, 16 Jun 2016 06:28:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AA712D556 for ; Thu, 16 Jun 2016 06:28:35 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:86c:194f:53da:e4f7] (unknown [IPv6:2001:718:1a02:1:86c:194f:53da:e4f7]) by mail.nic.cz (Postfix) with ESMTPSA id DE92D607DD; Thu, 16 Jun 2016 15:28:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466083713; bh=V4gspTELtxKF6beib9jFefocPEtCyNi55WBxPZpRXUg=; h=From:Date:To; b=iFS6ilOXogNIV3eqFjdiBoaJVmYhbEgksWQRO9H6rxb6Ju2sG9Qjodd3/9s7RkV1Z D3uXwrWNQnnX6fFOGz4Zlz7V0N17f0usE4+mwkZp0BfZXvr8gRK2V5k8sfzSmrHULh GZpAzWRjPnbCJiDm7I9GsiydODnm+TFeBw7oKNmQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 16 Jun 2016 15:28:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <996ADF73-45D2-4A62-9983-014DA731702C@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 13:28:38 -0000 > On 16 Jun 2016, at 15:12, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka = wrote: >=20 > > On 13 Jun 2016, at 16:39, Andy Bierman wrote: > > > > > > > > On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka = wrote: > > Andy Bierman writes: > > > > > Hi, > > > > > > I am trying to implement YANG 1.1 must-stmt extensions. > > > They appear to be under-specified. > > > > > > In sec. 7.5.3 > > > > > > The XPath expression is conceptually evaluated in the following > > > context, in addition to the definition in Section 6.4.1 > > > = : > > > > > > o The context node is the node in the accessible tree for = which the > > > "must" statement is defined. > > > > > > > > > The problem for input/output is that these nodes are not encoded > > > in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly = defines the > > > XPath context for input and output, so 7.5.3 is incorrect. > > > > > > 7.5.3 should say the context node for input/output is the node = representing > > > the RPC operation. This would be the same for NETCONF encoding of = action. > > > The RESTCONF encoding for RPC and action is completely different > > > but the definition in 7.5.3 is actually correct for RESTCONF. > > > > This should not depend on any encoding, an XPath expression is = evaluated > > on a conceptual data tree, and this tree is defined for operations, = too. > > > > > > > > The and nodes do not appear at all > > in the instance document for NETCONF so this bullet in 7.5.3 is = wrong > > for those nodes. > > > > For , the child of is already = specified > > as the child of docroot. >=20 > OK, so this is about "must" statements specified directly under = input/output and notification statements, right? I had the same comment = previously: >=20 > https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html >=20 > My understanding is that in the former case the context node is the = root of the input/output data tree, and in the latter case it is the = node with the same name as the notification. >=20 > I agree it should be better explained. >=20 >=20 >=20 > If you already brought up this issue, then why is the text still = incorrect? The subsequent discussion convinced me that it can be easily fixed, and = then I lost it from the radar, unfortunately. Lada >=20 > o The context node is the node in the accessible tree for which the > > > "must" statement is defined. >=20 > This text is clearly wrong for the 3 new nodes that were added (input, = output, notification). > Why wasn't this text corrected? >=20 >=20 > =20 > Lada >=20 >=20 >=20 > Andy > =20 > > > > > > > > > > > > > The problem for notification is not that is not in = the > > > instance document, but rather that it is not part of the XPath = context: > > > > > > o If the XPath expression is defined in a substatement to a > > > "notification" statement, the accessible tree is the = notification > > > instance, all state data in the server, and the running > > > configuration datastore. * If the notification is defined on = the > > > top-level in a module, then the root node has the node > > > representing the notification being defined* and all = top-level data > > > nodes in all modules as children. Otherwise, the root node = has > > > all top-level data nodes in all modules as children. > > > > > > > This is indeed quite incomprehensible. What's the idea here? > > > > Lada > > > > > > > > Andy > > > > > > > > The context node for should be the node = representing the > > > notification. > > > > > > > > > > > > Andy > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 16 06:58:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1141D12D66E for ; Thu, 16 Jun 2016 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 wghIoPyn5xm0 for ; Thu, 16 Jun 2016 06:58:49 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8212D66A for ; Thu, 16 Jun 2016 06:58:49 -0700 (PDT) Received: from localhost (h-46-190.a165.priv.bahnhof.se [46.59.46.190]) by mail.tail-f.com (Postfix) with ESMTPSA id 54DE21AE018A; Thu, 16 Jun 2016 15:58:48 +0200 (CEST) Date: Thu, 16 Jun 2016 15:58:48 +0200 (CEST) Message-Id: <20160616.155848.1395296716645649051.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <996ADF73-45D2-4A62-9983-014DA731702C@nic.cz> References: <996ADF73-45D2-4A62-9983-014DA731702C@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 13:58:51 -0000 Ladislav Lhotka wrote: > > > On 16 Jun 2016, at 15:12, Andy Bierman wrote: > > > > > > > > On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka wrote: > > > > > On 13 Jun 2016, at 16:39, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka wrote: > > > Andy Bierman writes: > > > > > > > Hi, > > > > > > > > I am trying to implement YANG 1.1 must-stmt extensions. > > > > They appear to be under-specified. > > > > > > > > In sec. 7.5.3 > > > > > > > > The XPath expression is conceptually evaluated in the following > > > > context, in addition to the definition in Section 6.4.1 > > > > : > > > > > > > > o The context node is the node in the accessible tree for which the > > > > "must" statement is defined. > > > > > > > > > > > > The problem for input/output is that these nodes are not encoded > > > > in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines the > > > > XPath context for input and output, so 7.5.3 is incorrect. > > > > > > > > 7.5.3 should say the context node for input/output is the node representing > > > > the RPC operation. This would be the same for NETCONF encoding of action. > > > > The RESTCONF encoding for RPC and action is completely different > > > > but the definition in 7.5.3 is actually correct for RESTCONF. > > > > > > This should not depend on any encoding, an XPath expression is evaluated > > > on a conceptual data tree, and this tree is defined for operations, too. > > > > > > > > > > > > The and nodes do not appear at all > > > in the instance document for NETCONF so this bullet in 7.5.3 is wrong > > > for those nodes. > > > > > > For , the child of is already specified > > > as the child of docroot. > > > > OK, so this is about "must" statements specified directly under input/output and notification statements, right? I had the same comment previously: > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html > > > > My understanding is that in the former case the context node is the root of the input/output data tree, and in the latter case it is the node with the same name as the notification. > > > > I agree it should be better explained. > > > > > > > > If you already brought up this issue, then why is the text still incorrect? > > The subsequent discussion convinced me that it can be easily fixed, > and then I lost it from the radar, unfortunately. I lost track of this issue as well :( Anyway, I think my original proposed fix to this issue should work: OLD: o The context node is the node in the accessible tree for which the "must" statement is defined. NEW: o If the "must" statement is a substatement of a "notification" statement, the context node is the node representing the notification in the accessible tree. o If the "must" statement is a substatement of a "input" statement, the context node is the node representing the operation in the accessible tree. o If the "must" statement is a substatement of a "output" statement, the context node is the node representing the operation in the accessible tree. o Otherwise, the context node is the node in the accessible tree for which the "must" statement is defined. Note that the original email thread quickly started to discuss the accessible tree, but the proposed text above does not change the accessible tree. /martin From nobody Thu Jun 16 07:08:14 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAE712D5CC for ; Thu, 16 Jun 2016 07:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 e45cLV19iZNt for ; Thu, 16 Jun 2016 07:08:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAC712B036 for ; Thu, 16 Jun 2016 07:08:08 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:86c:194f:53da:e4f7] (unknown [IPv6:2001:718:1a02:1:86c:194f:53da:e4f7]) by mail.nic.cz (Postfix) with ESMTPSA id 9028060810; Thu, 16 Jun 2016 16:08:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466086086; bh=uhsC5OHg2dPwo6K0CF4B3D39Hi8FBGZ7z1nsNfk6zt0=; h=From:Date:To; b=gRQ8FdIouaw92Y0muNT0KtQve8Wze50hPk6D36FIMXy/htbjqRbLhG/0VZ2virRr5 7iBby8UcxPWpC87LqTOpqMSdzMW5vzrA701PbmyuWd0jWX9rpVYWAAPSsmx3JcXgZv mBV+qX4Eroq6q/cxEDAD00TBMbodYvSAOwIGH4R4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <20160616.155848.1395296716645649051.mbj@tail-f.com> Date: Thu, 16 Jun 2016 16:08:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F8E5C74-D9C4-48C2-89FF-5964E8277ACB@nic.cz> References: <996ADF73-45D2-4A62-9983-014DA731702C@nic.cz> <20160616.155848.1395296716645649051.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 14:08:12 -0000 > On 16 Jun 2016, at 15:58, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 16 Jun 2016, at 15:12, Andy Bierman wrote: >>>=20 >>>=20 >>>=20 >>> On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka = wrote: >>>=20 >>>> On 13 Jun 2016, at 16:39, Andy Bierman wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka = wrote: >>>> Andy Bierman writes: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I am trying to implement YANG 1.1 must-stmt extensions. >>>>> They appear to be under-specified. >>>>>=20 >>>>> In sec. 7.5.3 >>>>>=20 >>>>> The XPath expression is conceptually evaluated in the following >>>>> context, in addition to the definition in Section 6.4.1 >>>>> = : >>>>>=20 >>>>> o The context node is the node in the accessible tree for which = the >>>>> "must" statement is defined. >>>>>=20 >>>>>=20 >>>>> The problem for input/output is that these nodes are not encoded >>>>> in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly = defines the >>>>> XPath context for input and output, so 7.5.3 is incorrect. >>>>>=20 >>>>> 7.5.3 should say the context node for input/output is the node = representing >>>>> the RPC operation. This would be the same for NETCONF encoding of = action. >>>>> The RESTCONF encoding for RPC and action is completely different >>>>> but the definition in 7.5.3 is actually correct for RESTCONF. >>>>=20 >>>> This should not depend on any encoding, an XPath expression is = evaluated >>>> on a conceptual data tree, and this tree is defined for operations, = too. >>>>=20 >>>>=20 >>>>=20 >>>> The and nodes do not appear at all >>>> in the instance document for NETCONF so this bullet in 7.5.3 is = wrong >>>> for those nodes. >>>>=20 >>>> For , the child of is already = specified >>>> as the child of docroot. >>>=20 >>> OK, so this is about "must" statements specified directly under = input/output and notification statements, right? I had the same comment = previously: >>>=20 >>> https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html >>>=20 >>> My understanding is that in the former case the context node is the = root of the input/output data tree, and in the latter case it is the = node with the same name as the notification. >>>=20 >>> I agree it should be better explained. >>>=20 >>>=20 >>>=20 >>> If you already brought up this issue, then why is the text still = incorrect? >>=20 >> The subsequent discussion convinced me that it can be easily fixed, >> and then I lost it from the radar, unfortunately. >=20 > I lost track of this issue as well :( >=20 > Anyway, I think my original proposed fix to this issue should work: >=20 > OLD: >=20 > o The context node is the node in the accessible tree for which the > "must" statement is defined. >=20 > NEW: >=20 > o If the "must" statement is a substatement of a "notification" > statement, the context node is the node representing the > notification in the accessible tree. >=20 > o If the "must" statement is a substatement of a "input" > statement, the context node is the node representing the > operation in the accessible tree. >=20 > o If the "must" statement is a substatement of a "output" > statement, the context node is the node representing the > operation in the accessible tree. What is "the node representing the operation in the accessible tree"? I = think it should rather be "the root node of the operation request/reply = instance". Unlike notifications, operations request/reply isn't wrapped = in an element with the operation's name. Lada >=20 > o Otherwise, the context node is the node in the accessible tree > for which the "must" statement is defined. >=20 >=20 > Note that the original email thread quickly started to discuss the > accessible tree, but the proposed text above does not change the > accessible tree. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 16 07:41:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DC212D643 for ; Thu, 16 Jun 2016 07:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LZz9iwPyrgA for ; Thu, 16 Jun 2016 07:41:01 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 009EA12D621 for ; Thu, 16 Jun 2016 07:41:00 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id u64so76034905vkf.3 for ; Thu, 16 Jun 2016 07:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=S7Dg8LFN4TK6dE5Rg0l3jj13jh+1kXc/Xlfmn0+7MqA=; b=d2Cg9u4X1/22CeSFxsvAM+sioqeA79/rFUlkInWXTM6/dyRG+gbAVTYPlgZN7GW/DM RpXNndsTSubFcuBkZv8/zuLyZmpqu1biEyY6J+TYWx0SAJspyOb6qUsIRve8WGGxptob I5d7eGlVh1LXCSZhR29eRT3wJ0G1IcsOiLbKeHHED1ozZGrb9oDs66L8ngZlME3gK6ew p17Dzvnk9JjTU+RrGVTu0cIgTYb7qv77mSQ8IL8A4sP7eKtQHYreGtbTswpecWNkt7sM orSQZKgktgdHPOXFj2jDpfB9Zn1iXDzEdCqC6LhekZSPJXN/QiLp/NUgfrbW9yehtKYX Y5HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=S7Dg8LFN4TK6dE5Rg0l3jj13jh+1kXc/Xlfmn0+7MqA=; b=VffctOtRnmGZzQjFhOw3wtbuf15V5HF/kRtbjvo/GKNy0zs/fNZ87Uh2rxJgUQSQzV MffAMjEt+H6OqswSbe3431aIA+IXhbiktuoOqayFt18gvvtffxINTg+hB8CsjfEgQBUR IDfcYQJFPjzyUoED4uWbuCzpgxS2bXFOy/G/A9VqrqljSzDIkvROqMG7TcSCBOCe4Qu2 YM6TNO/K6tgPhyeZYQ01RazyQ1BmEH0L4IaQdJyGiyh0Pi0EIoySrrIlxgPTjjGZd9F4 4Ks+lE3LHlsOAW41Lal4IqRJWKCteDEJ4o9+FDK7cRgaWE7LEMaO9yZfjPXfhDnEKV+a iyCA== X-Gm-Message-State: ALyK8tJWpHRXi8IdIjqe51x0+SEFj41Yki29iMFr4e+3BdIQt8qSp7o1YI8IfTvJnpJ/VRCsTZD7UBnNWeUI6Q== MIME-Version: 1.0 X-Received: by 10.31.94.201 with SMTP id s192mr2183846vkb.89.1466088059965; Thu, 16 Jun 2016 07:40:59 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Thu, 16 Jun 2016 07:40:59 -0700 (PDT) In-Reply-To: <8F8E5C74-D9C4-48C2-89FF-5964E8277ACB@nic.cz> References: <996ADF73-45D2-4A62-9983-014DA731702C@nic.cz> <20160616.155848.1395296716645649051.mbj@tail-f.com> <8F8E5C74-D9C4-48C2-89FF-5964E8277ACB@nic.cz> Date: Thu, 16 Jun 2016 07:40:59 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114e513c063ca00535663a91 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 14:41:03 -0000 --001a114e513c063ca00535663a91 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 16, 2016 at 7:08 AM, Ladislav Lhotka wrote: > > > On 16 Jun 2016, at 15:58, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 16 Jun 2016, at 15:12, Andy Bierman wrote: > >>> > >>> > >>> > >>> On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka > wrote: > >>> > >>>> On 13 Jun 2016, at 16:39, Andy Bierman wrote: > >>>> > >>>> > >>>> > >>>> On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka > wrote: > >>>> Andy Bierman writes: > >>>> > >>>>> Hi, > >>>>> > >>>>> I am trying to implement YANG 1.1 must-stmt extensions. > >>>>> They appear to be under-specified. > >>>>> > >>>>> In sec. 7.5.3 > >>>>> > >>>>> The XPath expression is conceptually evaluated in the following > >>>>> context, in addition to the definition in Section 6.4.1 > >>>>> < > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-13#section-6.4.1 > >: > >>>>> > >>>>> o The context node is the node in the accessible tree for which > the > >>>>> "must" statement is defined. > >>>>> > >>>>> > >>>>> The problem for input/output is that these nodes are not encoded > >>>>> in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines > the > >>>>> XPath context for input and output, so 7.5.3 is incorrect. > >>>>> > >>>>> 7.5.3 should say the context node for input/output is the node > representing > >>>>> the RPC operation. This would be the same for NETCONF encoding of > action. > >>>>> The RESTCONF encoding for RPC and action is completely different > >>>>> but the definition in 7.5.3 is actually correct for RESTCONF. > >>>> > >>>> This should not depend on any encoding, an XPath expression is > evaluated > >>>> on a conceptual data tree, and this tree is defined for operations, > too. > >>>> > >>>> > >>>> > >>>> The and nodes do not appear at all > >>>> in the instance document for NETCONF so this bullet in 7.5.3 is wrong > >>>> for those nodes. > >>>> > >>>> For , the child of is already specified > >>>> as the child of docroot. > >>> > >>> OK, so this is about "must" statements specified directly under > input/output and notification statements, right? I had the same comment > previously: > >>> > >>> https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html > >>> > >>> My understanding is that in the former case the context node is the > root of the input/output data tree, and in the latter case it is the node > with the same name as the notification. > >>> > >>> I agree it should be better explained. > >>> > >>> > >>> > >>> If you already brought up this issue, then why is the text still > incorrect? > >> > >> The subsequent discussion convinced me that it can be easily fixed, > >> and then I lost it from the radar, unfortunately. > > > > I lost track of this issue as well :( > > > > Anyway, I think my original proposed fix to this issue should work: > > > > OLD: > > > > o The context node is the node in the accessible tree for which the > > "must" statement is defined. > > > > NEW: > > > > o If the "must" statement is a substatement of a "notification" > > statement, the context node is the node representing the > > notification in the accessible tree. > notification foo { must "leaf-a > 4"; leaf leaf-a { type int32; } } 5 The text might confuse people into thinking is the context instead of . The XPath section says the accessible tree root has as a child node, but it is not obvious. > > > o If the "must" statement is a substatement of a "input" > > statement, the context node is the node representing the > > operation in the accessible tree. > > > > o If the "must" statement is a substatement of a "output" > > statement, the context node is the node representing the > > operation in the accessible tree. > > What is "the node representing the operation in the accessible tree"? I > think it should rather be "the root node of the operation request/reply > instance". Unlike notifications, operations request/reply isn't wrapped in > an element with the operation's name. > It is different for NETCONF and RESTCONF How about "representing the root of the operation input in the accessible tree" > Lada > Andy > > > > > o Otherwise, the context node is the node in the accessible tree > > for which the "must" statement is defined. > > > > > > Note that the original email thread quickly started to discuss the > > accessible tree, but the proposed text above does not change the > > accessible tree. > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a114e513c063ca00535663a91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 16, 2016 at 7:08 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 16 Jun 2016, at 15:58, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>>
>>> On 16 Jun 2016, at 15:12, Andy Bierman <andy@yumaworks.com> wrote:
>>>
>>>
>>>
>>> On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>>
>>>> On 13 Jun 2016, at 16:39, Andy Bierman <andy@yumaworks.com> wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>>> Andy Bierman <and= y@yumaworks.com> writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am trying to implement YANG 1.1 must-stmt extensions= .
>>>>> They appear to be under-specified.
>>>>>
>>>>> In sec. 7.5.3
>>>>>
>>>>>=C2=A0 =C2=A0The XPath expression is conceptually evalu= ated in the following
>>>>>=C2=A0 =C2=A0context, in addition to the definition in = Section 6.4.1
>>>>> <ht= tps://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-13#section-6.4.1= >:
>>>>>
>>>>>=C2=A0 =C2=A0o=C2=A0 The context node is the node in th= e accessible tree for which the
>>>>>=C2=A0 =C2=A0 =C2=A0 "must" statement is defi= ned.
>>>>>
>>>>>
>>>>> The problem for input/output is that these nodes are n= ot encoded
>>>>> in any NETCONF RPC or action invocation. Sec. 6.4.1 cl= early defines the
>>>>> XPath context for input and output, so 7.5.3 is incorr= ect.
>>>>>
>>>>> 7.5.3 should say the context node for input/output is = the node representing
>>>>> the RPC operation. This would be the same for NETCONF = encoding of action.
>>>>> The RESTCONF encoding for RPC and action is completely= different
>>>>> but the definition in 7.5.3 is actually correct for RE= STCONF.
>>>>
>>>> This should not depend on any encoding, an XPath expressio= n is evaluated
>>>> on a conceptual data tree, and this tree is defined for op= erations, too.
>>>>
>>>>
>>>>
>>>> The <input> and <output> nodes do not appear a= t all
>>>> in the instance document for NETCONF so this bullet in 7.5= .3 is wrong
>>>> for those nodes.
>>>>
>>>> For <notiofication>, the child of <notification&g= t; is already specified
>>>> as the child of docroot.
>>>
>>> OK, so this is about "must" statements specified dir= ectly under input/output and notification statements, right? I had the same= comment previously:
>>>
>>> https://www.ietf.org/= mail-archive/web/netmod/current/msg14469.html
>>>
>>> My understanding is that in the former case the context node i= s the root of the input/output data tree, and in the latter case it is the = node with the same name as the notification.
>>>
>>> I agree it should be better explained.
>>>
>>>
>>>
>>> If you already brought up this issue, then why is the text sti= ll incorrect?
>>
>> The subsequent discussion convinced me that it can be easily fixed= ,
>> and then I lost it from the radar, unfortunately.
>
> I lost track of this issue as well :(
>
> Anyway, I think my original proposed fix to this issue should work: >
> OLD:
>
>=C2=A0 =C2=A0o=C2=A0 The context node is the node in the accessible tre= e for which the
>=C2=A0 =C2=A0 =C2=A0 "must" statement is defined.
>
> NEW:
>
>=C2=A0 =C2=A0o=C2=A0 If the "must" statement is a substatemen= t of a "notification"
>=C2=A0 =C2=A0 =C2=A0 statement, the context node is the node representi= ng the
>=C2=A0 =C2=A0 =C2=A0 notification in the accessible tree.


notification foo {
=C2=A0 = =C2=A0must "leaf-a > 4";
=C2=A0 =C2=A0leaf leaf-a { = type int32; }
}

<notification>
=C2=A0 =C2=A0<foo>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<le= af-a>5</leaf-a>
=C2=A0 =C2=A0</foo>
<= /notification>

The text might confuse people in= to thinking <notification> is the context instead of <foo>.
The XPath section says the accessible tree root has <foo> as a= child node, but it is
not obvious.


=
>
>=C2=A0 =C2=A0o=C2=A0 If the "must" statement is a substatemen= t of a "input"
>=C2=A0 =C2=A0 =C2=A0 statement, the context node is the node representi= ng the
>=C2=A0 =C2=A0 =C2=A0 operation in the accessible tree.
>
>=C2=A0 =C2=A0o=C2=A0 If the "must" statement is a substatemen= t of a "output"
>=C2=A0 =C2=A0 =C2=A0 statement, the context node is the node representi= ng the
>=C2=A0 =C2=A0 =C2=A0 operation in the accessible tree.

What is "the node representing the operation in the accessible tree&qu= ot;? I think it should rather be "the root node of the operation reque= st/reply instance". Unlike notifications, operations request/reply isn= 't wrapped in an element with the operation's name.


It is different for NETCONF and RESTCON= F

How about "representing the root of the ope= ration input in the accessible tree"



Lada

Andy
=C2=A0

>
>=C2=A0 =C2=A0o=C2=A0 Otherwise, the context node is the node in the acc= essible tree
>=C2=A0 =C2=A0 =C2=A0 for which the "must" statement is define= d.
>
>
> Note that the original email thread quickly started to discuss the
> accessible tree, but the proposed text above does not change the
> accessible tree.
>
>
> /martin

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





--001a114e513c063ca00535663a91-- From nobody Thu Jun 16 08:49:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B9A12D88A for ; Thu, 16 Jun 2016 08:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 wEG-1xlvhm22 for ; Thu, 16 Jun 2016 08:49:54 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207: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 9870512D83E for ; Thu, 16 Jun 2016 08:49:54 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with SMTP id DZR8bhvnI8JCNDZYHbS6AA; Thu, 16 Jun 2016 15:49:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466092193; bh=ohgG/n6G/sv9ooOiiia03Alf6aazgWd/BJUzai27emo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=tPWR2ibUw8fS8pajEEWeu9uCB5dJO2ACRD8AWe/CDxEyHqLB2+dbcjQHrq0PH9ekl clDwpMgCrbeygrd0rZygdfl7jxHEkWyvClu74sfXyI28KzvTzwDF+XWJa+Ivs/iF8d E/lQwk9WTcPXlCFaHSwLk2l2YemXDiDq/ixfqvAKrue75tWXXLWsdBrQkXJM8kn82N Z24z1Lh/vq29Ph13P05TC4yIKJoTNm2hcSjr+YsNR/BX4pn9suGTcg5fJzxW6MPT2R b9ESkyk9sdKwqfR2yssn99PYPHMVRnzR+kUTwvJ7q1yPp8+/q5PS2rDRDRZXsnkww4 8vo29vNYuD3Uw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id 7Tps1t00Y1nMCLR01Tpt9s; Thu, 16 Jun 2016 15:49:53 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5GFnqhH015780; Thu, 16 Jun 2016 11:49:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5GFnpYH015777; Thu, 16 Jun 2016 11:49:51 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Balazs Lengyel In-Reply-To: <95c39a63-b9ec-e006-87f6-70443c4c726b@ericsson.com> (balazs.lengyel@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 16 Jun 2016 11:49:51 -0400 Message-ID: <87r3bxrv4w.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org, balazs.kovacs@ericsson.com Subject: Re: [netmod] Must on actions without input or output parameters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 15:49:55 -0000 Balazs Lengyel writes: > We only want to allow starting myThing (calling the start action) if > it is enabled. > However we > - can not put a must under action according to the RFC/draft > - while the RFC would allow us to put an empty input under action with > only the must statement in it, pyang complains about the absence of > data definition nodes. Reading the specification of the must statement (section 7.5.3), the concept that must declares a *constraint*, which is evaluated at commit time as specified in section 8. Reading 8.1, I see that it describes which constraints are applied at what times. No only are they used to validate the datastore at commit time, they also are used to validate the inputs and outputs of actions, etc. The scope of the XPath expression in such a must is the input data tree of the action, not the datastore. So there is no way to specify in Yang a constraint on the datastore that must be satisfied for an action to be valid. In regard to "input", it isn't said plainly in section 7.14, but the ABNF makes clear that it must contain at least one data-def-stmt. But if the action has no inputs, the input statement can be omitted. Dale From nobody Thu Jun 16 09:31:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F00812D8F7 for ; Thu, 16 Jun 2016 09:31:42 -0700 (PDT) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWJvWFWST_li for ; Thu, 16 Jun 2016 09:31:40 -0700 (PDT) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285D412D9AA for ; Thu, 16 Jun 2016 09:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uEgAbyeMAbiyRz9YS7QrHSHs2P1yGwqSPPoMRG0jdS8=; b=sesA//kzomUFf75dR+jVHCdCjP S0QI+bKK/uUFrJaAuQeGHTSL2IDTo8x+s65DReWjyynVo/nrSVGaDsr8UW7hhKmEGSgEE5JcTF6RB gaq1TeUCbH9QpH25Qo+QbwsiKhKaVqiuTfrVLdbpNeSBmrZZbBKwDWQHMx88ArTvab0YcSv35Cq7V GpG9qvcHSqAL/9fR3yc1gJob2lHpzplmXjKoBQFqZ4cXDDHGofYA1ru8FzGSgOOS30c2oyQjLoczs TIXDTGVW0qZ6EPJKQTsUmSARfpqOTIWGuMA4od0qchtyZMzi0FN0OGjkL2dqIvaaoct4UOzJgCk23 PPMKhEGw==; Received: from hansfords.plus.com ([84.92.116.209]:38415 helo=Vanguard) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bDaCa-00377W-7z; Thu, 16 Jun 2016 17:31:32 +0100 From: "Jonathan Hansford" To: "'Martin Bjorklund'" , References: <996ADF73-45D2-4A62-9983-014DA731702C@nic.cz> <20160616.155848.1395296716645649051.mbj@tail-f.com> In-Reply-To: <20160616.155848.1395296716645649051.mbj@tail-f.com> Date: Thu, 16 Jun 2016 17:31:34 +0100 Message-ID: <01e601d1c7ec$8c712690$a55373b0$@hansfords.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQNCD7266uGdmf384YNHI+733v67fQJDvJtBAomCaisB4dIOg5zWQHRw Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 16:31:42 -0000 s/a "input"/an "input" s/a "output"/an "output" > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin > Bjorklund > Sent: 16 June 2016 14:59 > To: lhotka@nic.cz > Cc: netmod@ietf.org > Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, > notification > > Ladislav Lhotka wrote: > > > > > On 16 Jun 2016, at 15:12, Andy Bierman wrote: > > > > > > > > > > > > On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka wrote: > > > > > > > On 13 Jun 2016, at 16:39, Andy Bierman > wrote: > > > > > > > > > > > > > > > > On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka > wrote: > > > > Andy Bierman writes: > > > > > > > > > Hi, > > > > > > > > > > I am trying to implement YANG 1.1 must-stmt extensions. > > > > > They appear to be under-specified. > > > > > > > > > > In sec. 7.5.3 > > > > > > > > > > The XPath expression is conceptually evaluated in the following > > > > > context, in addition to the definition in Section 6.4.1 > > > > > 13#section-6.4.1>: > > > > > > > > > > o The context node is the node in the accessible tree for which the > > > > > "must" statement is defined. > > > > > > > > > > > > > > > The problem for input/output is that these nodes are not encoded > > > > > in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly > > > > > defines the XPath context for input and output, so 7.5.3 is incorrect. > > > > > > > > > > 7.5.3 should say the context node for input/output is the node > > > > > representing the RPC operation. This would be the same for > NETCONF encoding of action. > > > > > The RESTCONF encoding for RPC and action is completely different > > > > > but the definition in 7.5.3 is actually correct for RESTCONF. > > > > > > > > This should not depend on any encoding, an XPath expression is > > > > evaluated on a conceptual data tree, and this tree is defined for > operations, too. > > > > > > > > > > > > > > > > The and nodes do not appear at all in the > > > > instance document for NETCONF so this bullet in 7.5.3 is wrong for > > > > those nodes. > > > > > > > > For , the child of is already > > > > specified as the child of docroot. > > > > > > OK, so this is about "must" statements specified directly under > input/output and notification statements, right? I had the same comment > previously: > > > > > > https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html > > > > > > My understanding is that in the former case the context node is the root > of the input/output data tree, and in the latter case it is the node with the > same name as the notification. > > > > > > I agree it should be better explained. > > > > > > > > > > > > If you already brought up this issue, then why is the text still incorrect? > > > > The subsequent discussion convinced me that it can be easily fixed, > > and then I lost it from the radar, unfortunately. > > I lost track of this issue as well :( > > Anyway, I think my original proposed fix to this issue should work: > > OLD: > > o The context node is the node in the accessible tree for which the > "must" statement is defined. > > NEW: > > o If the "must" statement is a substatement of a "notification" > statement, the context node is the node representing the > notification in the accessible tree. > > o If the "must" statement is a substatement of a "input" > statement, the context node is the node representing the > operation in the accessible tree. > > o If the "must" statement is a substatement of a "output" > statement, the context node is the node representing the > operation in the accessible tree. > > o Otherwise, the context node is the node in the accessible tree > for which the "must" statement is defined. > > > Note that the original email thread quickly started to discuss the accessible > tree, but the proposed text above does not change the accessible tree. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jun 16 11:52:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7012DACD for ; Thu, 16 Jun 2016 11:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 Gv1uUmbbHXLt for ; Thu, 16 Jun 2016 11:52:03 -0700 (PDT) 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 396EE12D862 for ; Thu, 16 Jun 2016 11:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5796; q=dns/txt; s=iport; t=1466103123; x=1467312723; h=from:to:subject:date:message-id:mime-version; bh=z9obXmUWokCrcMCydV8/oouYO1eE6kKQ0KUfHXUn2RA=; b=HDmnD3/s8IClfN0s+e1jcnuM3p+JlnOAwvIZUD+8O/57ODbaQ49refb7 bkAI5u5QnhSK3LCX6h7/nOo+JcTU3OS7l4qYSxM9Sko6TmmldX3GmjKlU H4xvYmA7v+AHWBO0GLZD5v5XAlxmIHxfC7IrT2TBEoNsKrUGn654jAyQB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAgCV9GJX/5FdJa1egnBOVn0GtVSCc?= =?us-ascii?q?oIPgXoXAQyHITgUAQEBAQEBAWUcC4RSLV4BLVMmAQQPDAGIJw6gGqA8AQEBAQE?= =?us-ascii?q?FAQEBAQEBASCGJ45oBZhxAYYEiB2PKY90AR42g3BuAQWIfwF+AQEB?= X-IronPort-AV: E=Sophos;i="5.26,481,1459814400"; d="scan'208,217";a="285025544" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2016 18:52:02 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5GIq2uo011534 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Jun 2016 18:52:02 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 16 Jun 2016 14:52:01 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1104.009; Thu, 16 Jun 2016 14:52:01 -0400 From: "Eric Voit (evoit)" To: "netmod@ietf.org" Thread-Topic: Event & YANG Datastore Subscription drafts in NETCONF Thread-Index: AdHH/+5kNB0V17wgQZ+sU/eh69LfpQ== Date: Thu, 16 Jun 2016 18:52:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.50] Content-Type: multipart/alternative; boundary="_000_a05cc20aa426479e809c6dffd1722653XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] Event & YANG Datastore Subscription drafts in NETCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 18:52:05 -0000 --_000_a05cc20aa426479e809c6dffd1722653XCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updates to the Subscription drafts discussed in NETMOD during IETF 95 have = been posted to the NETCONF WG. The goal of these drafts is to provide gene= ralized subscription and push specifications for YANG Datastores and Event = Streams. A summarized context on how the drafts interrelate is here. The drafts of interest include: Subscriptions for Event Notifications (RFC5277bis) draft-gonzalez-netconf-5277bis NETCONF Transport for Event Notifications draft-gonzalez-netconf-event-notifications RESTCONF & HTTP Transport for Event Notifications draft-voit-netconf-restconf-notif YANG Datastore Push (to be posted very shortly) draft-ietf-netconf-yang-push Thanks, Eric --_000_a05cc20aa426479e809c6dffd1722653XCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Updates to the Subscription drafts discussed in NETM= OD during IETF 95 have been posted to the NETCONF WG.  The goal of the= se drafts is to provide generalized subscription and push specifications fo= r YANG Datastores and Event Streams.   A summarized context on how the drafts interrelate is here.   

 

The drafts of interest include:

 

Subscriptions for Event Notifications  (RFC5= 277bis)

draft-gonzalez-netconf-5277bis

 

NETCONF Transport for Event Notifications

draft-gonzalez-netconf-event-notifi= cations 

 

RESTCONF & HTTP Transport for Event Notificat= ions

draft-voit-netconf-restconf-notif

 

YANG Datastore Push (to be posted very shortly)

draft-ietf-netconf-yang-push

 

Thanks,

Eric

 

--_000_a05cc20aa426479e809c6dffd1722653XCHRTP013ciscocom_-- From nobody Thu Jun 16 14:46:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9B12DC9F for ; Thu, 16 Jun 2016 14:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 H8yKy4bd33hV for ; Thu, 16 Jun 2016 14:46:02 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 B343E12DC9C for ; Thu, 16 Jun 2016 14:46:02 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 43132DC536EC8; Thu, 16 Jun 2016 21:45:59 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u5GLk0CW031341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Jun 2016 21:46:01 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u5GLjwLO019911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Jun 2016 21:46:00 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 16 Jun 2016 17:45:07 -0400 From: "Sterne, Jason (Nokia - CA)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt Thread-Index: AQHRxxrDqcSbCbxdqk+sJ01FZToTSJ/soRcA Date: Thu, 16 Jun 2016 21:45:06 +0000 Message-ID: References: <20160615152932.GA31216@elstar.local> In-Reply-To: <20160615152932.GA31216@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 21:46:05 -0000 Hi Juergen, About the identities vs enum for 'facilities' -> I'm pretty sure it was dis= cussed on the list previously but I think the applicability of the model is= going to be much better if we allow extensible facilities. Several imple= mentations use proprietary facility names along with RFC5424 facility names= in a unified way to configure logging. IMO this YANG model isn't exactly trying to match & reproduce RFC5424. RFC= 5424 is more about the format of syslog messages on a wire. But this syslo= g YANG model is more about how devices configure logging. So I'm strongly in favor of seeing the facilities stay as an identity. Regards, Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwa= elder Sent: Wednesday, June 15, 2016 11:30 To: netmod@ietf.org Subject: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt Hi, Dan Romascanu encouraged me to look at this I-D as part of his efforts to o= rganize YANG document reviews. Since the YANG definitions are not consisten= t with the tree diagram, I have not really looked at the YANG definitions y= et. So the comments below are essentially about the surrounding document st= ructure, terminology, etc. - Abstract: The 'which is used to convey event notification messages' may relate to 'the Syslog protocol' or 'a data model' and hence the sentence is I think potentially confusing. Perhaps simply remove the phrase altogether? Readers who do not know what SYSLOG is should stop reading here anyway. Or break the sentence into two to make the structure clearer. Perhaps add one more sentence describing what the scope of the data model is. - The text uses Syslog, syslog, and SYSLOG. It is not clear what the difference is (if any). If there is no semantic difference, I suggest to pick one writing style (and 5424 seems to prefer all lowercase except in cases where a sentence starts etc). - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 to 'The ietf-syslog Module' or something similar and consider changing the title of section 4 to "Syslog YANG Modules" since it contains the definitions of the modules themselves. - In section 2, should 'monitor and control' be 'configure and monitor' in section 2? Are there actually definitions that support monitoring? Perhaps the scope is just configuration? Otherwise, I would have expected to see a bunch of basic counters (messages received, forwarded, dropped, the usual monitoring stuff). - In section 2, s/network management agents such as NETCONF/network management protocols such as NETCONF/ - In section 2, the phrase 'This module' is a hanging reference. There is no prior text talking about a module. Perhaps replace with 'The data model' - I did not find the term 'message distributor' in RFC 5424. The figure first made me assume that only a console, log buffers, or log files are message distributors but later it was stated that relays and collectors (RFC 5424 defined terms) are also 'message distributors'. Perhaps it helps to clearly spell out terms imported from RFC 5424 and to clearly define any additional terms that go beyond what is defined in RFC 5424. - Is it possible to shorten 'log-input-transports' to simply 'log-inputs' (en par with log-actions)? And since both containers are under syslog, perhaps even the 'log-' prefix is not needed and all we have are /syslog/inputs and /syslog/actions? (I generally find it useful to look at the resulting paths and whether they are 'engineer friendly'. - I guess I have to define multiple /syslog/input/receiver in order to listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and [::]:514? This may be just find - just checking that this is the idea. - I actually do not find the definition of log-input-transports in the YANG model. It seems the tree diagram is not consistent with the YANG model. So I can't judge what the structured-data boolean flag is doing or what the syslog-sign presence container would do for inputs. - The security considerations are quite generic; I think the template asks for a more specific discussion. - I am not sure why RFC 6020 is an informative reference and why all the normative references are actually normative. It might be useful to go over the list to make sure we get the normative / informative distinction right. - My understanding is that RFC 5424 numbers facilities and there is a hard limit on the number of facilities that the protocol can distinguish. RFC 5424 says: Facility values MUST be in the range of 0 to 23 inclusive. Given this, the 'extending facilities' appendix does not make much sense to me. And given the fact that the number of facilities is fixed (which is due to the way things are encoded in RFC 5424), I am not even sure that using an identity instead of an enumeration is useful (except if we expect a future version of SYSLOG to use a very different encoding of facilities). I mean, to stay within the bounds of RFC 5424, all one can do is to add an identity that maps to an already allocated code point. - Do not use 1.1.1.1 as an example IP address, consider using an IPv6 address from the IPv6 example address space. - Section 4.3 should not be in Section 4 and the title 'A Syslog Example' is kind of misleading since the text shows NETCONF messages operating on the SYSLOG YANG data model. I suggest to move 4.3 to a new top-level section 5 "Usage Examples". Does it make sense to show some complete example configs for typical use cases? - Before the YANG model definitions, it is a common idea to describe what is imported from which RFCs. For example, one of the YANG modules imports ietf-interfaces but there is no (normative) reference to the relevant RFC. See the first sentence in section 4 of RFC 7277 for an example how to do this. - I suggest to remove the subsection title 3.1. or to change the title to "SYSLOG Data Model" and lifting it up to the top-level so that it becomes section 4. As said above, I have not reviewed the YANG definitions yet since apparentl= y it is not in sync with the rest of the document. But I thought I send the= se comments now anyway so that they can already be taken into account. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jun 16 23:38:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673BB12D0F0 for ; Thu, 16 Jun 2016 23:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 93IVsZQTUel4 for ; Thu, 16 Jun 2016 23:38:31 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE1612B024 for ; Thu, 16 Jun 2016 23:38:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0F15FE68; Fri, 17 Jun 2016 08:38:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id q4Mgu_mMBiYu; Fri, 17 Jun 2016 08:38:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Jun 2016 08:38:28 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C52820054; Fri, 17 Jun 2016 08:38:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BuSxMtRPxLWm; Fri, 17 Jun 2016 08:38:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 586B520031; Fri, 17 Jun 2016 08:38:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4D4DB3B27D06; Fri, 17 Jun 2016 08:38:26 +0200 (CEST) Date: Fri, 17 Jun 2016 08:38:26 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA)" Message-ID: <20160617063826.GB34404@elstar.local> Mail-Followup-To: "Sterne, Jason (Nokia - CA)" , "netmod@ietf.org" References: <20160615152932.GA31216@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: "netmod@ietf.org" Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 06:38:33 -0000 In ietf-syslog-types, there is a mapping of facility names to a limited number space on the wire. Unfortunately, this mapping is not available in a machine readable form. But for those names listed in RFC 5424, there is at least a mapping defined in human readable form in the description clauses. The examples given in A.1 are completely silent about which number is used on the wire. I think this is a problem if you consider setups where a relay is expected to filter on facility values. When an originator uses facility 'vendor:foo', what will that facility be from the viewpoint of a relay? /js On Thu, Jun 16, 2016 at 09:45:06PM +0000, Sterne, Jason (Nokia - CA) wrote: > Hi Juergen, > > About the identities vs enum for 'facilities' -> I'm pretty sure it was discussed on the list previously but I think the applicability of the model is going to be much better if we allow extensible facilities. Several implementations use proprietary facility names along with RFC5424 facility names in a unified way to configure logging. > > IMO this YANG model isn't exactly trying to match & reproduce RFC5424. RFC5424 is more about the format of syslog messages on a wire. But this syslog YANG model is more about how devices configure logging. > > So I'm strongly in favor of seeing the facilities stay as an identity. > > Regards, > Jason > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, June 15, 2016 11:30 > To: netmod@ietf.org > Subject: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt > > Hi, > > Dan Romascanu encouraged me to look at this I-D as part of his efforts to organize YANG document reviews. Since the YANG definitions are not consistent with the tree diagram, I have not really looked at the YANG definitions yet. So the comments below are essentially about the surrounding document structure, terminology, etc. > > - Abstract: The 'which is used to convey event notification messages' > may relate to 'the Syslog protocol' or 'a data model' and hence the > sentence is I think potentially confusing. Perhaps simply remove the > phrase altogether? Readers who do not know what SYSLOG is should > stop reading here anyway. Or break the sentence into two to make the > structure clearer. Perhaps add one more sentence describing what the > scope of the data model is. > > - The text uses Syslog, syslog, and SYSLOG. It is not clear what the > difference is (if any). If there is no semantic difference, I > suggest to pick one writing style (and 5424 seems to prefer all > lowercase except in cases where a sentence starts etc). > > - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 > to 'The ietf-syslog Module' or something similar and consider > changing the title of section 4 to "Syslog YANG Modules" since > it contains the definitions of the modules themselves. > > - In section 2, should 'monitor and control' be 'configure and > monitor' in section 2? Are there actually definitions that support > monitoring? Perhaps the scope is just configuration? Otherwise, I > would have expected to see a bunch of basic counters (messages > received, forwarded, dropped, the usual monitoring stuff). > > - In section 2, s/network management agents such as NETCONF/network > management protocols such as NETCONF/ > > - In section 2, the phrase 'This module' is a hanging reference. There > is no prior text talking about a module. Perhaps replace with 'The > data model' > > - I did not find the term 'message distributor' in RFC 5424. The > figure first made me assume that only a console, log buffers, or log > files are message distributors but later it was stated that relays > and collectors (RFC 5424 defined terms) are also 'message > distributors'. Perhaps it helps to clearly spell out terms imported > from RFC 5424 and to clearly define any additional terms that go > beyond what is defined in RFC 5424. > > - Is it possible to shorten 'log-input-transports' to simply > 'log-inputs' (en par with log-actions)? And since both containers > are under syslog, perhaps even the 'log-' prefix is not needed and > all we have are /syslog/inputs and /syslog/actions? (I generally > find it useful to look at the resulting paths and whether they are > 'engineer friendly'. > > - I guess I have to define multiple /syslog/input/receiver in order to > listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and > [::]:514? This may be just find - just checking that this is the > idea. > > - I actually do not find the definition of log-input-transports in the > YANG model. It seems the tree diagram is not consistent with the > YANG model. So I can't judge what the structured-data boolean flag > is doing or what the syslog-sign presence container would do for > inputs. > > - The security considerations are quite generic; I think the template > asks for a more specific discussion. > > - I am not sure why RFC 6020 is an informative reference and why all > the normative references are actually normative. It might be useful > to go over the list to make sure we get the normative / informative > distinction right. > > - My understanding is that RFC 5424 numbers facilities and there is a > hard limit on the number of facilities that the protocol can > distinguish. RFC 5424 says: > > Facility values MUST be in the range of 0 to 23 inclusive. > > Given this, the 'extending facilities' appendix does not make much > sense to me. And given the fact that the number of facilities is > fixed (which is due to the way things are encoded in RFC 5424), I am > not even sure that using an identity instead of an enumeration is > useful (except if we expect a future version of SYSLOG to use a very > different encoding of facilities). I mean, to stay within the bounds > of RFC 5424, all one can do is to add an identity that maps to an > already allocated code point. > > - Do not use 1.1.1.1 as an example IP address, consider using an IPv6 > address from the IPv6 example address space. > > - Section 4.3 should not be in Section 4 and the title 'A Syslog > Example' is kind of misleading since the text shows NETCONF messages > operating on the SYSLOG YANG data model. I suggest to move 4.3 to > a new top-level section 5 "Usage Examples". Does it make sense to > show some complete example configs for typical use cases? > > - Before the YANG model definitions, it is a common idea to describe > what is imported from which RFCs. For example, one of the YANG > modules imports ietf-interfaces but there is no (normative) > reference to the relevant RFC. See the first sentence in section 4 > of RFC 7277 for an example how to do this. > > - I suggest to remove the subsection title 3.1. or to change the title > to "SYSLOG Data Model" and lifting it up to the top-level so that it > becomes section 4. > > As said above, I have not reviewed the YANG definitions yet since apparently it is not in sync with the rest of the document. But I thought I send these comments now anyway so that they can already be taken into account. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- 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 Jun 17 00:39:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429B912D17B for ; Fri, 17 Jun 2016 00:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 S_hiLZtoyJUA for ; Fri, 17 Jun 2016 00:39:14 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 696EE12B026 for ; Fri, 17 Jun 2016 00:39:14 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 28DA01AE0387; Fri, 17 Jun 2016 09:39:13 +0200 (CEST) Date: Fri, 17 Jun 2016 09:39:36 +0200 (CEST) Message-Id: <20160617.093936.1934788325323679313.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <8F8E5C74-D9C4-48C2-89FF-5964E8277ACB@nic.cz> References: <996ADF73-45D2-4A62-9983-014DA731702C@nic.cz> <20160616.155848.1395296716645649051.mbj@tail-f.com> <8F8E5C74-D9C4-48C2-89FF-5964E8277ACB@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 07:39:16 -0000 Ladislav Lhotka wrote: > > > On 16 Jun 2016, at 15:58, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 16 Jun 2016, at 15:12, Andy Bierman wrote: > >>> > >>> > >>> > >>> On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka > >>> wrote: > >>> > >>>> On 13 Jun 2016, at 16:39, Andy Bierman wrote: > >>>> > >>>> > >>>> > >>>> On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka > >>>> wrote: > >>>> Andy Bierman writes: > >>>> > >>>>> Hi, > >>>>> > >>>>> I am trying to implement YANG 1.1 must-stmt extensions. > >>>>> They appear to be under-specified. > >>>>> > >>>>> In sec. 7.5.3 > >>>>> > >>>>> The XPath expression is conceptually evaluated in the following > >>>>> context, in addition to the definition in Section 6.4.1 > >>>>> : > >>>>> > >>>>> o The context node is the node in the accessible tree for which the > >>>>> "must" statement is defined. > >>>>> > >>>>> > >>>>> The problem for input/output is that these nodes are not encoded > >>>>> in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines > >>>>> the > >>>>> XPath context for input and output, so 7.5.3 is incorrect. > >>>>> > >>>>> 7.5.3 should say the context node for input/output is the node > >>>>> representing > >>>>> the RPC operation. This would be the same for NETCONF encoding of > >>>>> action. > >>>>> The RESTCONF encoding for RPC and action is completely different > >>>>> but the definition in 7.5.3 is actually correct for RESTCONF. > >>>> > >>>> This should not depend on any encoding, an XPath expression is > >>>> evaluated > >>>> on a conceptual data tree, and this tree is defined for operations, > >>>> too. > >>>> > >>>> > >>>> > >>>> The and nodes do not appear at all > >>>> in the instance document for NETCONF so this bullet in 7.5.3 is wrong > >>>> for those nodes. > >>>> > >>>> For , the child of is already specified > >>>> as the child of docroot. > >>> > >>> OK, so this is about "must" statements specified directly under > >>> input/output and notification statements, right? I had the same > >>> comment previously: > >>> > >>> https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html > >>> > >>> My understanding is that in the former case the context node is the > >>> root of the input/output data tree, and in the latter case it is the > >>> node with the same name as the notification. > >>> > >>> I agree it should be better explained. > >>> > >>> > >>> > >>> If you already brought up this issue, then why is the text still > >>> incorrect? > >> > >> The subsequent discussion convinced me that it can be easily fixed, > >> and then I lost it from the radar, unfortunately. > > > > I lost track of this issue as well :( > > > > Anyway, I think my original proposed fix to this issue should work: > > > > OLD: > > > > o The context node is the node in the accessible tree for which the > > "must" statement is defined. > > > > NEW: > > > > o If the "must" statement is a substatement of a "notification" > > statement, the context node is the node representing the > > notification in the accessible tree. > > > > o If the "must" statement is a substatement of a "input" > > statement, the context node is the node representing the > > operation in the accessible tree. > > > > o If the "must" statement is a substatement of a "output" > > statement, the context node is the node representing the > > operation in the accessible tree. > > What is "the node representing the operation in the accessible tree"? This is already defined in section 6.4.1. Again, note that the text we're currently discussing does not alter the definition of the accessible tree. For more background, see the old email thread to which you provided a pointer. > I think it should rather be "the root node of the operation > request/reply instance". Unlike notifications, operations > request/reply isn't wrapped in an element with the operation's name. Again, see the email thread (this is protocol specific) /martin > > Lada > > > > > o Otherwise, the context node is the node in the accessible tree > > for which the "must" statement is defined. > > > > > > Note that the original email thread quickly started to discuss the > > accessible tree, but the proposed text above does not change the > > accessible tree. > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Jun 17 02:06:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5D412B034 for ; Fri, 17 Jun 2016 02:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 hnZSlKRyh2If for ; Fri, 17 Jun 2016 02:06:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0707112B00E for ; Fri, 17 Jun 2016 02:06:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C5CD5FCE; Fri, 17 Jun 2016 11:06:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id IKCVoCDKST2m; Fri, 17 Jun 2016 11:06:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Jun 2016 11:06:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA01820054; Fri, 17 Jun 2016 11:06:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7-foWpMWilF3; Fri, 17 Jun 2016 11:06:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA1C920047; Fri, 17 Jun 2016 11:06:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F135E3B28515; Fri, 17 Jun 2016 11:06:42 +0200 (CEST) Date: Fri, 17 Jun 2016 11:06:41 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160617090641.GA34896@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <996ADF73-45D2-4A62-9983-014DA731702C@nic.cz> <20160616.155848.1395296716645649051.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160616.155848.1395296716645649051.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 09:06:49 -0000 On Thu, Jun 16, 2016 at 03:58:48PM +0200, Martin Bjorklund wrote: > Anyway, I think my original proposed fix to this issue should work: > > OLD: > > o The context node is the node in the accessible tree for which the > "must" statement is defined. > > NEW: > > o If the "must" statement is a substatement of a "notification" > statement, the context node is the node representing the > notification in the accessible tree. > > o If the "must" statement is a substatement of a "input" > statement, the context node is the node representing the > operation in the accessible tree. > > o If the "must" statement is a substatement of a "output" > statement, the context node is the node representing the > operation in the accessible tree. > > o Otherwise, the context node is the node in the accessible tree > for which the "must" statement is defined. > I think this resolves the issue. /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 Jun 17 03:53:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9F612D0B3 for ; Fri, 17 Jun 2016 03:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIYH110rfOnk for ; Fri, 17 Jun 2016 03:53:54 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D9A0912D110 for ; Fri, 17 Jun 2016 03:53:53 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2787E1CC01BE; Fri, 17 Jun 2016 12:53:57 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20160617.093936.1934788325323679313.mbj@tail-f.com> References: <996ADF73-45D2-4A62-9983-014DA731702C@nic.cz> <20160616.155848.1395296716645649051.mbj@tail-f.com> <8F8E5C74-D9C4-48C2-89FF-5964E8277ACB@nic.cz> <20160617.093936.1934788325323679313.mbj@tail-f.com> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 17 Jun 2016 12:54:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 10:53:56 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> >> > On 16 Jun 2016, at 15:58, Martin Bjorklund wrote: >> > >> > Ladislav Lhotka wrote: >> >> >> >>> On 16 Jun 2016, at 15:12, Andy Bierman wrote: >> >>> >> >>> >> >>> >> >>> On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka >> >>> wrote: >> >>> >> >>>> On 13 Jun 2016, at 16:39, Andy Bierman wrote: >> >>>> >> >>>> >> >>>> >> >>>> On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka >> >>>> wrote: >> >>>> Andy Bierman writes: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> I am trying to implement YANG 1.1 must-stmt extensions. >> >>>>> They appear to be under-specified. >> >>>>> >> >>>>> In sec. 7.5.3 >> >>>>> >> >>>>> The XPath expression is conceptually evaluated in the following >> >>>>> context, in addition to the definition in Section 6.4.1 >> >>>>> : >> >>>>> >> >>>>> o The context node is the node in the accessible tree for which the >> >>>>> "must" statement is defined. >> >>>>> >> >>>>> >> >>>>> The problem for input/output is that these nodes are not encoded >> >>>>> in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines >> >>>>> the >> >>>>> XPath context for input and output, so 7.5.3 is incorrect. >> >>>>> >> >>>>> 7.5.3 should say the context node for input/output is the node >> >>>>> representing >> >>>>> the RPC operation. This would be the same for NETCONF encoding of >> >>>>> action. >> >>>>> The RESTCONF encoding for RPC and action is completely different >> >>>>> but the definition in 7.5.3 is actually correct for RESTCONF. >> >>>> >> >>>> This should not depend on any encoding, an XPath expression is >> >>>> evaluated >> >>>> on a conceptual data tree, and this tree is defined for operations, >> >>>> too. >> >>>> >> >>>> >> >>>> >> >>>> The and nodes do not appear at all >> >>>> in the instance document for NETCONF so this bullet in 7.5.3 is wrong >> >>>> for those nodes. >> >>>> >> >>>> For , the child of is already specified >> >>>> as the child of docroot. >> >>> >> >>> OK, so this is about "must" statements specified directly under >> >>> input/output and notification statements, right? I had the same >> >>> comment previously: >> >>> >> >>> https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html >> >>> >> >>> My understanding is that in the former case the context node is the >> >>> root of the input/output data tree, and in the latter case it is the >> >>> node with the same name as the notification. >> >>> >> >>> I agree it should be better explained. >> >>> >> >>> >> >>> >> >>> If you already brought up this issue, then why is the text still >> >>> incorrect? >> >> >> >> The subsequent discussion convinced me that it can be easily fixed, >> >> and then I lost it from the radar, unfortunately. >> > >> > I lost track of this issue as well :( >> > >> > Anyway, I think my original proposed fix to this issue should work: >> > >> > OLD: >> > >> > o The context node is the node in the accessible tree for which the >> > "must" statement is defined. >> > >> > NEW: >> > >> > o If the "must" statement is a substatement of a "notification" >> > statement, the context node is the node representing the >> > notification in the accessible tree. >> > >> > o If the "must" statement is a substatement of a "input" >> > statement, the context node is the node representing the >> > operation in the accessible tree. >> > >> > o If the "must" statement is a substatement of a "output" >> > statement, the context node is the node representing the >> > operation in the accessible tree. >> >> What is "the node representing the operation in the accessible tree"? > > This is already defined in section 6.4.1. Again, note that the text > we're currently discussing does not alter the definition of the > accessible tree. For more background, see the old email thread to > which you provided a pointer. > > >> I think it should rather be "the root node of the operation >> request/reply instance". Unlike notifications, operations >> request/reply isn't wrapped in an element with the operation's name. > > Again, see the email thread (this is protocol specific) OK, got it. Lada > > > /martin > >> >> Lada >> >> > >> > o Otherwise, the context node is the node in the accessible tree >> > for which the "must" statement is defined. >> > >> > >> > Note that the original email thread quickly started to discuss the >> > accessible tree, but the proposed text above does not change the >> > accessible tree. >> > >> > >> > /martin >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jun 17 05:16:21 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D33F12D1A4; Fri, 17 Jun 2016 05:16:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.22.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160617121620.19171.77751.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2016 05:16:20 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-14.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 12:16:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : The YANG 1.1 Data Modeling Language Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc6020bis-14.txt Pages : 209 Date : 2016-06-17 Abstract: YANG is a data modeling language used to model configuration data, state data, remote procedure calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 17 06:23:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07F612D688 for ; Fri, 17 Jun 2016 06:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 iBESCS-kKyV7 for ; Fri, 17 Jun 2016 06:23:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F78B12D671 for ; Fri, 17 Jun 2016 06:23:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A171C834; Fri, 17 Jun 2016 15:23:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id v4ZaC3OjNmms; Fri, 17 Jun 2016 15:23:14 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Jun 2016 15:23:19 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 052E220054; Fri, 17 Jun 2016 15:23:19 +0200 (CEST) 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 uAM36JypZW2V; Fri, 17 Jun 2016 15:23:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FE2220031; Fri, 17 Jun 2016 15:23:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4E6393B28D36; Fri, 17 Jun 2016 15:23:17 +0200 (CEST) Date: Fri, 17 Jun 2016 15:23:16 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20160617132316.GA35266@elstar.local> Mail-Followup-To: Benoit Claise , netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: [netmod] YANG 1.1 - draft-ietf-netmod-rfc6020bis-14.txt ready X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:23:24 -0000 Benoit, Martin has posted revision -14 and I (in my role as document shepherd) believe -14 addresses all comments that we received during the IESG process. Please press any necessary buttons to continue the process. /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 Jun 17 06:35:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1812D5AB for ; Fri, 17 Jun 2016 06:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 2a-eVDxIzG90 for ; Fri, 17 Jun 2016 06:35:46 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 4433C12D0E2 for ; Fri, 17 Jun 2016 06:35:46 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id B5432D16CA4BD; Fri, 17 Jun 2016 13:35:43 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u5HDZiHL027466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 13:35:44 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u5HDZeEP031488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jun 2016 13:35:44 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 17 Jun 2016 09:34:32 -0400 From: "Sterne, Jason (Nokia - CA)" To: Juergen Schoenwaelder Thread-Topic: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt Thread-Index: AQHRxxrDqcSbCbxdqk+sJ01FZToTSJ/soRcAgADZdQCAADAJwA== Date: Fri, 17 Jun 2016 13:34:31 +0000 Message-ID: References: <20160615152932.GA31216@elstar.local> <20160617063826.GB34404@elstar.local> In-Reply-To: <20160617063826.GB34404@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:35:49 -0000 Hi Juergen, This model may be used in cases where no events are sent on any wire. Only= events sent on a 'remote' log-action would need to conform to RFC5424. In = that case there is the "destination-facility" override if needed. But for many of the other uses of the model for just configuring logging (a= nd event filtering) to buffer, file, console, etc it is very useful to have= the extensible facility concept. Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, June 17, 2016 2:38 To: Sterne, Jason (Nokia - CA) Cc: netmod@ietf.org Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.t= xt In ietf-syslog-types, there is a mapping of facility names to a limited num= ber space on the wire. Unfortunately, this mapping is not available in a ma= chine readable form. But for those names listed in RFC 5424, there is at le= ast a mapping defined in human readable form in the description clauses. Th= e examples given in A.1 are completely silent about which number is used on= the wire. I think this is a problem if you consider setups where a relay is expected = to filter on facility values. When an originator uses facility 'vendor:foo'= , what will that facility be from the viewpoint of a relay? /js On Thu, Jun 16, 2016 at 09:45:06PM +0000, Sterne, Jason (Nokia - CA) wrote: > Hi Juergen, >=20 > About the identities vs enum for 'facilities' -> I'm pretty sure it was d= iscussed on the list previously but I think the applicability of the model = is going to be much better if we allow extensible facilities. Several imp= lementations use proprietary facility names along with RFC5424 facility nam= es in a unified way to configure logging. >=20 > IMO this YANG model isn't exactly trying to match & reproduce RFC5424. R= FC5424 is more about the format of syslog messages on a wire. But this sys= log YANG model is more about how devices configure logging. >=20 > So I'm strongly in favor of seeing the facilities stay as an identity. >=20 > Regards, > Jason >=20 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Wednesday, June 15, 2016 11:30 > To: netmod@ietf.org > Subject: [netmod] partial review of=20 > draft-ietf-netmod-syslog-model-08.txt >=20 > Hi, >=20 > Dan Romascanu encouraged me to look at this I-D as part of his efforts to= organize YANG document reviews. Since the YANG definitions are not consist= ent with the tree diagram, I have not really looked at the YANG definitions= yet. So the comments below are essentially about the surrounding document = structure, terminology, etc. >=20 > - Abstract: The 'which is used to convey event notification messages' > may relate to 'the Syslog protocol' or 'a data model' and hence the > sentence is I think potentially confusing. Perhaps simply remove the > phrase altogether? Readers who do not know what SYSLOG is should > stop reading here anyway. Or break the sentence into two to make the > structure clearer. Perhaps add one more sentence describing what the > scope of the data model is. >=20 > - The text uses Syslog, syslog, and SYSLOG. It is not clear what the > difference is (if any). If there is no semantic difference, I > suggest to pick one writing style (and 5424 seems to prefer all > lowercase except in cases where a sentence starts etc). >=20 > - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 > to 'The ietf-syslog Module' or something similar and consider > changing the title of section 4 to "Syslog YANG Modules" since > it contains the definitions of the modules themselves. >=20 > - In section 2, should 'monitor and control' be 'configure and > monitor' in section 2? Are there actually definitions that support > monitoring? Perhaps the scope is just configuration? Otherwise, I > would have expected to see a bunch of basic counters (messages > received, forwarded, dropped, the usual monitoring stuff). >=20 > - In section 2, s/network management agents such as NETCONF/network > management protocols such as NETCONF/ >=20 > - In section 2, the phrase 'This module' is a hanging reference. There > is no prior text talking about a module. Perhaps replace with 'The > data model' >=20 > - I did not find the term 'message distributor' in RFC 5424. The > figure first made me assume that only a console, log buffers, or log > files are message distributors but later it was stated that relays > and collectors (RFC 5424 defined terms) are also 'message > distributors'. Perhaps it helps to clearly spell out terms imported > from RFC 5424 and to clearly define any additional terms that go > beyond what is defined in RFC 5424. >=20 > - Is it possible to shorten 'log-input-transports' to simply > 'log-inputs' (en par with log-actions)? And since both containers > are under syslog, perhaps even the 'log-' prefix is not needed and > all we have are /syslog/inputs and /syslog/actions? (I generally > find it useful to look at the resulting paths and whether they are > 'engineer friendly'. >=20 > - I guess I have to define multiple /syslog/input/receiver in order to > listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and > [::]:514? This may be just find - just checking that this is the > idea. >=20 > - I actually do not find the definition of log-input-transports in the > YANG model. It seems the tree diagram is not consistent with the > YANG model. So I can't judge what the structured-data boolean flag > is doing or what the syslog-sign presence container would do for > inputs. >=20 > - The security considerations are quite generic; I think the template > asks for a more specific discussion. >=20 > - I am not sure why RFC 6020 is an informative reference and why all > the normative references are actually normative. It might be useful > to go over the list to make sure we get the normative / informative > distinction right. >=20 > - My understanding is that RFC 5424 numbers facilities and there is a > hard limit on the number of facilities that the protocol can > distinguish. RFC 5424 says: >=20 > Facility values MUST be in the range of 0 to 23 inclusive. >=20 > Given this, the 'extending facilities' appendix does not make much > sense to me. And given the fact that the number of facilities is > fixed (which is due to the way things are encoded in RFC 5424), I am > not even sure that using an identity instead of an enumeration is > useful (except if we expect a future version of SYSLOG to use a very > different encoding of facilities). I mean, to stay within the bounds > of RFC 5424, all one can do is to add an identity that maps to an > already allocated code point. >=20 > - Do not use 1.1.1.1 as an example IP address, consider using an IPv6 > address from the IPv6 example address space. >=20 > - Section 4.3 should not be in Section 4 and the title 'A Syslog > Example' is kind of misleading since the text shows NETCONF messages > operating on the SYSLOG YANG data model. I suggest to move 4.3 to > a new top-level section 5 "Usage Examples". Does it make sense to > show some complete example configs for typical use cases? >=20 > - Before the YANG model definitions, it is a common idea to describe > what is imported from which RFCs. For example, one of the YANG > modules imports ietf-interfaces but there is no (normative) > reference to the relevant RFC. See the first sentence in section 4 > of RFC 7277 for an example how to do this. >=20 > - I suggest to remove the subsection title 3.1. or to change the title > to "SYSLOG Data Model" and lifting it up to the top-level so that it > becomes section 4. >=20 > As said above, I have not reviewed the YANG definitions yet since apparen= tly it is not in sync with the rest of the document. But I thought I send t= hese comments now anyway so that they can already be taken into account. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jun 17 07:51:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421FF12D518 for ; Fri, 17 Jun 2016 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-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 SLirrUJ9iEwo for ; Fri, 17 Jun 2016 07:51:52 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8169612D62F for ; Fri, 17 Jun 2016 07:51:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id D855E1E5D6D; Fri, 17 Jun 2016 07:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hxNOHC1iih-0; Fri, 17 Jun 2016 07:51:07 -0700 (PDT) Received: from [192.168.1.100] (host81-132-48-184.range81-132.btcentralplus.com [81.132.48.184]) by c8a.amsl.com (Postfix) with ESMTPSA id 0E6B81E5D67; Fri, 17 Jun 2016 07:51:06 -0700 (PDT) From: William Lupton Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jun 2016 15:51:49 +0100 To: netmod@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [netmod] bits lexical representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:51:53 -0000 RFC 6020bis Section 9.7.2 is silent on the question of whether bit names = can be repeated in a bits value, e.g is =E2=80=9Cuno dos dos tres=E2=80=9D= valid or invalid? Obviously repetition is not to be encouraged but is = it forbidden? Maybe this is a case where the robustness principle should = be applied? Thanks, William.= From nobody Fri Jun 17 07:53:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14F212D68D for ; Fri, 17 Jun 2016 07:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 76AAQHqJRIZg for ; Fri, 17 Jun 2016 07:53:18 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0A012D518 for ; Fri, 17 Jun 2016 07:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=500; q=dns/txt; s=iport; t=1466175198; x=1467384798; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=364rxtf///ASfv4uVDnQ0LgD/U0S+XDEx/rXMtACDC8=; b=M95dlLw0hDwtzzm91j5D9Sg0cQEKVB9jEtoqCOsWIxzU1FYe/T/0V8+N 1nDxTyQZ6Ea7PUbS9dkuzIad34+VRypNKta/n70ZrdrD9VoMXEcGoUqrb MqOhLHFt8LksQmWvOuf99QgWDAAHkLpqe6aBmn2+PYjaD8aCp6VW6Guan E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgB4DWRX/xbLJq1chD+5IYIPgXqGF?= =?us-ascii?q?wKBXBQBAQEBAQEBZSeETAEBBDg8FQtGVxMIAQEQiBzBFQEBAQEGAgEkhieBd4J?= =?us-ascii?q?WhQyFDwEEmHGOKYFTFoRSgwqFXY91HjaDcjqKLQEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,484,1459814400"; d="scan'208";a="635227875" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 14:53:16 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5HErGS0002241 for ; Fri, 17 Jun 2016 14:53:16 GMT To: netmod@ietf.org References: <20160617132316.GA35266@elstar.local> From: Benoit Claise Message-ID: Date: Fri, 17 Jun 2016 16:53:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160617132316.GA35266@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] YANG 1.1 - draft-ietf-netmod-rfc6020bis-14.txt ready X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 14:53:20 -0000 Happy to see this. Let me execute on this now, and approve this draft. Next stage is the RFC editor queue. Thanks to Martin as the editor, the doc. shepherd, the WG chairs, and the entire NETMOD community for this new standard. Regards, Benoit > Benoit, > > Martin has posted revision -14 and I (in my role as document shepherd) > believe -14 addresses all comments that we received during the IESG > process. Please press any necessary buttons to continue the process. > > /js > From nobody Fri Jun 17 08:17:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8812D764; Fri, 17 Jun 2016 08:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWwJZz3M9U0q; Fri, 17 Jun 2016 08:17:46 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD51F12D766; Fri, 17 Jun 2016 08:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xcImB8/gNREMS85dd7In6OaSf23duhn8XgTiIpC0RBE=; b=grVmxYv63HQmAuHEEdN1/5SB1C+bQU2CK0wFpx9wqxzdLP9EUWTDIryNMaWaxMVrczZGo3u9nRvaygerDcKvlxgrlJ92hD/pdsPvAY+7VZ8emcA3gN/Vz9eLQ/XEkwgoixUUgrwParClRjoQ+FpBcc3sZTiuHAyg/zSu5Lm1pNE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.165.8) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 17 Jun 2016 15:17:27 +0000 Message-ID: <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> From: t.petch To: Lou Berger , netmod WG References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> Date: Fri, 17 Jun 2016 16:15:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.165.8] X-ClientProxiedBy: DB5PR08CA0039.eurprd08.prod.outlook.com (10.163.102.177) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) X-MS-Office365-Filtering-Correlation-Id: e030dc78-0583-4b48-babd-08d396c27e8d X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:gg2e4v7gFoT0+aYZY8lYHxHIIAyfk+7mh3ramGYF44SW/2vcrr4px6AqUqjmdEtCQ3DB8TGsxTJDnvEX+YMuekyN429ZhXeA4kW5zMc1FaFm1xKgpVjFScUQDxlPveoaGJwsGCK8PGocOizdFFIi1jSEYIdLZjN3+elyQ/8gUTGplJ9HiPWoSI1U0Xu0zurz; 3:11yYHxuXPe8WsNhi8F9liUMHhjiC+siEHkbHdUYssPuRyqmA/MpqcuQX5dGq1cPwGQu9pAzWtjiD7m3s61k2hHw8Z8TpufoPEEdyVCJN7EH9UnTmKPdjeg/UYXEzhxZx; 25:umpwPiSFp8QatNFGhQ90tMLt1xbmUtAXzjj3vQaxmncL2587CUA07y9RF48j+NN8uoJeCCahJqhdejEfoVs+HYg8eH3tSdEd3G4GdwVPWb12zixgm/geYnglaQdbdtAN6+85K0WHAFZDkGgl/Y5eYeB4O81JFaTk4tv0zZXk9aOOBRd+/arjuPnbgv+CvQupnefm8146g0KkmLBkpssccEGOWtMZrUzZ5WCEUI5cqdeEoVHroNyQkwfZ+Q7gVm91hlwyVcH5ciadYVDHXNr77+u8LOCGF0TpsatDubIYjSXmqOasT2VvAMk/IzsCnHf/o3l8s2wtxUeShQr9kb49oUqvCjmiNEKbcr6HQHDuyXJ1fyVl/tLgPeRrySjmummHVdo6Vqmcc/VV+05nFwuFbumhYQm22J46BsKQrHHDJBU= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:8qQzt8DgxP+K4IrrTsCgF8Pri4b2WHi/if4VXLwPD25B+9w9DnmSwUIzvkwOeqBxBeqreR6XuIQU3f7bXJJDeVswggs3/mn+EVYtQKLzY3228r8dqWz12ufQHUQS19Cw//fxkxCessQKS9FP6FnVvXxX4m+vA0IIKZbGc6TotKJ/I603D11rqowqDw8WBbtPg113rh8qhrs9/JXPV4NKCQdOBNB5bmlj2o8q6VlS3xYGZ+SMJzPpJ3U59A9q8FCQ13Ugg5HJZjwFB4/CsAoY5qsRAqQl5C1WExHbIhrFGErQrFqghh3J49oUfeTpl51/tjYDQf53Z2FUNB8YbeSOIPVY4Ik0rl0bIdDEkt8kSXszH/Bmk10PyJja9aJI4gVG X-Forefront-PRVS: 09760A0505 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(189002)(377454003)(13464003)(199003)(101416001)(81156014)(561944003)(106356001)(81166006)(5008740100001)(33646002)(66066001)(77096005)(15975445007)(50466002)(105586002)(62236002)(2906002)(44716002)(47776003)(84392002)(4326007)(86362001)(8676002)(42186005)(44736004)(230700001)(81686999)(76176999)(50986999)(50226002)(14496001)(6116002)(3846002)(586003)(19580395003)(61296003)(23756003)(81816999)(5004730100002)(19580405001)(15650500001)(5001770100001)(97736004)(9686002)(1456003)(1556002)(189998001)(68736007)(116806002)(92566002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB1622; 23:fX2zkCgZHb8uef2fkQ7YFTJ5b4+rhBZnbgggmMY?= =?iso-8859-1?Q?Uz3KnACUAo+xVYcmFKgj+U4NpZ2/NRE9l69AdgRjLOs3M6oAdSRvb76bwz?= =?iso-8859-1?Q?HmvAaxx6rfjMnTQ9QqVCRpF8E5t31ktzgSV7YkAzsmkUnPyM0bH29GESEM?= =?iso-8859-1?Q?UyC7OJsgZemUa5ite1gyrM2srjVsF+T7Y/l2VW3WU8Q1UHD9B4fPkza50p?= =?iso-8859-1?Q?CbNPsIylzMv/PHlA3DRimVKCRUrMMSKw6zZlF0scCLGIy8WNpcjKHoE9z9?= =?iso-8859-1?Q?Elr3DIuGDBQYxsfGJQMSLXAVBQ9f9bxnaQu0NRKUNTFFm9RCZZBGQClPBV?= =?iso-8859-1?Q?fJV5QZVKhGHLut/95pbwoTM+iGvvq70Vgq2NfuuCmagsEp538CYEGDozrI?= =?iso-8859-1?Q?pxdJmRP4He8n7E7xnkMDZWofzpDQ11I0PkRSGmzexboyn8mocfXZ829o/C?= =?iso-8859-1?Q?JAqLZI7q1FVNJT/c6lMwQQAUljrXQWIE+k8Wc1lBr2owrjgIdgw/zgmxIK?= =?iso-8859-1?Q?RSp8R+m9aYTCUOn9O2KHp8kYbXXpwJuMtcEsX7TaGyxRwbQwFqQ6br47iU?= =?iso-8859-1?Q?oe3FJAtXIoOFKif2vStoZiR505LHi5YlrwBVvasXLb9ZfywzY4V82ootWp?= =?iso-8859-1?Q?eVpLNbsx6Upw3JcdRtejy4R1B+msrPO/EgasKEArNfzmjYgy5rgVAOphXU?= =?iso-8859-1?Q?D10CfJeaZWzg83NmQ5FlO/1Bwn+/9UVNAHszaAi+b50lMV+TPs7onIkWKP?= =?iso-8859-1?Q?gVPfDB35C9uUznYJtLkzTuFkOOuvSfT2AdpDgpCahQ0YrQjzvJmENaKrxo?= =?iso-8859-1?Q?YGm4IQt9A9P2sKW8PQfRCp88PFGAAkmKhD09QXLWCmJipPoNEFfmw4hLxZ?= =?iso-8859-1?Q?vMWE1SFNM8E/RUCViNuDcAz59nXnghhXuuG7UKYouy2j4tQiLNDFtqyuT+?= =?iso-8859-1?Q?lO1bIvDwY530EsN5ULgZkJswP1EGyztdnr+RhND9LpyEHp56vzDsLOmtAc?= =?iso-8859-1?Q?bLB8JRXP4KHZ5ZwFTSUJfwzo4GXV9T4B1aoo8IfKI8EFqgzKse73P9YxtQ?= =?iso-8859-1?Q?ZUELXEN+N9ops9+d889I3JNBrs0AM3qDceY8ic09YH1HHW6AwWPgSuaJ+D?= =?iso-8859-1?Q?r3NRxXPs3RuBvJtv0IMkq3bivR8FPRRW0a0Ns/7oGXaK8kbhWfDa8rIasO?= =?iso-8859-1?Q?JE7Uifwxu36mCU4eLkMMqmvmtsN3RFXI/m7EU8wcdRThTBa2e3E9m9kVjz?= =?iso-8859-1?Q?xLQ+awzSWoxgX+JGq/BWKjv6FkLHs3k9XbTG+8BIxz219KGj56+UZL5DDE?= =?iso-8859-1?Q?+GRWleF4EG30Ekz+ZI2P/5Ci6NUH6MqWSyIzDwWHRqujRlwTxI/QEKNktD?= =?iso-8859-1?Q?E86WNq8DdhKlRxVNdZy5WiiZCkl23eM2KpznCZEdLueEW4TOPX+ElPwuEM?= =?iso-8859-1?Q?zSgYiRtZ0P4AZ4IzNtr86VXWo5Y7ZUI4D1VG9NgVUt/sIvrf3gWIKBpiA?= =?iso-8859-1?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 6:FfoJ/cg2Tr0r3c4wJoLPUfs/afm6u/Hh295LcQ7Tg+BhkeiqwxNBENyBWwyVYQ7SKuExo/ci3DtlbmVJvWn5zP9lBBYScA00vXIwZLXQv48JpNnxvFoYQqv1tqQxjgHv3wLYblLuzjfrkOArbvUrqOs1lCfo5KnCqEskaIuVM2iqo0rXdWcnZqkKS1gpUvGLeqZgT+ggcL9Oy9pHLQxldikYxaB/RTLe3xq5PdsLdBBnz/m9n9N8KT+SzJvDj2urfouELztX0quuo6FnMVXcrnT+yfSoPcRZtHO/TgQu88c=; 5:vWzv0cmY1D8q7ffId4/THV3S62m3U2/TGmQQRjalqRe+1FM/4Y7JNjy6UidGVJk1VOQ+lsd2Rh8c3D3aFqtE0ZNgiyjjIpppT6dajppVDG62BAAGWgxfwjuFaWDjPMPLBSi5fZO0c4Klgk3EaJvEWw==; 24:miTKv+VhbCO7XQrP2iAdzk5jyQuwTNdSSipQSX0ePNqL2eDn+/oVVgfyjLoXuaJ8XQQnTYVrruuwQ+IL6sry0fRVwCTTOrSRO4yFKAfyWio=; 7:WmP9t523vyatibyabQJ0bHe+cZWCUak7IiexBG76VsV6oEtNkPL4kwuQk3isr0aRXPdeU6V0lYeKaZ1ZW9esh9t4fikW5gaMbjh7ydPdVobRhBMMFICRG//LeUYo7Um7sb5aVQ8AONsc6loyoaazgbPj7EzD4vKTcKXVhuXX6hczS5QMxamd1rSi7hMJ9d7YcIcVZqJHGFDJ2djU/16KxA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2016 15:17:27.8449 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622 Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 15:17:48 -0000 Lou By now, 17th June, I see solid support for one option but only see comments from a somewhat small number of participants The majority of the authors of the 172 YANG files I have in an archive are probably unaware of this discussion and yet some at least will be affected. What concerns me is that history might be repeating itself. In a sense, this discussion is about the original proposals for NETCONF and YANG not meeting current requirements which may be because there has mostly been a limited number of participants in netmod discussions. I was struck by Dale's recent, brilliant review of 6020bis because it came from a fresh angle and brought up nagging concerns that I had had but had not been able to articulate. With a wider audience, similar comments might have been made much earlier to the advantage of YANG (perhaps even about RFC6020). In the same vein, there is NETCONF. Juergen's I-D, which I see finding favour, could be said to cut the ground from under NETCONF (well, I would). RFC6241 says " Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics. " The proposed 'intended' in the I-D is (ct, ro). It is ct, configuration true, so it is configuration data. It is ro, read only, so it is clearly not configuration data. Without changing RFC6241, I cannot reconcile this. So I see RFC6241 being changed; can anyone reading the RFC understand it any more? And yet the I-D makes no mention of this change to NETCONF nor have I seen any discussion on the netconf list. Stimulated by posts to the I2RS list, perhaps also a trigger for Juergen's I-D, I wrote up my own summary of the current state of datastores but I called it draft-tp-netconf-datastore because I see NETCONF currently telling us almost all that we know about datastores; YANG 1.0 adds very little. For me, NETCONF should be the starting point. Tom Petch ----- Original Message ----- From: "Lou Berger" To: "netmod WG" Cc: Sent: Tuesday, June 07, 2016 3:19 PM > All, > > We want to provide an update based on the off line discussions > related to OpState Solutions that we have been having and solicit > input from the WG. > > All authors of current solution drafts [1,2,3] together with those > who helped conduct the solutions analysis* were invited to the these > discussions -- with the objective of coming up with a single > consolidated proposal to bring to the WG. (I/Lou acted as facilitator > as Kent and Juergen were and are involved with the technical details.) > > The discussions have yielded some results but, unfortunately, > not a single consolidated proposal as hoped, but rather two > alternate directions -- and clearly we need to choose one: > > 1) Adopt the conventions for representing state/config > based on Section 6 of [1]. > > From a model definition perspective, these conventions > impact every model and every model writer. > > 2) Model OpState using a revised logical datastore definition > as introduced in [4] and also covered in [5]. There is > also a variant of this that we believe doesn't significantly > impact this choice. > > With this approach, model definitions need no explicit > changes to support applied configuration. > > >From a technology/WG standpoint, we believe an approach > that doesn't impact every model written (i.e., #2) is superior. > The counterpoint to this is that the conventions based > approach (i.e., #1) is available today and being followed in > OpenConfig defined models. > > We would like to hear opinions on this from the WG before > declaring one of the following as the WG direction: > > A) models that wish to support applied configuration MUST > follow conventions based on [1] -- and the WG needs to > formalize these conventions. > or > B) no explicit support is required for models to support > applied configuration -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. > > We intend to close on this choice before Berlin. > > Thank you, > Lou (and co-chairs) > > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > * - Chris H. and Acee L. > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Jun 17 09:09:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696EC12D7F8 for ; Fri, 17 Jun 2016 09:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 iyd0TSpbeF53 for ; Fri, 17 Jun 2016 09:09:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E7312D665 for ; Fri, 17 Jun 2016 09:09:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9403087A; Fri, 17 Jun 2016 18:09:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5fxbjU37Wzjy; Fri, 17 Jun 2016 18:09:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Jun 2016 18:09:35 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4724320055; Fri, 17 Jun 2016 18:09:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m8VJ4rOk10bI; Fri, 17 Jun 2016 18:09:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B61B020047; Fri, 17 Jun 2016 18:09:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BDD1D3B29106; Fri, 17 Jun 2016 18:09:29 +0200 (CEST) Date: Fri, 17 Jun 2016 18:09:29 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA)" Message-ID: <20160617160929.GA35470@elstar.local> Mail-Followup-To: "Sterne, Jason (Nokia - CA)" , "netmod@ietf.org" References: <20160615152932.GA31216@elstar.local> <20160617063826.GB34404@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: "netmod@ietf.org" Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 16:09:43 -0000 Then this probably needs to be more clearly spelled out. /js On Fri, Jun 17, 2016 at 01:34:31PM +0000, Sterne, Jason (Nokia - CA) wrote: > Hi Juergen, > > This model may be used in cases where no events are sent on any wire. Only events sent on a 'remote' log-action would need to conform to RFC5424. In that case there is the "destination-facility" override if needed. > > But for many of the other uses of the model for just configuring logging (and event filtering) to buffer, file, console, etc it is very useful to have the extensible facility concept. > > Jason > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, June 17, 2016 2:38 > To: Sterne, Jason (Nokia - CA) > Cc: netmod@ietf.org > Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt > > In ietf-syslog-types, there is a mapping of facility names to a limited number space on the wire. Unfortunately, this mapping is not available in a machine readable form. But for those names listed in RFC 5424, there is at least a mapping defined in human readable form in the description clauses. The examples given in A.1 are completely silent about which number is used on the wire. > > I think this is a problem if you consider setups where a relay is expected to filter on facility values. When an originator uses facility 'vendor:foo', what will that facility be from the viewpoint of a relay? > > /js > > On Thu, Jun 16, 2016 at 09:45:06PM +0000, Sterne, Jason (Nokia - CA) wrote: > > Hi Juergen, > > > > About the identities vs enum for 'facilities' -> I'm pretty sure it was discussed on the list previously but I think the applicability of the model is going to be much better if we allow extensible facilities. Several implementations use proprietary facility names along with RFC5424 facility names in a unified way to configure logging. > > > > IMO this YANG model isn't exactly trying to match & reproduce RFC5424. RFC5424 is more about the format of syslog messages on a wire. But this syslog YANG model is more about how devices configure logging. > > > > So I'm strongly in favor of seeing the facilities stay as an identity. > > > > Regards, > > Jason > > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Wednesday, June 15, 2016 11:30 > > To: netmod@ietf.org > > Subject: [netmod] partial review of > > draft-ietf-netmod-syslog-model-08.txt > > > > Hi, > > > > Dan Romascanu encouraged me to look at this I-D as part of his efforts to organize YANG document reviews. Since the YANG definitions are not consistent with the tree diagram, I have not really looked at the YANG definitions yet. So the comments below are essentially about the surrounding document structure, terminology, etc. > > > > - Abstract: The 'which is used to convey event notification messages' > > may relate to 'the Syslog protocol' or 'a data model' and hence the > > sentence is I think potentially confusing. Perhaps simply remove the > > phrase altogether? Readers who do not know what SYSLOG is should > > stop reading here anyway. Or break the sentence into two to make the > > structure clearer. Perhaps add one more sentence describing what the > > scope of the data model is. > > > > - The text uses Syslog, syslog, and SYSLOG. It is not clear what the > > difference is (if any). If there is no semantic difference, I > > suggest to pick one writing style (and 5424 seems to prefer all > > lowercase except in cases where a sentence starts etc). > > > > - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 > > to 'The ietf-syslog Module' or something similar and consider > > changing the title of section 4 to "Syslog YANG Modules" since > > it contains the definitions of the modules themselves. > > > > - In section 2, should 'monitor and control' be 'configure and > > monitor' in section 2? Are there actually definitions that support > > monitoring? Perhaps the scope is just configuration? Otherwise, I > > would have expected to see a bunch of basic counters (messages > > received, forwarded, dropped, the usual monitoring stuff). > > > > - In section 2, s/network management agents such as NETCONF/network > > management protocols such as NETCONF/ > > > > - In section 2, the phrase 'This module' is a hanging reference. There > > is no prior text talking about a module. Perhaps replace with 'The > > data model' > > > > - I did not find the term 'message distributor' in RFC 5424. The > > figure first made me assume that only a console, log buffers, or log > > files are message distributors but later it was stated that relays > > and collectors (RFC 5424 defined terms) are also 'message > > distributors'. Perhaps it helps to clearly spell out terms imported > > from RFC 5424 and to clearly define any additional terms that go > > beyond what is defined in RFC 5424. > > > > - Is it possible to shorten 'log-input-transports' to simply > > 'log-inputs' (en par with log-actions)? And since both containers > > are under syslog, perhaps even the 'log-' prefix is not needed and > > all we have are /syslog/inputs and /syslog/actions? (I generally > > find it useful to look at the resulting paths and whether they are > > 'engineer friendly'. > > > > - I guess I have to define multiple /syslog/input/receiver in order to > > listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and > > [::]:514? This may be just find - just checking that this is the > > idea. > > > > - I actually do not find the definition of log-input-transports in the > > YANG model. It seems the tree diagram is not consistent with the > > YANG model. So I can't judge what the structured-data boolean flag > > is doing or what the syslog-sign presence container would do for > > inputs. > > > > - The security considerations are quite generic; I think the template > > asks for a more specific discussion. > > > > - I am not sure why RFC 6020 is an informative reference and why all > > the normative references are actually normative. It might be useful > > to go over the list to make sure we get the normative / informative > > distinction right. > > > > - My understanding is that RFC 5424 numbers facilities and there is a > > hard limit on the number of facilities that the protocol can > > distinguish. RFC 5424 says: > > > > Facility values MUST be in the range of 0 to 23 inclusive. > > > > Given this, the 'extending facilities' appendix does not make much > > sense to me. And given the fact that the number of facilities is > > fixed (which is due to the way things are encoded in RFC 5424), I am > > not even sure that using an identity instead of an enumeration is > > useful (except if we expect a future version of SYSLOG to use a very > > different encoding of facilities). I mean, to stay within the bounds > > of RFC 5424, all one can do is to add an identity that maps to an > > already allocated code point. > > > > - Do not use 1.1.1.1 as an example IP address, consider using an IPv6 > > address from the IPv6 example address space. > > > > - Section 4.3 should not be in Section 4 and the title 'A Syslog > > Example' is kind of misleading since the text shows NETCONF messages > > operating on the SYSLOG YANG data model. I suggest to move 4.3 to > > a new top-level section 5 "Usage Examples". Does it make sense to > > show some complete example configs for typical use cases? > > > > - Before the YANG model definitions, it is a common idea to describe > > what is imported from which RFCs. For example, one of the YANG > > modules imports ietf-interfaces but there is no (normative) > > reference to the relevant RFC. See the first sentence in section 4 > > of RFC 7277 for an example how to do this. > > > > - I suggest to remove the subsection title 3.1. or to change the title > > to "SYSLOG Data Model" and lifting it up to the top-level so that it > > becomes section 4. > > > > As said above, I have not reviewed the YANG definitions yet since apparently it is not in sync with the rest of the document. But I thought I send these comments now anyway so that they can already be taken into account. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > 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 Fri Jun 17 09:18:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A06112D849; Fri, 17 Jun 2016 09:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 jDU82dmiQVFi; Fri, 17 Jun 2016 09:18:32 -0700 (PDT) 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 1151912D845; Fri, 17 Jun 2016 09:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7818; q=dns/txt; s=iport; t=1466180311; x=1467389911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KuhSe+DEyrZd43k1pFnqaC8ni5GHZyVv0rC4SP2w2kI=; b=GYyQjeUun0gaAQCW/csQWIqJeZtz/UaFxtUBrupKnX7Iy1Py8+HxfDpq G0uqrGLqnduKfqxxluSNufopjnaiuGU30Ce0PJpOQ91JhAWKBODz7RO1u aLpqb1bxOqvkuSSFxzWXbXn+acrE71QfQ3B8Mzox6Az6aC2px4k01Uii0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgCHImRX/4ENJK1dgz5WfQa6WIF6F?= =?us-ascii?q?wuFK0oCHIEIOBQBAQEBAQEBZSeESwEBAQMBAQEBIBE6CwwEAgEIFQEEAiYCAgI?= =?us-ascii?q?lCxUQAgQBDQUbiA0IDrAvkEkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBiXOBI?= =?us-ascii?q?oJ6JIMBgloFmHEBhgSIJIFph3+FOoZOiSYBHjaCCByBTG6IN0V/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,484,1459814400"; d="scan'208";a="114431402" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jun 2016 16:18:30 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5HGIUKZ021334 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2016 16:18:30 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.1104.5; Fri, 17 Jun 2016 12:18:29 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 17 Jun 2016 12:18:29 -0400 From: "Acee Lindem (acee)" To: "t.petch" , Lou Berger , netmod WG Thread-Topic: [netmod] Opstate solutions discussions: update and request for WGinput Thread-Index: AQHRyKtxP5fYeOFAwE2wfn1UHIw1w5/t1mkA Date: Fri, 17 Jun 2016 16:18:29 +0000 Message-ID: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> In-Reply-To: <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.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.200] Content-Type: text/plain; charset="utf-8" Content-ID: <4403C701EFE73D4CA98812A5115670F4@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod-chairs@ietf.org" Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 16:18:34 -0000 SGkgVG9tLCANCkF0IGxlYXN0IG1vc3Qgb2YgdGhlIFlBTkcgbW9kZWwgYXV0aG9ycyB0aGF0IEkg d29yayB3aXRoIGFyZSBmb2xsb3dpbmcNCnRoaXMgZGlzY3Vzc2lvbi4gSG93ZXZlciwgSSB3b3Vs ZCBndWVzcyB0aGF0IG1hbnkgYXJlIHdhaXRpbmcgZm9yIHRoZQ0Kb3V0Y29tZSBhbmQgaG93IGl0 IGFmZmVjdHMgbW9kZWwgc3RydWN0dXJlIGFzIG9wcG9zZWQgdG8gaGF2aW5nIGEgc3Ryb25nDQpv cGluaW9uIG9uIHRoZSBvcHRpb25zLg0KVGhhbmtzLA0KQWNlZSANCg0KT24gNi8xNy8xNiwgMTE6 MTUgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIHQucGV0Y2giDQo8bmV0bW9kLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIGlldGZjQGJ0Y29ubmVjdC5jb20+IHdyb3RlOg0KDQo+TG91DQo+ DQo+Qnkgbm93LCAxN3RoIEp1bmUsIEkgc2VlIHNvbGlkIHN1cHBvcnQgZm9yIG9uZSBvcHRpb24g YnV0IG9ubHkgc2VlDQo+Y29tbWVudHMgZnJvbSBhIHNvbWV3aGF0IHNtYWxsIG51bWJlciBvZiBw YXJ0aWNpcGFudHMNCj4NCj5UaGUgbWFqb3JpdHkgb2YgdGhlIGF1dGhvcnMgb2YgdGhlIDE3MiBZ QU5HIGZpbGVzIEkgaGF2ZSBpbiBhbg0KPmFyY2hpdmUgYXJlIHByb2JhYmx5IHVuYXdhcmUgb2Yg dGhpcyBkaXNjdXNzaW9uIGFuZCB5ZXQgc29tZSBhdCBsZWFzdA0KPndpbGwgYmUgYWZmZWN0ZWQu ICBXaGF0IGNvbmNlcm5zIG1lIGlzIHRoYXQgaGlzdG9yeSBtaWdodCBiZSByZXBlYXRpbmcNCj5p dHNlbGYuICBJbiBhIHNlbnNlLCB0aGlzIGRpc2N1c3Npb24gaXMgYWJvdXQgdGhlIG9yaWdpbmFs IHByb3Bvc2FscyBmb3INCj5ORVRDT05GIGFuZCBZQU5HIG5vdCBtZWV0aW5nIGN1cnJlbnQgcmVx dWlyZW1lbnRzIHdoaWNoDQo+bWF5IGJlIGJlY2F1c2UgdGhlcmUgaGFzIG1vc3RseSBiZWVuIGEg bGltaXRlZCBudW1iZXIgb2YNCj5wYXJ0aWNpcGFudHMgaW4gbmV0bW9kIGRpc2N1c3Npb25zLg0K Pg0KPkkgd2FzIHN0cnVjayBieSBEYWxlJ3MgcmVjZW50LCBicmlsbGlhbnQgcmV2aWV3IG9mIDYw MjBiaXMgYmVjYXVzZSBpdA0KPmNhbWUgZnJvbSBhIGZyZXNoIGFuZ2xlIGFuZCBicm91Z2h0IHVw IG5hZ2dpbmcgY29uY2VybnMgdGhhdCBJIGhhZCBoYWQNCj5idXQgaGFkIG5vdCBiZWVuIGFibGUg dG8gYXJ0aWN1bGF0ZS4gIFdpdGggYSB3aWRlciBhdWRpZW5jZSwgc2ltaWxhcg0KPmNvbW1lbnRz IG1pZ2h0IGhhdmUgYmVlbiBtYWRlIG11Y2ggZWFybGllciB0byB0aGUgYWR2YW50YWdlDQo+b2Yg WUFORyAocGVyaGFwcyBldmVuIGFib3V0IFJGQzYwMjApLg0KPg0KPkluIHRoZSBzYW1lIHZlaW4s IHRoZXJlIGlzIE5FVENPTkYuICBKdWVyZ2VuJ3MgSS1ELCB3aGljaCBJIHNlZSBmaW5kaW5nDQo+ ZmF2b3VyLCBjb3VsZCBiZSBzYWlkIHRvIGN1dCB0aGUgZ3JvdW5kIGZyb20gdW5kZXIgTkVUQ09O RiAod2VsbCwgSQ0KPndvdWxkKS4gIFJGQzYyNDEgc2F5cw0KPiIgQ29uZmlndXJhdGlvbiBkYXRh IGlzIHRoZSBzZXQgb2Ygd3JpdGFibGUgZGF0YSB0aGF0IGlzIHJlcXVpcmVkIHRvDQo+ICAgdHJh bnNmb3JtIGEgc3lzdGVtIGZyb20gaXRzIGluaXRpYWwgZGVmYXVsdCBzdGF0ZSBpbnRvIGl0cyBj dXJyZW50DQo+ICAgc3RhdGUuICBTdGF0ZSBkYXRhIGlzIHRoZSBhZGRpdGlvbmFsIGRhdGEgb24g YSBzeXN0ZW0gdGhhdCBpcyBub3QNCj4gICBjb25maWd1cmF0aW9uIGRhdGEgc3VjaCBhcyByZWFk LW9ubHkgc3RhdHVzIGluZm9ybWF0aW9uIGFuZCBjb2xsZWN0ZWQNCj4gICBzdGF0aXN0aWNzLiAg Ig0KPg0KPlRoZSBwcm9wb3NlZCAnaW50ZW5kZWQnIGluIHRoZSBJLUQgaXMgKGN0LCBybykuICBJ dCBpcyBjdCwgY29uZmlndXJhdGlvbg0KPnRydWUsIHNvIGl0IGlzIGNvbmZpZ3VyYXRpb24gZGF0 YS4gIEl0IGlzIHJvLCByZWFkIG9ubHksIHNvIGl0IGlzDQo+Y2xlYXJseSBub3QNCj5jb25maWd1 cmF0aW9uIGRhdGEuICBXaXRob3V0IGNoYW5naW5nIFJGQzYyNDEsIEkgY2Fubm90IHJlY29uY2ls ZSB0aGlzLg0KPg0KPlNvIEkgc2VlIFJGQzYyNDEgYmVpbmcgY2hhbmdlZDsgY2FuIGFueW9uZSBy ZWFkaW5nIHRoZSBSRkMgdW5kZXJzdGFuZCBpdA0KPmFueSBtb3JlPyAgQW5kIHlldCB0aGUgSS1E IG1ha2VzIG5vIG1lbnRpb24gb2YgdGhpcyBjaGFuZ2UgdG8NCj5ORVRDT05GIG5vciBoYXZlIEkg c2VlbiBhbnkgZGlzY3Vzc2lvbiBvbiB0aGUgbmV0Y29uZiBsaXN0Lg0KPg0KPlN0aW11bGF0ZWQg YnkgcG9zdHMgdG8gdGhlIEkyUlMgbGlzdCwgcGVyaGFwcyBhbHNvIGEgdHJpZ2dlciBmb3INCj5K dWVyZ2VuJ3MgSS1ELCBJIHdyb3RlIHVwIG15IG93biBzdW1tYXJ5IG9mIHRoZSBjdXJyZW50IHN0 YXRlIG9mDQo+ZGF0YXN0b3JlcyBidXQgSSBjYWxsZWQgaXQgZHJhZnQtdHAtbmV0Y29uZi1kYXRh c3RvcmUgYmVjYXVzZSBJIHNlZQ0KPk5FVENPTkYNCj5jdXJyZW50bHkgdGVsbGluZyB1cyBhbG1v c3QgYWxsIHRoYXQgd2Uga25vdyBhYm91dCBkYXRhc3RvcmVzOyBZQU5HIDEuMA0KPmFkZHMgdmVy eSBsaXR0bGUuICBGb3IgbWUsIE5FVENPTkYgc2hvdWxkIGJlIHRoZSBzdGFydGluZyBwb2ludC4N Cj4NCj5Ub20gUGV0Y2gNCj4NCj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+RnJvbTog IkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KPlRvOiAibmV0bW9kIFdHIiA8bmV0bW9k QGlldGYub3JnPg0KPkNjOiA8bmV0bW9kLWNoYWlyc0BpZXRmLm9yZz4NCj5TZW50OiBUdWVzZGF5 LCBKdW5lIDA3LCAyMDE2IDM6MTkgUE0NCj4NCj4+IEFsbCwNCj4+DQo+PiBXZSB3YW50IHRvIHBy b3ZpZGUgYW4gdXBkYXRlIGJhc2VkIG9uIHRoZSBvZmYgbGluZSBkaXNjdXNzaW9ucw0KPj4gcmVs YXRlZCB0byBPcFN0YXRlIFNvbHV0aW9ucyB0aGF0IHdlIGhhdmUgYmVlbiBoYXZpbmcgYW5kIHNv bGljaXQNCj4+IGlucHV0IGZyb20gdGhlIFdHLg0KPj4NCj4+IEFsbCBhdXRob3JzIG9mIGN1cnJl bnQgc29sdXRpb24gZHJhZnRzIFsxLDIsM10gdG9nZXRoZXIgd2l0aCB0aG9zZQ0KPj4gd2hvIGhl bHBlZCBjb25kdWN0IHRoZSBzb2x1dGlvbnMgYW5hbHlzaXMqIHdlcmUgaW52aXRlZCB0byB0aGUg dGhlc2UNCj4+IGRpc2N1c3Npb25zIC0tIHdpdGggdGhlIG9iamVjdGl2ZSBvZiBjb21pbmcgdXAg d2l0aCBhIHNpbmdsZQ0KPj4gY29uc29saWRhdGVkIHByb3Bvc2FsIHRvIGJyaW5nIHRvIHRoZSBX Ry4gKEkvTG91IGFjdGVkIGFzIGZhY2lsaXRhdG9yDQo+PiBhcyBLZW50IGFuZCBKdWVyZ2VuIHdl cmUgYW5kIGFyZSBpbnZvbHZlZCB3aXRoIHRoZSB0ZWNobmljYWwgZGV0YWlscy4pDQo+Pg0KPj4g VGhlIGRpc2N1c3Npb25zIGhhdmUgeWllbGRlZCBzb21lIHJlc3VsdHMgYnV0LCB1bmZvcnR1bmF0 ZWx5LA0KPj4gbm90IGEgc2luZ2xlIGNvbnNvbGlkYXRlZCBwcm9wb3NhbCBhcyBob3BlZCwgYnV0 IHJhdGhlciB0d28NCj4+IGFsdGVybmF0ZSBkaXJlY3Rpb25zIC0tIGFuZCBjbGVhcmx5IHdlIG5l ZWQgdG8gY2hvb3NlIG9uZToNCj4+DQo+PiAgICAgMSkgQWRvcHQgdGhlIGNvbnZlbnRpb25zIGZv ciByZXByZXNlbnRpbmcgc3RhdGUvY29uZmlnDQo+PiAgICAgICAgYmFzZWQgb24gU2VjdGlvbiA2 IG9mIFsxXS4NCj4+DQo+PiAgICAgICAgRnJvbSBhIG1vZGVsIGRlZmluaXRpb24gcGVyc3BlY3Rp dmUsIHRoZXNlIGNvbnZlbnRpb25zDQo+PiAgICAgICAgaW1wYWN0IGV2ZXJ5IG1vZGVsIGFuZCBl dmVyeSBtb2RlbCB3cml0ZXIuDQo+Pg0KPj4gICAgIDIpIE1vZGVsIE9wU3RhdGUgdXNpbmcgYSBy ZXZpc2VkIGxvZ2ljYWwgZGF0YXN0b3JlIGRlZmluaXRpb24NCj4+ICAgICAgICBhcyBpbnRyb2R1 Y2VkIGluIFs0XSBhbmQgYWxzbyBjb3ZlcmVkIGluIFs1XS4gVGhlcmUgaXMNCj4+ICAgICAgICBh bHNvIGEgdmFyaWFudCBvZiB0aGlzIHRoYXQgd2UgYmVsaWV2ZSBkb2Vzbid0IHNpZ25pZmljYW50 bHkNCj4+ICAgICAgICBpbXBhY3QgdGhpcyBjaG9pY2UuDQo+Pg0KPj4gICAgICAgIFdpdGggdGhp cyBhcHByb2FjaCwgbW9kZWwgZGVmaW5pdGlvbnMgbmVlZCBubyBleHBsaWNpdA0KPj4gICAgICAg IGNoYW5nZXMgdG8gc3VwcG9ydCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24uDQo+Pg0KPj4gPkZyb20g YSB0ZWNobm9sb2d5L1dHIHN0YW5kcG9pbnQsIHdlIGJlbGlldmUgYW4gYXBwcm9hY2gNCj4+IHRo YXQgZG9lc24ndCBpbXBhY3QgZXZlcnkgbW9kZWwgd3JpdHRlbiAoaS5lLiwgIzIpIGlzIHN1cGVy aW9yLg0KPj4gVGhlIGNvdW50ZXJwb2ludCB0byB0aGlzIGlzIHRoYXQgdGhlIGNvbnZlbnRpb25z IGJhc2VkDQo+PiBhcHByb2FjaCAoaS5lLiwgIzEpIGlzIGF2YWlsYWJsZSB0b2RheSBhbmQgYmVp bmcgZm9sbG93ZWQgaW4NCj4+IE9wZW5Db25maWcgZGVmaW5lZCBtb2RlbHMuDQo+Pg0KPj4gV2Ug d291bGQgbGlrZSB0byBoZWFyIG9waW5pb25zIG9uIHRoaXMgZnJvbSB0aGUgV0cgYmVmb3JlDQo+ PiBkZWNsYXJpbmcgb25lIG9mIHRoZSBmb2xsb3dpbmcgYXMgdGhlIFdHIGRpcmVjdGlvbjoNCj4+ DQo+PiAgICAgQSkgbW9kZWxzIHRoYXQgd2lzaCB0byBzdXBwb3J0IGFwcGxpZWQgY29uZmlndXJh dGlvbiBNVVNUDQo+PiAgICAgICAgZm9sbG93IGNvbnZlbnRpb25zIGJhc2VkIG9uIFsxXSAtLSBh bmQgdGhlIFdHIG5lZWRzIHRvDQo+PiAgICAgICAgZm9ybWFsaXplIHRoZXNlIGNvbnZlbnRpb25z Lg0KPj4gb3INCj4+ICAgICBCKSBubyBleHBsaWNpdCBzdXBwb3J0IGlzIHJlcXVpcmVkIGZvciBt b2RlbHMgdG8gc3VwcG9ydA0KPj4gICAgICAgIGFwcGxpZWQgY29uZmlndXJhdGlvbiAtLSBhbmQg dGhhdCB0aGUgV0cgbmVlZHMgdG8NCj4+ICAgICAgICBmb3JtYWxpemUgYW4gb3BzdGF0ZSBzb2x1 dGlvbiBiYXNlZCBvbiB0aGUgYXBwcm9hY2gNCj4+ICAgICAgICBkaXNjdXNzZWQgaW4gWzRdIGFu ZCBbNV0uDQo+Pg0KPj4gV2UgaW50ZW5kIHRvIGNsb3NlIG9uIHRoaXMgY2hvaWNlIGJlZm9yZSBC ZXJsaW4uDQo+Pg0KPj4gVGhhbmsgeW91LA0KPj4gTG91IChhbmQgY28tY2hhaXJzKQ0KPj4NCj4+ IFsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qt b3BzdGF0ZS0wMQ0KPj4gWzJdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rd2F0 c2VuLW5ldG1vZC1vcHN0YXRlLTAyDQo+PiBbM10gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdpbHRvbi1uZXRtb2Qtb3BzdGF0ZS15YW5nLTAyDQo+PiBbNF0NCj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nob2Vudy1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVz LTAwDQo+PiBbNV0NCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2lsdG9uLW5l dG1vZC1yZWZpbmVkLWRhdGFzdG9yZXMtMDANCj4+ICogLSBDaHJpcyBILiBhbmQgQWNlZSBMLg0K Pj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0K Pm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kDQoNCg== From nobody Fri Jun 17 09:54:51 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D39C112D851; Fri, 17 Jun 2016 09:54:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160617165442.9746.5342.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2016 09:54:42 -0700 Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org, The IESG , draft-ietf-netmod-rfc6020bis@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] Protocol Action: 'The YANG 1.1 Data Modeling Language' to Proposed Standard (draft-ietf-netmod-rfc6020bis-14.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 16:54:43 -0000 The IESG has approved the following document: - 'The YANG 1.1 Data Modeling Language' (draft-ietf-netmod-rfc6020bis-14.txt) as Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ Technical Summary YANG is a data modeling language used to model configuration data, state data, remote procedure calls, and notifications for network management protocols like the Network Configuration Protocol (NETCONF). This document defines YANG version 1.1. Working Group Summary This is an update of YANG 1.0 as defined in RFC 6020. The working group used an issue tracker and a number of virtual interim meetings to discuss all bug fix proposals and feature requests. The document went through two WG last calls and there is broad consensus on the final version. Document Quality Recent versions of the open source pyang implementation support this specification. Additional commercial implementations are expected to follow soon. Personnel Juergen Schoenwaelder is the document shepherd and Benoit Claise is the responsible AD. From nobody Fri Jun 17 11:22:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31812D978 for ; Fri, 17 Jun 2016 11:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, 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 qenTGTEhrnbZ for ; Fri, 17 Jun 2016 11:22:33 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id BBF4E12D977 for ; Fri, 17 Jun 2016 11:22:33 -0700 (PDT) Received: (qmail 17712 invoked by uid 0); 17 Jun 2016 18:22:31 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy1.mail.unifiedlayer.com with SMTP; 17 Jun 2016 18:22:31 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 7uNS1t01G2SSUrH01uNVKo; Fri, 17 Jun 2016 12:22:29 -0600 X-Authority-Analysis: v=2.1 cv=ff4+lSgF c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=Dt7N7ZIm6-11c7dqh_MA:9 a=WcK_3SK9ij7Yo_TI:21 a=DIq1urli2pm8C_z2:21 a=pILNOxqGKmIA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=h1QKnUT15VGmj2Tj2K11ETbXhE/suaqCYmytr43SNgY=; b=b6+d8Y5sbrtvdQezy2lFd6hAoS FIsIwgS3k+1cOcG6s0s/PT6IkN127KmGv8VvrP7wMhPA+7y/bAKnegDCVlejBRiUnZw9AKSDT6Rb+ wZcCxVIDQ+jMmFZociwdBq52u; Received: from box313.bluehost.com ([69.89.31.113]:52059 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bDyPU-0005pu-Gm; Fri, 17 Jun 2016 12:22:28 -0600 To: "t.petch" , netmod WG References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> From: Lou Berger Message-ID: Date: Fri, 17 Jun 2016 14:22:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:22:36 -0000 Tom, Thanks for the perspective. I'm a little unsure if you're expecting a response or just making a statement, so if you're looking for something specific and don't see it below -- please let me know. On 6/17/2016 11:15 AM, t.petch wrote: > Lou > > By now, 17th June, I see solid support for one option but only see > comments from a somewhat small number of participants This is true, and I've heard privately that some more may/should be forthcoming. > The majority of the authors of the 172 YANG files I have in an > archive are probably unaware of this discussion and yet some at least > will be affected. What concerns me is that history might be repeating > itself. In a sense, this discussion is about the original proposals for > NETCONF and YANG not meeting current requirements which > may be because there has mostly been a limited number of > participants in netmod discussions. So two points on this: - Today is different in that there are a great number of players using/looking to YANG at the moment --- so I think we have more lurkers out there than you'd expect. - The fact that 172 documents (and that's just in the IETF) would be impacted by option (A) is exactly why we think it's the wrong way to go. Think about if we came up with a solution that requires each modeler to build their definitions a fixed way how this would be socialized/enforced. Now think about doing that in other SDOs. > I was struck by Dale's recent, brilliant review of 6020bis because it > came from a fresh angle and brought up nagging concerns that I had had > but had not been able to articulate. With a wider audience, similar > comments might have been made much earlier to the advantage > of YANG (perhaps even about RFC6020). > > In the same vein, there is NETCONF. Juergen's I-D, which I see finding > favour, could be said to cut the ground from under NETCONF (well, I > would). RFC6241 says > " Configuration data is the set of writable data that is required to > transform a system from its initial default state into its current > state. State data is the additional data on a system that is not > configuration data such as read-only status information and collected > statistics. " > > The proposed 'intended' in the I-D is (ct, ro). It is ct, configuration > true, so it is configuration data. It is ro, read only, so it is > clearly not > configuration data. Without changing RFC6241, I cannot reconcile this. It's just a ro version/view of the config data. I'm not sure why this is problematic. Perhaps I'm just missing something. > So I see RFC6241 being changed; can anyone reading the RFC understand it > any more? And yet the I-D makes no mention of this change to > NETCONF nor have I seen any discussion on the netconf list. > > Stimulated by posts to the I2RS list, perhaps also a trigger for > Juergen's I-D, I wrote up my own summary of the current state of > datastores but I called it draft-tp-netconf-datastore because I see > NETCONF > currently telling us almost all that we know about datastores; YANG 1.0 > adds very little. For me, NETCONF should be the starting point. The first question is deciding on an approach (A vs B), the second question is on the details of the selected option. If we move forward with B, I think which WG does the data store work is a fine topic to consider. But we (netmod) first need to close on A vs B -- which will be easy if there are no new comments in short order. Lou > Tom Petch > > ----- Original Message ----- > From: "Lou Berger" > To: "netmod WG" > Cc: > Sent: Tuesday, June 07, 2016 3:19 PM > >> All, >> >> We want to provide an update based on the off line discussions >> related to OpState Solutions that we have been having and solicit >> input from the WG. >> >> All authors of current solution drafts [1,2,3] together with those >> who helped conduct the solutions analysis* were invited to the these >> discussions -- with the objective of coming up with a single >> consolidated proposal to bring to the WG. (I/Lou acted as facilitator >> as Kent and Juergen were and are involved with the technical details.) >> >> The discussions have yielded some results but, unfortunately, >> not a single consolidated proposal as hoped, but rather two >> alternate directions -- and clearly we need to choose one: >> >> 1) Adopt the conventions for representing state/config >> based on Section 6 of [1]. >> >> From a model definition perspective, these conventions >> impact every model and every model writer. >> >> 2) Model OpState using a revised logical datastore definition >> as introduced in [4] and also covered in [5]. There is >> also a variant of this that we believe doesn't significantly >> impact this choice. >> >> With this approach, model definitions need no explicit >> changes to support applied configuration. >> >> >From a technology/WG standpoint, we believe an approach >> that doesn't impact every model written (i.e., #2) is superior. >> The counterpoint to this is that the conventions based >> approach (i.e., #1) is available today and being followed in >> OpenConfig defined models. >> >> We would like to hear opinions on this from the WG before >> declaring one of the following as the WG direction: >> >> A) models that wish to support applied configuration MUST >> follow conventions based on [1] -- and the WG needs to >> formalize these conventions. >> or >> B) no explicit support is required for models to support >> applied configuration -- and that the WG needs to >> formalize an opstate solution based on the approach >> discussed in [4] and [5]. >> >> We intend to close on this choice before Berlin. >> >> Thank you, >> Lou (and co-chairs) >> >> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 >> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 >> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 >> [4] > https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 >> [5] > https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 >> * - Chris H. and Acee L. >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Jun 17 11:33:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD82812D99E for ; Fri, 17 Jun 2016 11:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 QbyhI0gGqTCh for ; Fri, 17 Jun 2016 11:33:39 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 4BC1712D84D for ; Fri, 17 Jun 2016 11:33:39 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id u64so126821731vkf.3 for ; Fri, 17 Jun 2016 11:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vWZbseW2lDGEgZfpZiearTneT9DGyU5BIwEifrKOap8=; b=Y6qn6ib2hlLlCbyXIvX9NGlk0hA40sVeKesf4BxEOEbbzRHZPOZsPymjHuIXnSwFCo Jpt4PUe87PUXGIjAYIpzj3IimRYFaJ4e+BB5m8SX/vYqzhqlerEUSRHG3s3PglqdBQAX AJLsf6I6q81I4/O6QguIihuAIzpWgg8va4kBDnGL3iqFPQfzJNsv3aLEKOVW8k9GF6Y8 EQ36Xl0C+ln0HlznPuhg3qY2IkZgdvARcf3vPjO33+esmoSkvgbuYWkdzyZ03ao7WePN Mimtze52P16ptyvHaCvQBS1Cl7wgr/M8BRomMiM4aCOAVF+bFBs33H5HA9tb+N0d17AN LYqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vWZbseW2lDGEgZfpZiearTneT9DGyU5BIwEifrKOap8=; b=GVUCG3oeiKEgniwPcCaNu/Pedtq4LOUdaHj/q52hmtYTtLA8CHEmUA3XxDXxkptfdC s/Lp6QyGLpceoFSl1EgdwToe9GsQggRggD8mTPRATlQ1iChUeNJ2GHPLpTPI9H3Nd0jm 5f4v/jIWZ6gol1J/fPIuz5k/5LduZJ3/fs3ahqHcjpLQMWYCaMWV/yshmjYVCkE10Blj NA6ci7Sit1gGj16M3nHoaf1z7kpnjvduLmtMork+7GY7ssMUCWbh/7E3iXjO07K0j4fc CHm5HPZGk60d3KrpLqCvEfxGVjTVjiv9Zb2cSZWL2bADMgTbaLo5qdZvHWGFOU17Q6PU pgOw== X-Gm-Message-State: ALyK8tI+tH/3FkuBjvucgFJMeWUHuygIfBsJYeKpZo/BAiFMofZW4m0HpXPRdhYm967Ocdm02VZYDRnqyc8GqQ== MIME-Version: 1.0 X-Received: by 10.31.108.216 with SMTP id j85mr1747522vki.68.1466188418325; Fri, 17 Jun 2016 11:33:38 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Fri, 17 Jun 2016 11:33:38 -0700 (PDT) In-Reply-To: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> Date: Fri, 17 Jun 2016 11:33:38 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a11478f34d92c4405357d975e Archived-At: Cc: netmod-chairs@ietf.org, netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:33:43 -0000 --001a11478f34d92c4405357d975e Content-Type: text/plain; charset=UTF-8 On Fri, Jun 17, 2016 at 11:22 AM, Lou Berger wrote: > Tom, > > Thanks for the perspective. I'm a little unsure if you're expecting > a response or just making a statement, so if you're looking for > something specific and don't see it below -- please let me know. > > On 6/17/2016 11:15 AM, t.petch wrote: > > Lou > > > > By now, 17th June, I see solid support for one option but only see > > comments from a somewhat small number of participants > This is true, and I've heard privately that some more may/should be > forthcoming. > > > The majority of the authors of the 172 YANG files I have in an > > archive are probably unaware of this discussion and yet some at least > > will be affected. What concerns me is that history might be repeating > > itself. In a sense, this discussion is about the original proposals for > > NETCONF and YANG not meeting current requirements which > > may be because there has mostly been a limited number of > > participants in netmod discussions. > > So two points on this: > - Today is different in that there are a great number of players > using/looking to YANG at the moment --- so I think we have more lurkers > out there than you'd expect. > > - The fact that 172 documents (and that's just in the IETF) would be > impacted by option (A) is exactly why we think it's the wrong way to go. > Think about if we came up with a solution that requires each modeler to > build their definitions a fixed way how this would be > socialized/enforced. Now think about doing that in other SDOs. > > Not to mention all the vendor defined YANG modules. IMO this has always been a protocol issue. The state of the data depends on the interaction model and that depends on the protocol. E.g., how does confirmed-commit factor into the state machine? The config may be applied but also temporary, pending confirmation. What if a YANG protocol mandated that means applied, not just intended? That interaction model would not need separate datastores for intended vs. applied. (One solution approach is to update NETCONF to provide this interaction model.) Andy > I was struck by Dale's recent, brilliant review of 6020bis because it > > came from a fresh angle and brought up nagging concerns that I had had > > but had not been able to articulate. With a wider audience, similar > > comments might have been made much earlier to the advantage > > of YANG (perhaps even about RFC6020). > > > > In the same vein, there is NETCONF. Juergen's I-D, which I see finding > > favour, could be said to cut the ground from under NETCONF (well, I > > would). RFC6241 says > > " Configuration data is the set of writable data that is required to > > transform a system from its initial default state into its current > > state. State data is the additional data on a system that is not > > configuration data such as read-only status information and collected > > statistics. " > > > > The proposed 'intended' in the I-D is (ct, ro). It is ct, configuration > > true, so it is configuration data. It is ro, read only, so it is > > clearly not > > configuration data. Without changing RFC6241, I cannot reconcile this. > It's just a ro version/view of the config data. I'm not sure why this > is problematic. Perhaps I'm just missing something. > > > So I see RFC6241 being changed; can anyone reading the RFC understand it > > any more? And yet the I-D makes no mention of this change to > > NETCONF nor have I seen any discussion on the netconf list. > > > > Stimulated by posts to the I2RS list, perhaps also a trigger for > > Juergen's I-D, I wrote up my own summary of the current state of > > datastores but I called it draft-tp-netconf-datastore because I see > > NETCONF > > currently telling us almost all that we know about datastores; YANG 1.0 > > adds very little. For me, NETCONF should be the starting point. > The first question is deciding on an approach (A vs B), the second > question is on the details of the selected option. If we move forward > with B, I think which WG does the data store work is a fine topic to > consider. But we (netmod) first need to close on A vs B -- which will > be easy if there are no new comments in short order. > > Lou > > Tom Petch > > > > ----- Original Message ----- > > From: "Lou Berger" > > To: "netmod WG" > > Cc: > > Sent: Tuesday, June 07, 2016 3:19 PM > > > >> All, > >> > >> We want to provide an update based on the off line discussions > >> related to OpState Solutions that we have been having and solicit > >> input from the WG. > >> > >> All authors of current solution drafts [1,2,3] together with those > >> who helped conduct the solutions analysis* were invited to the these > >> discussions -- with the objective of coming up with a single > >> consolidated proposal to bring to the WG. (I/Lou acted as facilitator > >> as Kent and Juergen were and are involved with the technical details.) > >> > >> The discussions have yielded some results but, unfortunately, > >> not a single consolidated proposal as hoped, but rather two > >> alternate directions -- and clearly we need to choose one: > >> > >> 1) Adopt the conventions for representing state/config > >> based on Section 6 of [1]. > >> > >> From a model definition perspective, these conventions > >> impact every model and every model writer. > >> > >> 2) Model OpState using a revised logical datastore definition > >> as introduced in [4] and also covered in [5]. There is > >> also a variant of this that we believe doesn't significantly > >> impact this choice. > >> > >> With this approach, model definitions need no explicit > >> changes to support applied configuration. > >> > >> >From a technology/WG standpoint, we believe an approach > >> that doesn't impact every model written (i.e., #2) is superior. > >> The counterpoint to this is that the conventions based > >> approach (i.e., #1) is available today and being followed in > >> OpenConfig defined models. > >> > >> We would like to hear opinions on this from the WG before > >> declaring one of the following as the WG direction: > >> > >> A) models that wish to support applied configuration MUST > >> follow conventions based on [1] -- and the WG needs to > >> formalize these conventions. > >> or > >> B) no explicit support is required for models to support > >> applied configuration -- and that the WG needs to > >> formalize an opstate solution based on the approach > >> discussed in [4] and [5]. > >> > >> We intend to close on this choice before Berlin. > >> > >> Thank you, > >> Lou (and co-chairs) > >> > >> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > >> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > >> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > >> [4] > > https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > >> [5] > > https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > >> * - Chris H. and Acee L. > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11478f34d92c4405357d975e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 17, 2016 at 11:22 AM, Lou Berger <lberger@labn.net><= /span> wrote:
Tom,

=C2=A0 =C2=A0 Thanks for the perspective.=C2=A0 I'm a little unsure if = you're expecting
a response or just making a statement, so if you're looking for
something specific and don't see it below -- please let me know.

On 6/17/2016 11:15 AM, t.petch wrote:
> Lou
>
> By now, 17th June, I see solid support for one option but only see
> comments from a somewhat small number of participants
This is true, and I've heard privately that some more may/should be
forthcoming.

> The majority of the authors of the 172 YANG files I have in an
> archive are probably unaware of this discussion and yet some at least<= br> > will be affected.=C2=A0 What concerns me is that history might be repe= ating
> itself.=C2=A0 In a sense, this discussion is about the original propos= als for
> NETCONF and YANG not meeting current requirements which
> may be because there has mostly been a limited number of
> participants in netmod discussions.

So two points on this:
- Today is different in that there are a great number of players
using/looking to YANG at the moment --- so I think we have more lurkers
out there than you'd expect.

- The fact that 172 documents (and that's just in the IETF) would be impacted by option (A) is exactly why we think it's the wrong way to go= .
Think about if we came up with a solution that requires each modeler to
build their definitions a fixed way how this would be
socialized/enforced.=C2=A0 Now think about doing that in other SDOs.


Not to mention all the vendor defined = YANG modules.

IMO this has always been a protocol = issue.
The state of the data depends on the interaction model and= that depends on the protocol.
E.g., how does confirmed-commit fa= ctor into the state machine?
The config may be applied but also t= emporary, pending confirmation.

What if a YANG pro= tocol mandated that <ok> means applied, not just intended?
= That interaction model would not need separate datastores for intended vs. = applied.
(One solution approach is to update NETCONF to provide t= his interaction model.)


Andy
<= div>

> I was struck by Dale's recent, brilliant review of 6020bis because= it
> came from a fresh angle and brought up nagging concerns that I had had=
> but had not been able to articulate.=C2=A0 With a wider audience, simi= lar
> comments might have been made much earlier to the advantage
> of YANG (perhaps even about RFC6020).
>
> In the same vein, there is NETCONF.=C2=A0 Juergen's I-D, which I s= ee finding
> favour, could be said to cut the ground from under NETCONF (well, I > would).=C2=A0 RFC6241 says
> " Configuration data is the set of writable data that is required= to
>=C2=A0 =C2=A0 transform a system from its initial default state into it= s current
>=C2=A0 =C2=A0 state.=C2=A0 State data is the additional data on a syste= m that is not
>=C2=A0 =C2=A0 configuration data such as read-only status information a= nd collected
>=C2=A0 =C2=A0 statistics.=C2=A0 "
>
> The proposed 'intended' in the I-D is (ct, ro).=C2=A0 It is ct= , configuration
> true, so it is configuration data.=C2=A0 It is ro, read only, so it is=
> clearly not
> configuration data.=C2=A0 Without changing RFC6241, I cannot reconcile= this.
It's just a ro version/view of the config data.=C2=A0 I'm not sure = why this
is problematic.=C2=A0 Perhaps I'm just missing something.

> So I see RFC6241 being changed; can anyone reading the RFC understand = it
> any more?=C2=A0 And yet the I-D makes no mention of this change to
> NETCONF nor have I seen any discussion on the netconf list.
>
> Stimulated by posts to the I2RS list, perhaps also a trigger for
> Juergen's I-D, I wrote up my own summary of the current state of > datastores but I called it draft-tp-netconf-datastore because I see > NETCONF
> currently telling us almost all that we know about datastores; YANG 1.= 0
> adds very little.=C2=A0 For me, NETCONF should be the starting point.<= br> The first question is deciding on an approach (A vs B), the second
question is on the details of the selected option.=C2=A0 If we move forward=
with B, I think which WG does the data store work is a fine topic to
consider.=C2=A0 But we (netmod)=C2=A0 first need to close on A vs B -- whic= h will
be easy if there are no new comments in short order.

Lou
> Tom Petch
>
> ----- Original Message -----
> From: "Lou Berger" <l= berger@labn.net>
> To: "netmod WG" <netmo= d@ietf.org>
> Cc: <netmod-chairs@ietf.o= rg>
> Sent: Tuesday, June 07, 2016 3:19 PM
>
>> All,
>>
>> We want to provide an update based on the off line discussions
>> related to OpState Solutions that we have been having and solicit<= br> >> input from the WG.
>>
>> All authors of current solution drafts [1,2,3] together with those=
>> who helped conduct the solutions analysis* were invited to the the= se
>> discussions -- with the objective of coming up with a single
>> consolidated proposal to bring to the WG. (I/Lou acted as facilita= tor
>> as Kent and Juergen were and are involved with the technical detai= ls.)
>>
>> The discussions have yielded some results but, unfortunately,
>> not a single consolidated proposal as hoped, but rather two
>> alternate directions -- and clearly we need to choose one:
>>
>>=C2=A0 =C2=A0 =C2=A01) Adopt the conventions for representing state= /config
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 based on Section 6 of [1].
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 From a model definition perspective, th= ese conventions
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 impact every model and every model writ= er.
>>
>>=C2=A0 =C2=A0 =C2=A02) Model OpState using a revised logical datast= ore definition
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as introduced in [4] and also covered i= n [5]. There is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 also a variant of this that we believe = doesn't significantly
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 impact this choice.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 With this approach, model definitions n= eed no explicit
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 changes to support applied configuratio= n.
>>
>> >From a technology/WG standpoint, we believe an approach
>> that doesn't impact every model written (i.e., #2) is superior= .
>> The counterpoint to this is that the conventions based
>> approach (i.e., #1) is available today and being followed in
>> OpenConfig defined models.
>>
>> We would like to hear opinions on this from the WG before
>> declaring one of the following as the WG direction:
>>
>>=C2=A0 =C2=A0 =C2=A0A) models that wish to support applied configur= ation MUST
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 follow conventions based on [1] -- and = the WG needs to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 formalize these conventions.
>> or
>>=C2=A0 =C2=A0 =C2=A0B) no explicit support is required for models t= o support
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 applied configuration -- and that the W= G needs to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 formalize an opstate solution based on = the approach
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 discussed in [4] and [5].
>>
>> We intend to close on this choice before Berlin.
>>
>> Thank you,
>> Lou (and co-chairs)
>>
>> [1] https://tools.ietf.org/ht= ml/draft-openconfig-netmod-opstate-01
>> [2] https://tools.ietf.org/html/= draft-kwatsen-netmod-opstate-02
>> [3] https://tools.ietf.org/h= tml/draft-wilton-netmod-opstate-yang-02
>> [4]
> https://tools.ietf.org/ht= ml/draft-schoenw-netmod-revised-datastores-00
>> [5]
> https://tools.ietf.org/htm= l/draft-wilton-netmod-refined-datastores-00
>> * - Chris H. and Acee L.
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>


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

--001a11478f34d92c4405357d975e-- From nobody Fri Jun 17 11:36:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DEC12D84D; Fri, 17 Jun 2016 11:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 yErd8cDUz1kv; Fri, 17 Jun 2016 11:36:03 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878A512D815; Fri, 17 Jun 2016 11:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9878; q=dns/txt; s=iport; t=1466188563; x=1467398163; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8oymEf9JYNYNQ9R/qzO7nUGaGjs2uqWHmBQPa1an3Bo=; b=Z2GE4oeJBVptz+PrMC14fwwrfSJoP5s7ly48+qnv5YzfgIuuSoeQW5Ft 3wvQXAlgHlHZpoHjLMc4/ftsbcNt2G4XY+/nd2fgAdfPndcwuekhBihyu 13BFNyHTW1r3xbRYgrSmsgcS0i4osbLWOp73nJdaGdxftOmOOUtSifMHm E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAwARQmRX/5NdJa1dgnBOVn0GtVqFA?= =?us-ascii?q?YF6FwEKhStKAoEkOBQBAQEBAQEBZSeETAEBAwEBAQFrCxACAQgOMQcnCxQRAgQ?= =?us-ascii?q?OBRuIDQgOwQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYp0gSKIeQWOLIpFAYYEi?= =?us-ascii?q?CSBaY05hk6JJgEeNoNwboh8fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,484,1459814400"; d="scan'208,217";a="286997887" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 18:36:02 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5HIa2JV004654 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2016 18:36:02 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 17 Jun 2016 13:36:01 -0500 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1104.009; Fri, 17 Jun 2016 13:36:01 -0500 From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" To: Lou Berger Thread-Topic: [netmod] Opstate solutions discussions: update and request for WGinput Thread-Index: AQHRyMbMg9jP/RxUKEKiv54jnb2EsZ/t/JyA Date: Fri, 17 Jun 2016 18:36:01 +0000 Message-ID: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.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.82.243.35] Content-Type: multipart/alternative; boundary="_000_D389AD131CDBFkkoushikciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:36:05 -0000 --_000_D389AD131CDBFkkoushikciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All I'd like to support Option B below. >> B) no explicit support is required for models to support >> applied configuration -- and that the WG needs to >> formalize an opstate solution based on the approach >> discussed in [4] and [5]. Thanks Kiran >> All, >> >> We want to provide an update based on the off line discussions >> related to OpState Solutions that we have been having and solicit >> input from the WG. >> >> All authors of current solution drafts [1,2,3] together with those >> who helped conduct the solutions analysis* were invited to the these >> discussions -- with the objective of coming up with a single >> consolidated proposal to bring to the WG. (I/Lou acted as facilitator >> as Kent and Juergen were and are involved with the technical details.) >> >> The discussions have yielded some results but, unfortunately, >> not a single consolidated proposal as hoped, but rather two >> alternate directions -- and clearly we need to choose one: >> >> 1) Adopt the conventions for representing state/config >> based on Section 6 of [1]. >> >> From a model definition perspective, these conventions >> impact every model and every model writer. >> >> 2) Model OpState using a revised logical datastore definition >> as introduced in [4] and also covered in [5]. There is >> also a variant of this that we believe doesn't significantly >> impact this choice. >> >> With this approach, model definitions need no explicit >> changes to support applied configuration. >> >> >From a technology/WG standpoint, we believe an approach >> that doesn't impact every model written (i.e., #2) is superior. >> The counterpoint to this is that the conventions based >> approach (i.e., #1) is available today and being followed in >> OpenConfig defined models. >> >> We would like to hear opinions on this from the WG before >> declaring one of the following as the WG direction: >> >> A) models that wish to support applied configuration MUST >> follow conventions based on [1] -- and the WG needs to >> formalize these conventions. >> or >> B) no explicit support is required for models to support >> applied configuration -- and that the WG needs to >> formalize an opstate solution based on the approach >> discussed in [4] and [5]. >> >> We intend to close on this choice before Berlin. >> >> Thank you, >> Lou (and co-chairs) >> >> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 >> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 >> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 >> [4] > https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 >> [5] > https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 >> * - Chris H. and Acee L. >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D389AD131CDBFkkoushikciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi All
I’d like to support Option B below.
>>     B) no explicit support is required for mod= els to support
>>        applied configuration -- and that the W= G needs to
>>        formalize an opstate solution based on = the approach
>>        discussed in [4] and [5].

Thanks
Kiran


>> All,
>>
>> We want to provide an update based on the off line discussions
>> related to OpState Solutions that we have been having and solicit<= br> >> input from the WG.
>>
>> All authors of current solution drafts [1,2,3] together with those=
>> who helped conduct the solutions analysis* were invited to the the= se
>> discussions -- with the objective of coming up with a single
>> consolidated proposal to bring to the WG. (I/Lou acted as facilita= tor
>> as Kent and Juergen were and are involved with the technical detai= ls.)
>>
>> The discussions have yielded some results but, unfortunately,
>> not a single consolidated proposal as hoped, but rather two
>> alternate directions -- and clearly we need to choose one:
>>
>>     1) Adopt the conventions for representing state= /config
>>        based on Section 6 of [1].
>>
>>        From a model definition perspective, th= ese conventions
>>        impact every model and every model writ= er.
>>
>>     2) Model OpState using a revised logical datast= ore definition
>>        as introduced in [4] and also covered i= n [5]. There is
>>        also a variant of this that we believe = doesn't significantly
>>        impact this choice.
>>
>>        With this approach, model definitions n= eed no explicit
>>        changes to support applied configuratio= n.
>>
>> >From a technology/WG standpoint, we believe an approach
>> that doesn't impact every model written (i.e., #2) is superior. >> The counterpoint to this is that the conventions based
>> approach (i.e., #1) is available today and being followed in
>> OpenConfig defined models.
>>
>> We would like to hear opinions on this from the WG before
>> declaring one of the following as the WG direction:
>>
>>     A) models that wish to support applied configur= ation MUST
>>        follow conventions based on [1] -- and = the WG needs to
>>        formalize these conventions.
>> or
>>     B) no explicit support is required for models t= o support
>>        applied configuration -- and that the W= G needs to
>>        formalize an opstate solution based on = the approach
>>        discussed in [4] and [5].
>>
>> We intend to close on this choice before Berlin.
>>
>> Thank you,
>> Lou (and co-chairs)
>>
>> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
>> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
>> [4]
> https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00<= br> >> [5]
> https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 >> * - Chris H. and Acee L.
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>


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

 --_000_D389AD131CDBFkkoushikciscocom_-- From nobody Fri Jun 17 12:19:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B4612DA32; Fri, 17 Jun 2016 12:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 67fXSRc5wTAR; Fri, 17 Jun 2016 12:19:13 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9363812DA31; Fri, 17 Jun 2016 12:19:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5C8EF946; Fri, 17 Jun 2016 21:19:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MXo8e8zgVBxp; Fri, 17 Jun 2016 21:19:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Jun 2016 21:19:11 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD60920054; Fri, 17 Jun 2016 21:19:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mbPf2Bu3AeOG; Fri, 17 Jun 2016 21:19:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4754320047; Fri, 17 Jun 2016 21:19:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 95D263B2951D; Fri, 17 Jun 2016 21:19:09 +0200 (CEST) Date: Fri, 17 Jun 2016 21:19:09 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20160617191909.GA35760@elstar.local> Mail-Followup-To: Andy Bierman , Lou Berger , "t.petch" , netmod WG , netmod-chairs@ietf.org References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> 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: netmod-chairs@ietf.org, netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 19:19:16 -0000 On Fri, Jun 17, 2016 at 11:33:38AM -0700, Andy Bierman wrote: > > IMO this has always been a protocol issue. > The state of the data depends on the interaction model and that depends on > the protocol. > E.g., how does confirmed-commit factor into the state machine? > The config may be applied but also temporary, pending confirmation. > > What if a YANG protocol mandated that means applied, not just intended? > That interaction model would not need separate datastores for intended vs. > applied. > (One solution approach is to update NETCONF to provide this interaction > model.) > You can have configuration for an interface in that does not get applied because the interface is currently not present. I do not think that this is a protocol semantics issue. /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 Jun 17 16:47:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4BF12D60E for ; Fri, 17 Jun 2016 16:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 XLDthESZHVaM for ; Fri, 17 Jun 2016 16:47:25 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 8A4AF12D581 for ; Fri, 17 Jun 2016 16:47:25 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id d185so135133598vkg.0 for ; Fri, 17 Jun 2016 16:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc; bh=DSld4tHDz4QtwEideVILok4PgwY93y+zfVg4llP19Ms=; b=0BX3xcUJ1fg6TxCWdrYwDFE5vuimQJvfZvev+9Hl1XqxmU0hMKz986nyj9hWf00hPF XDkH2MedGZkUA94VnbGFBIhS1yl3r5qyNYxNWmRP5vh1FpsCEFX6tntXqJ+XNA76eLnj /etaryZdW07Evp/VMCPCvN+FXCE5e/W3gMlc6ymhnJTubYZbCsRIxLqUV6aznr7jWgQt 4V2ggk2APb+2tWA+ECSxn+Vd4V1t7dxeBnYrZftdPoyUvc+QTg8sMiwNZGie09YUwjoJ 6FDZ8ntOkg/D8lcHr9JY3hhFnkzIM0oe9FRRIgiYYz9lQljouIC6FVqnobgQI/qFQxS5 6LXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc; bh=DSld4tHDz4QtwEideVILok4PgwY93y+zfVg4llP19Ms=; b=IHRAp9JF6ioD4ddaiAiAbykue3XiHZMppXuVMJ/Iy78hxawkAr40I/jZyTtg+eI+8K 4SnHrtrMd1pmfWV4WFpkZ9M6C95WloKdDGzVQj/n2EoDwN3Xj1JzSauQWPX6YWYQcocN uRlAEJzIGwABpRo6JeeodYeYC3otKwp39MtrF0yGx0aFNdzKrmoSnR1Zb6jRZGwaibWO DYZBaj9EIDVMKnqNOAZLT83BT+OqXTK+pAbIbm0cKjULlTX2/kgVSDu15ZWbtACmSNAI 3einm5/EoQQ8B1xl+532G03StS2tr6qG29Op5LYwOrl5IfGNktdB3Si//m5ZACPoFwbr wRQw== X-Gm-Message-State: ALyK8tKpsRA1lbNkTT6/VAT+1Y55j4icBgnmCf9Qb/CCrev0u7PkgRWs+Zd+k8+iuj85l+BqtgzFDAaS1vOWbg== MIME-Version: 1.0 X-Received: by 10.159.41.196 with SMTP id s62mr2074466uas.47.1466207244552; Fri, 17 Jun 2016 16:47:24 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Fri, 17 Jun 2016 16:47:24 -0700 (PDT) In-Reply-To: <20160617165442.9746.5342.idtracker@ietfa.amsl.com> References: <20160617165442.9746.5342.idtracker@ietfa.amsl.com> Date: Fri, 17 Jun 2016 16:47:24 -0700 Message-ID: From: Andy Bierman Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114b4642faa463053581f923 Archived-At: Subject: Re: [netmod] Protocol Action: 'The YANG 1.1 Data Modeling Language' to Proposed Standard (draft-ietf-netmod-rfc6020bis-14.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 23:47:27 -0000 --001a114b4642faa463053581f923 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 17, 2016 at 9:54 AM, The IESG wrote: > The IESG has approved the following document: > - 'The YANG 1.1 Data Modeling Language' > (draft-ietf-netmod-rfc6020bis-14.txt) as Proposed Standard > > This document is the product of the NETCONF Data Modeling Language > Working Group. > > The IESG contact persons are Benoit Claise and Joel Jaeggli. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ > > > great news! So are we ready for a YANG 1.1 Interoperability Test yet? Our client/server support is almost done -- I suspect some more implementations are in the same state. Maybe a bakeoff at IETF #97 in November? Andy > > > Technical Summary > > YANG is a data modeling language used to model configuration data, > state data, remote procedure calls, and notifications for network > management protocols like the Network Configuration Protocol > (NETCONF). This document defines YANG version 1.1. > > Working Group Summary > > This is an update of YANG 1.0 as defined in RFC 6020. The working > group used an issue tracker and a number of virtual interim meetings > to discuss all bug fix proposals and feature requests. The document > went through two WG last calls and there is broad consensus on the > final version. > > Document Quality > > Recent versions of the open source pyang implementation support this > specification. Additional commercial implementations are expected to > follow soon. > > Personnel > > Juergen Schoenwaelder is the document shepherd and Benoit Claise is > the responsible AD. > > > --001a114b4642faa463053581f923 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 17, 2016 at 9:54 AM, The IESG <iesg-secretary@ietf.o= rg> wrote:
The IESG has app= roved the following document:
- 'The YANG 1.1 Data Modeling Language'
=C2=A0 (draft-ietf-netmod-rfc6020bis-14.txt) as Proposed Standard

This document is the product of the NETCONF Data Modeling Language
Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft= -ietf-netmod-rfc6020bis/




great news!
<= br>
So are we ready for a YANG 1.1 Interoperability Test yet?
Our client/server support is almost done -- I suspect some more impl= ementations
are in the same state. Maybe a bakeoff at IETF #97 in= November?


Andy




Technical Summary

=C2=A0 YANG is a data modeling language used to model configuration data, =C2=A0 state data, remote procedure calls, and notifications for network =C2=A0 management protocols like the Network Configuration Protocol
=C2=A0 (NETCONF). This document defines YANG version 1.1.

Working Group Summary

=C2=A0 This is an update of YANG 1.0 as defined in RFC 6020. The working =C2=A0 group used an issue tracker and a number of virtual interim meetings=
=C2=A0 to discuss all bug fix proposals and feature requests. The document<= br> =C2=A0 went through two WG last calls and there is broad consensus on the =C2=A0 final version.

Document Quality

=C2=A0 Recent versions of the open source pyang implementation support this=
=C2=A0 specification. Additional commercial implementations are expected to=
=C2=A0 follow soon.

Personnel

=C2=A0 =C2=A0Juergen Schoenwaelder is the document shepherd and Benoit Clai= se is
=C2=A0 =C2=A0the responsible AD.



--001a114b4642faa463053581f923-- From nobody Sat Jun 18 06:37:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6093812D1C7 for ; Sat, 18 Jun 2016 06:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 XeTYkyEC1Hlp for ; Sat, 18 Jun 2016 06:37:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D2E5912D1C1 for ; Sat, 18 Jun 2016 06:37:06 -0700 (PDT) Received: from localhost (h-46-190.a165.priv.bahnhof.se [46.59.46.190]) by mail.tail-f.com (Postfix) with ESMTPSA id C04FD1AE0481; Sat, 18 Jun 2016 15:37:04 +0200 (CEST) Date: Sat, 18 Jun 2016 15:37:04 +0200 (CEST) Message-Id: <20160618.153704.551194433238049271.mbj@tail-f.com> To: wlupton@broadband-forum.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] bits lexical representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 13:37:09 -0000 V2lsbGlhbSBMdXB0b24gPHdsdXB0b25AYnJvYWRiYW5kLWZvcnVtLm9yZz4gd3JvdGU6DQo+IFJG QyA2MDIwYmlzIFNlY3Rpb24gOS43LjIgaXMgc2lsZW50IG9uIHRoZSBxdWVzdGlvbiBvZiB3aGV0 aGVyIGJpdA0KPiBuYW1lcyBjYW4gYmUgcmVwZWF0ZWQgaW4gYSBiaXRzIHZhbHVlLCBlLmcgaXMg 4oCcdW5vIGRvcyBkb3MgdHJlc+KAnSB2YWxpZA0KPiBvciBpbnZhbGlkPw0KDQo5LjcuNCBzYXlz Og0KDQogIEFsbCBhc3NpZ25lZCBuYW1lcyBpbiBhIGJpdHMgdHlwZSBNVVNUIGJlIHVuaXF1ZS4N Cg0KDQovbWFydGluDQoNCg0KPiBPYnZpb3VzbHkgcmVwZXRpdGlvbiBpcyBub3QgdG8gYmUgZW5j b3VyYWdlZCBidXQgaXMgaXQNCj4gZm9yYmlkZGVuPyBNYXliZSB0aGlzIGlzIGEgY2FzZSB3aGVy ZSB0aGUgcm9idXN0bmVzcyBwcmluY2lwbGUgc2hvdWxkDQo+IGJlIGFwcGxpZWQ/IFRoYW5rcywg V2lsbGlhbS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Sat Jun 18 09:21:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC2B12D69E for ; Sat, 18 Jun 2016 09:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 WQ5UZ_T03eAg for ; Sat, 18 Jun 2016 09:21:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EFD12D699 for ; Sat, 18 Jun 2016 09:21:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0FA8D76A; Sat, 18 Jun 2016 18:21:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XgiSG7jzMEyn; Sat, 18 Jun 2016 18:21:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 18 Jun 2016 18:21:52 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1006F20054; Sat, 18 Jun 2016 18:21:52 +0200 (CEST) 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 ij2vBlweon-b; Sat, 18 Jun 2016 18:21:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE80720047; Sat, 18 Jun 2016 18:21:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8F15F3B2A686; Sat, 18 Jun 2016 18:21:50 +0200 (CEST) Date: Sat, 18 Jun 2016 18:21:50 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160618162150.GA37197@elstar.local> Mail-Followup-To: Martin Bjorklund , wlupton@broadband-forum.org, netmod@ietf.org References: <20160618.153704.551194433238049271.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <20160618.153704.551194433238049271.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] bits lexical representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 16:21:58 -0000 On Sat, Jun 18, 2016 at 03:37:04PM +0200, Martin Bjorklund wrote: > William Lupton wrote: > > RFC 6020bis Section 9.7.2 is silent on the question of whether bit > > names can be repeated in a bits value, e.g is “uno dos dos tres” valid > > or invalid? > > 9.7.4 says: > > All assigned names in a bits type MUST be unique. > I think this sentence says that leaf a { type bits { bit a; bit a; } } is illegal while I think the question was about the value encoding, that is, given the definition leaf b { type bits { bit a; bit b; } } is a b b illegal. I do not think this is specified but of course a decent implementation would not generate something like this and an implementation following the robustness principle would simply ignore bits that are encoded multiple times. /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 Sat Jun 18 09:54:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAC512D69B for ; Sat, 18 Jun 2016 09:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzBOzChCATbk for ; Sat, 18 Jun 2016 09:54:19 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 65A5D12D665 for ; Sat, 18 Jun 2016 09:54:19 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id d185so151611623vkg.0 for ; Sat, 18 Jun 2016 09:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=EbUG/IjGXJMlT8yUxa0+OevGtQUWCMIsnJHEjEaoxjk=; b=tpcLhwNu9G3i2WpwuK0WzdfwiSOj319dwIjBOq3Hm/iJB1sDzLJt7pjtVSl96k9Jvz LgOqB6Csane2KxAI9hfh7DnVRkvCwTI3aSUsA5uzNhSod3EdfLRm9d9y/IIPntrKhX0k sc/f0ta/83nnYg/jqVz7yQprSZM8U2ej6/HbqxGBdG0AecAPGGRcUs28YVRmLe9JIEpV VaTXI24wyXbWD6xWSKU/ZHmFLwDw3GoL3q6K24wrnRnJEUXCPLl4HhoyGIvfJmZdnfXv r/WpuZzuOuqx3KjmIIK5ymYBHG/c8FQL+TOD1L4D0ZfFR2PQ5JSu6ttwUteF6UkHhsj6 2EQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=EbUG/IjGXJMlT8yUxa0+OevGtQUWCMIsnJHEjEaoxjk=; b=B4d5btYq4o/NRBh4bJxSGxX3IlvnEa6n2IxprsrTA253ZZvyF6JJbRg5E73MqUmfuB xpN9LdFSPd6yiZeTpnbkMg4IoscAa07A0pXqpZ60HaUP33wuQMIGGjs7mJy3TAvlE03X HaBLJFWJAyevhQNUVcB86oZAydog9ZRFxtkIIstfU+KfW/g9s9EaLkJ4PcnRF1okG0sE 2mUYD5IvhXPqo8cSqrMnU4qiSRMRXiphhBA9yYb9YEbAsVjai+LZogri7jVwiNz4Wwt3 QHLhRZcgoRGx6M0J6+1Nphte3k1t3U//9lIiPNZBdtrPzVXMAqFXjewdGl7rp6+16nc+ kR8Q== X-Gm-Message-State: ALyK8tKD4WHj9hgrGKCtfbO3bW4nVcC4ioMi/41bQnC8IMUNrp9tK2gO/i60goQzKwNPdcKC46qBQYhPi4jOEA== MIME-Version: 1.0 X-Received: by 10.31.132.77 with SMTP id g74mr3637755vkd.121.1466268858326; Sat, 18 Jun 2016 09:54:18 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Sat, 18 Jun 2016 09:54:18 -0700 (PDT) In-Reply-To: <20160618162150.GA37197@elstar.local> References: <20160618.153704.551194433238049271.mbj@tail-f.com> <20160618162150.GA37197@elstar.local> Date: Sat, 18 Jun 2016 09:54:18 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , William Lupton , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1144f9d87232fa053590521e Archived-At: Subject: Re: [netmod] bits lexical representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 16:54:21 -0000 --001a1144f9d87232fa053590521e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 18, 2016 at 9:21 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sat, Jun 18, 2016 at 03:37:04PM +0200, Martin Bjorklund wrote: > > William Lupton wrote: > > > RFC 6020bis Section 9.7.2 is silent on the question of whether bit > > > names can be repeated in a bits value, e.g is =E2=80=9Cuno dos dos tr= es=E2=80=9D valid > > > or invalid? > > > > 9.7.4 says: > > > > All assigned names in a bits type MUST be unique. > > > > I think this sentence says that > > leaf a { > type bits { > bit a; > bit a; > } > } > > is illegal while I think the question was about the value encoding, > that is, given the definition > > leaf b { > type bits { > bit a; > bit b; > } > } > > is a b b illegal. I do not think this is specified but of > course a decent implementation would not generate something like this > and an implementation following the robustness principle would simply > ignore bits that are encoded multiple times. > > I don't think this is "of course". It should be clear 1 way or the other. We do not have warnings in the protocols that are usable, so silently ignoring extra bits may not help the client developer find out why there is a duplicate bit. Probably a programming error and a different bit was meant to be set. (So returning an error may be "of course"). > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1144f9d87232fa053590521e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 18, 2016 at 9:21 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Jun 18, 2016 at 03:37:04PM +0200, Martin Bjo= rklund wrote:
> William Lupton <wlup= ton@broadband-forum.org> wrote:
> > RFC 6020bis Section 9.7.2 is silent on the question of whether bi= t
> > names can be repeated in a bits value, e.g is =E2=80=9Cuno dos do= s tres=E2=80=9D valid
> > or invalid?
>
> 9.7.4 says:
>
>=C2=A0 =C2=A0All assigned names in a bits type MUST be unique.
>

I think this sentence says that

leaf a {
=C2=A0 type bits {
=C2=A0 =C2=A0 bit a;
=C2=A0 =C2=A0 bit a;
=C2=A0 }
}

is illegal while I think the question was about the value encoding,
that is, given the definition

leaf b {
=C2=A0 type bits {
=C2=A0 =C2=A0 bit a;
=C2=A0 =C2=A0 bit b;
=C2=A0 }
}

is <b>a b b</b> illegal. I do not think this is specified but o= f
course a decent implementation would not generate something like this
and an implementation following the robustness principle would simply
ignore bits that are encoded multiple times.


I don't think this is "of course".=C2= =A0 It should be clear 1 way or the other.
We do not have warning= s in the protocols that are usable, so silently ignoring
extra bi= ts may not help the client developer find out why there is a duplicate bit.=
Probably a programming error and a different bit was meant to be= set.
(So returning an error may be "of course").
=

=C2=A0
/js


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

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

--001a1144f9d87232fa053590521e-- From nobody Sun Jun 19 02:53:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEC912B00E; Sun, 19 Jun 2016 02:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA4kio-lUHfD; Sun, 19 Jun 2016 02:53:56 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0093.outbound.protection.outlook.com [104.47.0.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6404112B006; Sun, 19 Jun 2016 02:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mvxq8MIqbxnX/YzOQSPbf7aGVFZ3sUxBqOXU06qdr78=; b=hK/Dk2jbuVbzQqoeUo1iYmnt0Gi5Gsk0PnqiuHTvVwaXzVyySSozKy1polIwdoRE8yZ8COpgppIxNvuQKUOh4nZDrNdo/h3ZltfRuRc/JDmoXU2c2xs9hRLEypt2D0Pu+rKD3bcaW/PLd9aGs+LsUwaAIPlWL13oS8JtYIv1HRU= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.165.8) by VI1PR07MB1631.eurprd07.prod.outlook.com (10.166.142.149) with Microsoft SMTP Server (TLS) id 15.1.523.12; Sun, 19 Jun 2016 09:53:52 +0000 Message-ID: <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> From: t.petch To: netmod WG , Lou Berger References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> Date: Sun, 19 Jun 2016 10:52:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.165.8] X-ClientProxiedBy: DB3PR05CA0015.eurprd05.prod.outlook.com (10.160.41.143) To VI1PR07MB1631.eurprd07.prod.outlook.com (10.166.142.149) X-MS-Office365-Filtering-Correlation-Id: c8d4cf3a-601d-43c9-51a7-08d398279ecf X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 2:m0xRtu8Fsg6zi1cqqeFOQ/hOSQF5ybBOQfZpleL9VCfgOk5k8pOxW9tSffkwZRMBjisCIPTXeTCqWRZRGdFOGxI3kXnPuAQ7ZWTpUQW1wMgiLBaGRDaahE0ReaZbYUiBFYQK7LPrul8mlApaBqSeQGaSDnZNqtfcieqXvWIvlDg8y7IcNPZLoQrYEtaspxAI; 3:69bdj7SgFjY2ZEIHsKC0GVpbwm2cjitlH7aA8WNaqXcXT7oAyC+nhUkIc08Ahbmpp6Fh1Z9+WHHgeTGD6GzcPKfTJsYbPx1tNpOkxBOH2wcZurgdk9e/bXJIEifHOwZs; 25:NNnzF5dGXwJxvEOq8E6rX/qHLar18muO2s2qhst0cMcljZSly8c0jyrT9+y/C184j0w7Ut3sZxOKP6qrN3ZOBU/SuW+ZgqAlq/ywzY0G6NFrskNxGtX5/uup0aS9o9umFYn+Vs51stweXTNkGsmwTd0alkk0aKS/MC9wuKklPOgb7mIS5/KqiLd+3iH851W5FvLFkMvRqaswdFbLBwOl1KbpbwSkz1vnx6iilVm1NhsTDv5/JxUtLCFue2ByZDTZl8+07KZrTWsU/KCZp9Ye/e2gyuR1wvQPnAiM0o64VVkX0it7Qg9SdpffP21TaqSb4vmZ0WJifBHWsFvvoDfARXvBeq1F1L+3bDSqUeqZGLI8nmDRBgVlbFxARF4cvA5m5DNqMnOf0MRzkkocOD8++b4BIuGROwZuaydOQqtTOjc= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1631; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR07MB1631; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1631; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 4:7gmEGm1A+kxSZHfdBcV/hNcwnm3ipkQ4ygbWVte5A7Khw2yZd6urT9cyA4eVEmtqtql4fC0LV+3Mu6M46iaXCphEmZe6o3aaUyFQPcmMpv9TtaucBOgvCaOqVsjYIhUXsSTtQpLQrylS2A2WwD6/zTPxz02rxqwPNz/8Rp+X/3qRaSsGOV1MjQStcdGm+H5n8kcCYFWKO/OIHrWD/gl/hTFJzjAdxQVPEJ1SUTcp2NLfuyXwZQZ6G7nJr2NECDnYxDHHZnUgDEWHegp5Gp0jvGLWFdkwmF+yxoK2SlGe6pNssig+NpLZLpO3aj5yb+vyv+16N+rHD6QKBiUmuAc2GeujiZu6oZiIw7UuUFuyNyV6Nh7ecHdMLsum3VHIhkFEexXcMY6z91ilO7R5iAhMHA97rpe9JUjHuraPQ/N8l1URISOrQXxEJ5W3+pxFQge8 X-Forefront-PRVS: 09781D4C35 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(51914003)(24454002)(189002)(13464003)(199003)(377454003)(33646002)(1456003)(77096005)(66066001)(23746002)(86362001)(50226002)(230700001)(97736004)(92566002)(9686002)(5001770100001)(44736004)(106356001)(105586002)(1556002)(189998001)(2906002)(586003)(6116002)(4326007)(84392002)(3846002)(19580395003)(116806002)(44716002)(62236002)(50986999)(15650500001)(76176999)(101416001)(81686999)(81816999)(42186005)(81166006)(81156014)(50466002)(68736007)(47776003)(8676002)(14496001)(7846002)(19580405001)(61296003)(5004730100002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1631; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR07MB1631; 23:78LIzWxnv555rM4A/q9Gi4lUg23B2zjDQExKM?= =?Windows-1252?Q?7/V0XwROkRWDE5z2gFi42hhMlARvhoMBRRCIKmIyc6WsCGvRES872nB2?= =?Windows-1252?Q?cVXRW1hKsnbGEueuAfxfo3NPTok+7t2UWBv1Rvs7t8LU2pghhSh1+xBT?= =?Windows-1252?Q?1zdpZe8JTGkT7KOVEmKZyubYSmtsfE0wJInufEbgs60/yPZgMD38X5tG?= =?Windows-1252?Q?PUpBuvlOwuIBdlvFjSflBtcYiF8hI9zLheMVvCff52np9HlnwoJArNeA?= =?Windows-1252?Q?e2HHQKbM01jXdskqiQI67Jn7DfcQogk7GmrVFgpdcoz76g7ve4tjhDbr?= =?Windows-1252?Q?XhJiSFfyRPfZioLt2C0kcjwXn3dwzuSzPIou7C9fSFc+2AqxZ2ulih8H?= =?Windows-1252?Q?bJPBDO+sjPb/J/eI1JRL8eA068LFKMhXe+5OjntwLtSNpQy6k03sYd/3?= =?Windows-1252?Q?tX0r1tRpbxmPct6va2FSbmdD6QV5HIJvIhp0BzeI1PwJ13AZ6kOFLTzF?= =?Windows-1252?Q?vqy6xQWav5ohDr8Is5cMQ+T/wXTcFQWk0KH3iTTLF/lLtgILe9VLhro/?= =?Windows-1252?Q?EE9fobEEvSOq+Xg7VqFGOf2GB7LpFSi80Xf2TlbcmiyCvpqJUrBRhhqJ?= =?Windows-1252?Q?ROCv8Nl9TXfgBJql8IqsoR3lto/W0lxcMIDffSl7WsjdsFdJYLjYxhrf?= =?Windows-1252?Q?nyzV5Ke2j/EcRSszwa38vYA3Ux1SbhyhNKhJo53Aa/ylLXSTVWZB4UL0?= =?Windows-1252?Q?0grCDu/8o/g4s8JF1lkTD9G0KO6OOH4bOOxXhqyIP7cAERf1hTln1dxV?= =?Windows-1252?Q?PtMVyzhysDGmfxRhZ+UNGsCXVBlZmF2K+iPYUCCgRLmFRNCAzjXyPJZs?= =?Windows-1252?Q?iwaKLIkmy2MYCZ1HLjoAZTJ1pcLH0yjx2x4/dqiZJuUwbdzpIz7E8oUB?= =?Windows-1252?Q?T5OtMARhnYRLLCdVxGIjM6rUVe3DsC3g1TKXhGJk8xIv8+Wk0o/9/i4t?= =?Windows-1252?Q?PMGNKaDEQqeij01FB+VSO+3sdegrelmvHnFB8VxN/n/vWsh6/ArKGpo6?= =?Windows-1252?Q?x7KZcZbhM1vC0MaRNwUVoM/HxyqPwWyEqSiXfOgWIta0hdB2ZMYWvZ+s?= =?Windows-1252?Q?WesOFMUwNkIYeQ4RaqbULzaExnWOptFqtUeCHkV1UtO+1Nj1SJ/GAcgB?= =?Windows-1252?Q?tKBst3hKAtCe+weMjREWH10XlzusvF/7cS6HX7xQNKB0lbQJ/X4+HpaT?= =?Windows-1252?Q?dKDwnFOaBVab8cyMTffVu12T/DMvFsjP9UGJXHa6qEl0vz9zSLjEoXFo?= =?Windows-1252?Q?VJ8TmogQ6lMpaPQvK5vgodK3KYIOELPTfTy91SwoA3m0z5SMiiSLbHzP?= =?Windows-1252?Q?AI2ryMZqqg7T7RE1EG7wFj2p6o8QFotT/Ij25Im3SpAg69X1/4s+Qf14?= =?Windows-1252?Q?liSy+dr/j8xwShG8rCLhj1wQKTStDyqmU83hEkZo1FNXPGr1KRutbQfG?= =?Windows-1252?Q?TznBJ0YuiD+r71J9sd8GBSEpQJy?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 6:TY3qDY78dR65jn+B476TJ7NPEtBBEYXHN3V5TZRaMu/3idhe5OrwRETpt362QKej3CnrfT9HL/RGgdVNT5VD59p7I6exD55/O8mzdWP3uuDaPm21DcVfWNmBsQMRyifr2LyZ93Gs4BArw3/MqEP2DREa61H4aBXrvVI0POzhX0KsN4rFhk22r4hv/hRoGGkOOQ7pw1sLCcpph/xuZcrfhGGlJp4osNZc+dGPVlRq2zHcLLXweChTOWuzRRsDMHThd2wgATu6P2tigt5Zug+Qkxa7P5eoxyHj/MF05Dz1Yi8=; 5:PFdDubSoWhVAO0wHPjv6FCNO+1wEA9MlkKO745L5rmVHgXpG29wWI0K+eIyg0iipz8c8NfH7njmGzUWkyQ4qdU7/Nx4weGu9Vals2mwBrm/vJ0eeuliJckvFEjISCmRTNnbbnE9rJb7t87oEzP+qWA==; 24:qnvQfmXtN+CXShmOvn10FIa1aCV1d5XL/Pvz7KQP+WBaKcGZZ8E4gitjZjnSRCF3jNBI/Q17W2xM1UnPJBMDwgFtMgqtv/A0/+VMdwHEvF0=; 7:rsjw/ni7ocRb5qFf+GYRp5UlWInbz8YrWAZCXEk5kEvKsKSdAV/iE+SV3UmfBYJONvqdBVGDCedfcOxk/41ZAYhQs66JXgATypNZTstqRKLcZ6d6yR+BLG2aJn+LZpZxOVS8VBnRP1kzGncQmO2Rs3tcE94Jjzuq9p1a7zCdj3c2n6qKHP9d92DvX2UCyGObjW/13Cl6BBxWGdlIFKsZ/XEiJvpOARDclupYoCzrE9eDGq2y9XpV0npYjnXpVy9S SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2016 09:53:52.1012 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1631 Archived-At: Cc: netmod-chairs@ietf.org Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 09:53:58 -0000 Lou You say below " > It's just a ro version/view of the config data. I'm not sure why this > is problematic. Perhaps I'm just missing something. " I see it as a fundamental change (to NETCONF). Tracking other lists (e.g.I2RS) I repeatedly get the sense that they have not grasped what configuration data is (editable, potential persistent but a minute fraction of what a box needs to operate), and by contrast what is state. I see some, if not many, of Juergen's posts to that list as reflecting that such as "I have no clue what the above sentence is trying to say. Please try to use YANG terminology. " Every time I read 'ephemeral state' I think the same; state is ephemeral, the phrase does not convey any meaning (except that the user does not understand what configuration is). And this comes mostly from RFC6241 not from RFC6020. So, I see a strong preference for Option B which is all very logical, as Acee points out. But Option B I see as being a fundamental change to RFC6241, so if the netmod WG takes that decision, then it is stamping on the netconf WG. Perhaps the WG should be merged, now that 6020bis is on its way, but for the moment, I believe that changes to NETCONF need the consensus of the NETCONF WG. Tom Petch ----- Original Message ----- From: "Lou Berger" To: "t.petch" ; "netmod WG" Cc: Sent: Friday, June 17, 2016 7:22 PM Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput > Tom, > > Thanks for the perspective. I'm a little unsure if you're expecting > a response or just making a statement, so if you're looking for > something specific and don't see it below -- please let me know. > > On 6/17/2016 11:15 AM, t.petch wrote: > > Lou > > > > By now, 17th June, I see solid support for one option but only see > > comments from a somewhat small number of participants > This is true, and I've heard privately that some more may/should be > forthcoming. > > > The majority of the authors of the 172 YANG files I have in an > > archive are probably unaware of this discussion and yet some at least > > will be affected. What concerns me is that history might be repeating > > itself. In a sense, this discussion is about the original proposals for > > NETCONF and YANG not meeting current requirements which > > may be because there has mostly been a limited number of > > participants in netmod discussions. > > So two points on this: > - Today is different in that there are a great number of players > using/looking to YANG at the moment --- so I think we have more lurkers > out there than you'd expect. > > - The fact that 172 documents (and that's just in the IETF) would be > impacted by option (A) is exactly why we think it's the wrong way to go. > Think about if we came up with a solution that requires each modeler to > build their definitions a fixed way how this would be > socialized/enforced. Now think about doing that in other SDOs. > > > I was struck by Dale's recent, brilliant review of 6020bis because it > > came from a fresh angle and brought up nagging concerns that I had had > > but had not been able to articulate. With a wider audience, similar > > comments might have been made much earlier to the advantage > > of YANG (perhaps even about RFC6020). > > > > In the same vein, there is NETCONF. Juergen's I-D, which I see finding > > favour, could be said to cut the ground from under NETCONF (well, I > > would). RFC6241 says > > " Configuration data is the set of writable data that is required to > > transform a system from its initial default state into its current > > state. State data is the additional data on a system that is not > > configuration data such as read-only status information and collected > > statistics. " > > > > The proposed 'intended' in the I-D is (ct, ro). It is ct, configuration > > true, so it is configuration data. It is ro, read only, so it is > > clearly not > > configuration data. Without changing RFC6241, I cannot reconcile this. > It's just a ro version/view of the config data. I'm not sure why this > is problematic. Perhaps I'm just missing something. > > > So I see RFC6241 being changed; can anyone reading the RFC understand it > > any more? And yet the I-D makes no mention of this change to > > NETCONF nor have I seen any discussion on the netconf list. > > > > Stimulated by posts to the I2RS list, perhaps also a trigger for > > Juergen's I-D, I wrote up my own summary of the current state of > > datastores but I called it draft-tp-netconf-datastore because I see > > NETCONF > > currently telling us almost all that we know about datastores; YANG 1.0 > > adds very little. For me, NETCONF should be the starting point. > The first question is deciding on an approach (A vs B), the second > question is on the details of the selected option. If we move forward > with B, I think which WG does the data store work is a fine topic to > consider. But we (netmod) first need to close on A vs B -- which will > be easy if there are no new comments in short order. > > Lou > > Tom Petch > > > > ----- Original Message ----- > > From: "Lou Berger" From nobody Sun Jun 19 08:02:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED7012D1E0 for ; Sun, 19 Jun 2016 08:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, 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 090uwwhEKJ92 for ; Sun, 19 Jun 2016 08:02:52 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 11B6312D1BD for ; Sun, 19 Jun 2016 08:02:52 -0700 (PDT) Received: (qmail 11722 invoked by uid 0); 19 Jun 2016 15:02:49 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 19 Jun 2016 15:02:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 8f2Y1t00Q2SSUrH01f2baz; Sun, 19 Jun 2016 09:02:49 -0600 X-Authority-Analysis: v=2.1 cv=KpLehwmN 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=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=oK_VWpv5GtAA:10 a=pD_ry4oyNxEA:10 a=voZKSeMjAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=3HIYsarxFalxpHcw-RYA:9 a=K3fsatB5F1bQokz1:21 a=KKdC6nUIV0Df1HhW:21 a=CjuIK1q_8ugA:10 a=9_PflfxPP4jfUBPIDKbT: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:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From; bh=00EScvBtTLgHe5UQzMUytYwOafooR0mdHioM2te09dI=; b=KM2Rny0kF5nX9x7kb9T8vveX0Y 7kM+ViPpPEvRNbTA+4R7JC1VGIfxJtJLiThQuB89CNLf71Mos9p1beBqVsxNa38ln+sDE96EwVIs6 0mrcf+QPW15Gbt6K0Qk+YrIsJ; Received: from [100.15.89.178] (port=47272 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.86_2) (envelope-from ) id 1bEeEk-00060h-0h; Sun, 19 Jun 2016 09:02:32 -0600 From: Lou Berger To: "t.petch" , netmod WG Date: Sun, 19 Jun 2016 11:01:58 -0400 Message-ID: <155692eba70.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> User-Agent: AquaMail/1.6.2.3 (build: 27000203) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.89.178 authed with lberger@labn.net} Archived-At: Cc: netmod-chairs@ietf.org, netconf-chairs@tools.ietf.org Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 15:02:55 -0000 Hi Tom, On June 19, 2016 5:54:20 AM t.petch wrote: > Lou > > You say below > " >> It's just a ro version/view of the config data. I'm not sure why this >> is problematic. Perhaps I'm just missing something. > " > > I see it as a fundamental change (to NETCONF). Tracking other lists > (e.g.I2RS) I repeatedly get the sense that they have not grasped what > configuration data is (editable, potential persistent but a minute > fraction of what a box needs to operate), and by contrast what is state. > I see some, if not many, of Juergen's posts to that list as reflecting > that such as > "I have no clue what the above sentence is trying to say. Please try to > use YANG terminology. " > > Every time I read 'ephemeral state' I think the same; state is > ephemeral, the phrase does not convey any meaning (except that the user > does not understand what configuration is). > > And this comes mostly from RFC6241 not from RFC6020. > > So, I see a strong preference for Option B which is all very logical, as > Acee points out. But Option B I see as being a fundamental change to > RFC6241, so if the netmod WG takes that decision, then it is stamping on > the netconf WG. Perhaps the WG should be merged, now that 6020bis is on > its way, but for the moment, I believe that changes to NETCONF need the > consensus of the NETCONF WG. > So feel free to look at the decision for the netmod group as to follow option a, or not to follow a. Once the decision is made, we certainly will sync up with netconf chairs. Thanks, Lou > Tom Petch > > ----- Original Message ----- > From: "Lou Berger" > To: "t.petch" ; "netmod WG" > Cc: > Sent: Friday, June 17, 2016 7:22 PM > Subject: Re: [netmod] Opstate solutions discussions: update and request > for WGinput > > >> Tom, >> >> Thanks for the perspective. I'm a little unsure if you're > expecting >> a response or just making a statement, so if you're looking for >> something specific and don't see it below -- please let me know. >> >> On 6/17/2016 11:15 AM, t.petch wrote: >> > Lou >> > >> > By now, 17th June, I see solid support for one option but only see >> > comments from a somewhat small number of participants >> This is true, and I've heard privately that some more may/should be >> forthcoming. >> >> > The majority of the authors of the 172 YANG files I have in an >> > archive are probably unaware of this discussion and yet some at > least >> > will be affected. What concerns me is that history might be > repeating >> > itself. In a sense, this discussion is about the original proposals > for >> > NETCONF and YANG not meeting current requirements which >> > may be because there has mostly been a limited number of >> > participants in netmod discussions. >> >> So two points on this: >> - Today is different in that there are a great number of players >> using/looking to YANG at the moment --- so I think we have more > lurkers >> out there than you'd expect. >> >> - The fact that 172 documents (and that's just in the IETF) would be >> impacted by option (A) is exactly why we think it's the wrong way to > go. >> Think about if we came up with a solution that requires each modeler > to >> build their definitions a fixed way how this would be >> socialized/enforced. Now think about doing that in other SDOs. >> >> > I was struck by Dale's recent, brilliant review of 6020bis because > it >> > came from a fresh angle and brought up nagging concerns that I had > had >> > but had not been able to articulate. With a wider audience, similar >> > comments might have been made much earlier to the advantage >> > of YANG (perhaps even about RFC6020). >> > >> > In the same vein, there is NETCONF. Juergen's I-D, which I see > finding >> > favour, could be said to cut the ground from under NETCONF (well, I >> > would). RFC6241 says >> > " Configuration data is the set of writable data that is required to >> > transform a system from its initial default state into its > current >> > state. State data is the additional data on a system that is not >> > configuration data such as read-only status information and > collected >> > statistics. " >> > >> > The proposed 'intended' in the I-D is (ct, ro). It is ct, > configuration >> > true, so it is configuration data. It is ro, read only, so it is >> > clearly not >> > configuration data. Without changing RFC6241, I cannot reconcile > this. >> It's just a ro version/view of the config data. I'm not sure why this >> is problematic. Perhaps I'm just missing something. >> >> > So I see RFC6241 being changed; can anyone reading the RFC > understand it >> > any more? And yet the I-D makes no mention of this change to >> > NETCONF nor have I seen any discussion on the netconf list. >> > >> > Stimulated by posts to the I2RS list, perhaps also a trigger for >> > Juergen's I-D, I wrote up my own summary of the current state of >> > datastores but I called it draft-tp-netconf-datastore because I see >> > NETCONF >> > currently telling us almost all that we know about datastores; YANG > 1.0 >> > adds very little. For me, NETCONF should be the starting point. >> The first question is deciding on an approach (A vs B), the second >> question is on the details of the selected option. If we move forward >> with B, I think which WG does the data store work is a fine topic to >> consider. But we (netmod) first need to close on A vs B -- which > will >> be easy if there are no new comments in short order. >> >> Lou >> > Tom Petch >> > >> > ----- Original Message ----- >> > From: "Lou Berger" > > From nobody Sun Jun 19 08:23:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B654912D50C for ; Sun, 19 Jun 2016 08:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpdLzn6jDoEV for ; Sun, 19 Jun 2016 08:23:38 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 F3D7E12D195 for ; Sun, 19 Jun 2016 08:23:37 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id d185so169467726vkg.0 for ; Sun, 19 Jun 2016 08:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kSG4FjV73AJN3JIGwlKimio8J0ixsr879ZEmv1uWEBs=; b=VXBgWn746JxV2I+/8tnhXtOVmTfAzymtzmUMEdsYzjOi/qh70AII2Xc6Ctp8cgnRJ0 5kexu36LMiec5kbCpQHPMyl/Ce2nbgDRrSJKjlmmTisumREaos4+RxIvzQgpIuJSbi9f rhZEx10pxNZo6FwIfuukv4k3p+sEQ/5VuGxanXMO+uaBcJ/KLX7hRCSrRq2FIio41xRH 3kzOtOKktIKHxHFcO+6cVolvKyv4bEX01ELwBgRK6VvKf8qQMmB2t7726ah7C685N33V 5BjKp+TNcFFRbqMignZH1PHHnK0EMMrJO5yi8J864wwflru0vaciiHlGcJHmscV5GE7f c6dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kSG4FjV73AJN3JIGwlKimio8J0ixsr879ZEmv1uWEBs=; b=WjNdH3ubyhyHK3b12aseHwKQ5BEczNfWwrzccmB7zGfXZ9FFa8rlX46v3s/qRejO9a Avzcbne32A4iLVTXywoclot8uT1X35ilH4CAQe8e9PZw8vb1D9rAC252OQzxa5bn7mFk 8bBa0g4KpOx7F5WTvpgtlM2McyatPkhnxDNJsIpBwkfXNtYuCkxdwUeun8O/IIQF3/9Y 5CTqf8hlS1gmCNpYY+hu3tsoQuYCfHysiDje/lP03iZCmhyMrU1fzM8YO51fTx1hlz7o TNi0ZHmeiBk/Z4JbfOS8etwvTog0B+R8cjrzWJoZQ7IW1z9g9x6C2d/FfUeSY8V6fNln c/Cw== X-Gm-Message-State: ALyK8tIefSU+Rc6/8mqF3r+DQTcre1LQlGEl/lAiNIVzbPLPa0aGCLOfUpaSxPjkXr6QP1Wolvoj7MuMAO+A0A== MIME-Version: 1.0 X-Received: by 10.31.132.77 with SMTP id g74mr5214192vkd.121.1466349816855; Sun, 19 Jun 2016 08:23:36 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Sun, 19 Jun 2016 08:23:36 -0700 (PDT) In-Reply-To: <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> Date: Sun, 19 Jun 2016 08:23:36 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a1144f9d8f356610535a32b27 Archived-At: Cc: netmod-chairs@ietf.org, netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 15:23:41 -0000 --001a1144f9d8f356610535a32b27 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 19, 2016 at 2:52 AM, t.petch wrote: > Lou > > You say below > " > > It's just a ro version/view of the config data. I'm not sure why this > > is problematic. Perhaps I'm just missing something. > " > > I see it as a fundamental change (to NETCONF). Tracking other lists > (e.g.I2RS) I repeatedly get the sense that they have not grasped what > configuration data is (editable, potential persistent but a minute > fraction of what a box needs to operate), and by contrast what is state. > I see some, if not many, of Juergen's posts to that list as reflecting > that such as > "I have no clue what the above sentence is trying to say. Please try to > use YANG terminology. " > > Every time I read 'ephemeral state' I think the same; state is > ephemeral, the phrase does not convey any meaning (except that the user > does not understand what configuration is). > > And this comes mostly from RFC6241 not from RFC6020. > > So, I see a strong preference for Option B which is all very logical, as > Acee points out. But Option B I see as being a fundamental change to > RFC6241, so if the netmod WG takes that decision, then it is stamping on > the netconf WG. Perhaps the WG should be merged, now that 6020bis is on > its way, but for the moment, I believe that changes to NETCONF need the > consensus of the NETCONF WG. > I disagree. I have implemented NETCONF and RESTCONF and I do not see any problems with adding additional (optional) datastores. As often the case in the IETF, when a WG does not have consensus on a particular topic, the standard is silent on that topic. That is what happened with config=false in RFC 6241 and 6020. I don't see a problem with a datastore model that evolves over time. > > Tom Petch > Andy > > ----- Original Message ----- > From: "Lou Berger" > To: "t.petch" ; "netmod WG" > Cc: > Sent: Friday, June 17, 2016 7:22 PM > Subject: Re: [netmod] Opstate solutions discussions: update and request > for WGinput > > > > Tom, > > > > Thanks for the perspective. I'm a little unsure if you're > expecting > > a response or just making a statement, so if you're looking for > > something specific and don't see it below -- please let me know. > > > > On 6/17/2016 11:15 AM, t.petch wrote: > > > Lou > > > > > > By now, 17th June, I see solid support for one option but only see > > > comments from a somewhat small number of participants > > This is true, and I've heard privately that some more may/should be > > forthcoming. > > > > > The majority of the authors of the 172 YANG files I have in an > > > archive are probably unaware of this discussion and yet some at > least > > > will be affected. What concerns me is that history might be > repeating > > > itself. In a sense, this discussion is about the original proposals > for > > > NETCONF and YANG not meeting current requirements which > > > may be because there has mostly been a limited number of > > > participants in netmod discussions. > > > > So two points on this: > > - Today is different in that there are a great number of players > > using/looking to YANG at the moment --- so I think we have more > lurkers > > out there than you'd expect. > > > > - The fact that 172 documents (and that's just in the IETF) would be > > impacted by option (A) is exactly why we think it's the wrong way to > go. > > Think about if we came up with a solution that requires each modeler > to > > build their definitions a fixed way how this would be > > socialized/enforced. Now think about doing that in other SDOs. > > > > > I was struck by Dale's recent, brilliant review of 6020bis because > it > > > came from a fresh angle and brought up nagging concerns that I had > had > > > but had not been able to articulate. With a wider audience, similar > > > comments might have been made much earlier to the advantage > > > of YANG (perhaps even about RFC6020). > > > > > > In the same vein, there is NETCONF. Juergen's I-D, which I see > finding > > > favour, could be said to cut the ground from under NETCONF (well, I > > > would). RFC6241 says > > > " Configuration data is the set of writable data that is required to > > > transform a system from its initial default state into its > current > > > state. State data is the additional data on a system that is not > > > configuration data such as read-only status information and > collected > > > statistics. " > > > > > > The proposed 'intended' in the I-D is (ct, ro). It is ct, > configuration > > > true, so it is configuration data. It is ro, read only, so it is > > > clearly not > > > configuration data. Without changing RFC6241, I cannot reconcile > this. > > It's just a ro version/view of the config data. I'm not sure why this > > is problematic. Perhaps I'm just missing something. > > > > > So I see RFC6241 being changed; can anyone reading the RFC > understand it > > > any more? And yet the I-D makes no mention of this change to > > > NETCONF nor have I seen any discussion on the netconf list. > > > > > > Stimulated by posts to the I2RS list, perhaps also a trigger for > > > Juergen's I-D, I wrote up my own summary of the current state of > > > datastores but I called it draft-tp-netconf-datastore because I see > > > NETCONF > > > currently telling us almost all that we know about datastores; YANG > 1.0 > > > adds very little. For me, NETCONF should be the starting point. > > The first question is deciding on an approach (A vs B), the second > > question is on the details of the selected option. If we move forward > > with B, I think which WG does the data store work is a fine topic to > > consider. But we (netmod) first need to close on A vs B -- which > will > > be easy if there are no new comments in short order. > > > > Lou > > > Tom Petch > > > > > > ----- Original Message ----- > > > From: "Lou Berger" > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1144f9d8f356610535a32b27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Jun 19, 2016 at 2:52 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
Lou

You say below
"
> It's just a ro version/view of the config data.=C2=A0 I'm not = sure why this
> is problematic.=C2=A0 Perhaps I'm just missing something.
"

I see it as a fundamental change (to NETCONF).=C2=A0 Tracking other lists (e.g.I2RS) I repeatedly get the sense that they have not grasped what
configuration data is (editable, potential persistent but a minute
fraction of what a box needs to operate), and by contrast what is state. I see some, if not many, of Juergen's posts to that list as reflecting<= br> that such as
"I have no clue what the above sentence is trying to say. Please try t= o
use YANG terminology. "
=C2=A0
Every time I read 'ephemeral state' I think the same; state is
ephemeral, the phrase does not convey any meaning (except that the user
does not understand what configuration is).

And this comes mostly from RFC6241 not from RFC6020.

So, I see a strong preference for Option B which is all very logical, as Acee points out.=C2=A0 But Option B I see as being a fundamental change to<= br> RFC6241, so if the netmod WG takes that decision, then it is stamping on the netconf WG.=C2=A0 Perhaps the WG should be merged, now that 6020bis is = on
its way, but for the moment, I believe that changes to NETCONF need the
consensus of=C2=A0 the NETCONF WG.

I di= sagree.
I have implemented NETCONF and RESTCONF and I do not see = any problems with
adding additional (optional) datastores.
<= div>
As often the case in the IETF, when a WG does not have c= onsensus on a particular
topic, the standard is silent on that to= pic.=C2=A0 That is what happened with config=3Dfalse in RFC 6241
= and 6020.=C2=A0 I don't see a problem with a datastore model that evolv= es over time.

=C2=A0

Tom Petch

Andy
=C2=A0

----- Original Message -----
From: "Lou Berger" <lberge= r@labn.net>
To: "t.petch" <ietfc@bt= connect.com>; "netmod WG" <netmod@ietf.org>
Cc: <netmod-chairs@ietf.org>
Sent: Friday, June 17, 2016 7:22 PM
Subject: Re: [netmod] Opstate solutions discussions: update and request
for WGinput


> Tom,
>
>=C2=A0 =C2=A0 =C2=A0Thanks for the perspective.=C2=A0 I'm a little = unsure if you're
expecting
> a response or just making a statement, so if you're looking for > something specific and don't see it below -- please let me know. >
> On 6/17/2016 11:15 AM, t.petch wrote:
> > Lou
> >
> > By now, 17th June, I see solid support for one option but only se= e
> > comments from a somewhat small number of participants
> This is true, and I've heard privately that some more may/should b= e
> forthcoming.
>
> > The majority of the authors of the 172 YANG files I have in an > > archive are probably unaware of this discussion and yet some at least
> > will be affected.=C2=A0 What concerns me is that history might be=
repeating
> > itself.=C2=A0 In a sense, this discussion is about the original p= roposals
for
> > NETCONF and YANG not meeting current requirements which
> > may be because there has mostly been a limited number of
> > participants in netmod discussions.
>
> So two points on this:
> - Today is different in that there are a great number of players
> using/looking to YANG at the moment --- so I think we have more
lurkers
> out there than you'd expect.
>
> - The fact that 172 documents (and that's just in the IETF) would = be
> impacted by option (A) is exactly why we think it's the wrong way = to
go.
> Think about if we came up with a solution that requires each modeler to
> build their definitions a fixed way how this would be
> socialized/enforced.=C2=A0 Now think about doing that in other SDOs. >
> > I was struck by Dale's recent, brilliant review of 6020bis be= cause
it
> > came from a fresh angle and brought up nagging concerns that I ha= d
had
> > but had not been able to articulate.=C2=A0 With a wider audience,= similar
> > comments might have been made much earlier to the advantage
> > of YANG (perhaps even about RFC6020).
> >
> > In the same vein, there is NETCONF.=C2=A0 Juergen's I-D, whic= h I see
finding
> > favour, could be said to cut the ground from under NETCONF (well,= I
> > would).=C2=A0 RFC6241 says
> > " Configuration data is the set of writable data that is req= uired to
> >=C2=A0 =C2=A0 transform a system from its initial default state in= to its
current
> >=C2=A0 =C2=A0 state.=C2=A0 State data is the additional data on a = system that is not
> >=C2=A0 =C2=A0 configuration data such as read-only status informat= ion and
collected
> >=C2=A0 =C2=A0 statistics.=C2=A0 "
> >
> > The proposed 'intended' in the I-D is (ct, ro).=C2=A0 It = is ct,
configuration
> > true, so it is configuration data.=C2=A0 It is ro, read only, so = it is
> > clearly not
> > configuration data.=C2=A0 Without changing RFC6241, I cannot reco= ncile
this.
> It's just a ro version/view of the config data.=C2=A0 I'm not = sure why this
> is problematic.=C2=A0 Perhaps I'm just missing something.
>
> > So I see RFC6241 being changed; can anyone reading the RFC
understand it
> > any more?=C2=A0 And yet the I-D makes no mention of this change t= o
> > NETCONF nor have I seen any discussion on the netconf list.
> >
> > Stimulated by posts to the I2RS list, perhaps also a trigger for<= br> > > Juergen's I-D, I wrote up my own summary of the current state= of
> > datastores but I called it draft-tp-netconf-datastore because I s= ee
> > NETCONF
> > currently telling us almost all that we know about datastores; YA= NG
1.0
> > adds very little.=C2=A0 For me, NETCONF should be the starting po= int.
> The first question is deciding on an approach (A vs B), the second
> question is on the details of the selected option.=C2=A0 If we move fo= rward
> with B, I think which WG does the data store work is a fine topic to > consider.=C2=A0 But we (netmod)=C2=A0 first need to close on A vs B --= which
will
> be easy if there are no new comments in short order.
>
> Lou
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Lou Berger" <lberger@labn.net>

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

--001a1144f9d8f356610535a32b27-- From nobody Sun Jun 19 11:50:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E59F12D733 for ; Sun, 19 Jun 2016 11:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_XRQGutzZxR for ; Sun, 19 Jun 2016 11:50:25 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [IPv6:2001:1900:3001:11::28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324ED12D731 for ; Sun, 19 Jun 2016 11:50:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 75EDB1E5D67; Sun, 19 Jun 2016 11:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8jfUhueu_aQ3; Sun, 19 Jun 2016 11:49:32 -0700 (PDT) Received: from [192.168.1.100] (host81-132-48-184.range81-132.btcentralplus.com [81.132.48.184]) by c8a.amsl.com (Postfix) with ESMTPSA id 454671E5D61; Sun, 19 Jun 2016 11:49:31 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_B4D9CD0F-B793-45B1-BA37-0769C3FC0FBD" From: William Lupton In-Reply-To: Date: Sun, 19 Jun 2016 19:50:21 +0100 Message-Id: <36FAEC4F-E37F-4C13-A886-3322BAF9FFBF@broadband-forum.org> References: <20160618.153704.551194433238049271.mbj@tail-f.com> <20160618162150.GA37197@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] bits lexical representation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 18:50:29 -0000 --Apple-Mail=_B4D9CD0F-B793-45B1-BA37-0769C3FC0FBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It was actually a YANG default that triggered my original question. If = repetition were officially forbidden or discouraged then presumably it = would be permissible for pyang (and other tools) to check for it and = issue an error or warning if it finds it. W. > On 18 Jun 2016, at 17:54, Andy Bierman wrote: >=20 > On Sat, Jun 18, 2016 at 9:21 AM, Juergen Schoenwaelder = > wrote: > On Sat, Jun 18, 2016 at 03:37:04PM +0200, Martin Bjorklund wrote: > > William Lupton > wrote: > > > RFC 6020bis Section 9.7.2 is silent on the question of whether bit > > > names can be repeated in a bits value, e.g is =E2=80=9Cuno dos dos = tres=E2=80=9D valid > > > or invalid? > > > > 9.7.4 says: > > > > All assigned names in a bits type MUST be unique. > > >=20 > I think this sentence says that >=20 > leaf a { > type bits { > bit a; > bit a; > } > } >=20 > is illegal while I think the question was about the value encoding, > that is, given the definition >=20 > leaf b { > type bits { > bit a; > bit b; > } > } >=20 > is a b b illegal. I do not think this is specified but of > course a decent implementation would not generate something like this > and an implementation following the robustness principle would simply > ignore bits that are encoded multiple times. >=20 >=20 > I don't think this is "of course". It should be clear 1 way or the = other. > We do not have warnings in the protocols that are usable, so silently = ignoring > extra bits may not help the client developer find out why there is a = duplicate bit. > Probably a programming error and a different bit was meant to be set. > (So returning an error may be "of course"). >=20 > =20 > /js >=20 >=20 > Andy > =20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = >=20 --Apple-Mail=_B4D9CD0F-B793-45B1-BA37-0769C3FC0FBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
It was actually a YANG default that triggered = my original question. If repetition were officially forbidden or = discouraged then presumably it would be permissible for pyang (and other = tools) to check for it and issue an error or warning if it finds it. = W.

On 18 Jun 2016, at 17:54, Andy Bierman <andy@yumaworks.com> = wrote:

On Sat, = Jun 18, 2016 at 9:21 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Jun 18, 2016 = at 03:37:04PM +0200, Martin Bjorklund wrote:
> William Lupton <wlupton@broadband-forum.org> wrote:
> > RFC 6020bis Section 9.7.2 is silent on the question of whether = bit
> > names can be repeated in a bits value, e.g is =E2=80=9Cuno dos = dos tres=E2=80=9D valid
> > or invalid?
>
> 9.7.4 says:
>
>   All assigned names in a bits type MUST be unique.
>

I think this sentence says that

leaf a {
  type bits {
    bit a;
    bit a;
  }
}

is illegal while I think the question was about the value encoding,
that is, given the definition

leaf b {
  type bits {
    bit a;
    bit b;
  }
}

is <b>a b b</b> illegal. I do not think this is specified = but of
course a decent implementation would not generate something like this
and an implementation following the robustness principle would simply
ignore bits that are encoded multiple times.


I don't think this is "of = course".  It should be clear 1 way or the other.
We do not have warnings in the protocols that are usable, so = silently ignoring
extra bits may not help the = client developer find out why there is a duplicate bit.
Probably a programming error and a different bit was meant to = be set.
(So returning an error may be "of = course").

 
/js


Andy
 
--
Juergen Schoenwaelder           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | = 28759 Bremen | Germany
Fax:   +49 421 200 3103        =  <http://www.jacobs-university.de/>

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


= --Apple-Mail=_B4D9CD0F-B793-45B1-BA37-0769C3FC0FBD-- From nobody Sun Jun 19 22:43:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321E012D8E5; Sun, 19 Jun 2016 20:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.355 X-Spam-Level: X-Spam-Status: No, score=-14.355 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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=-1.426, 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 noz5FKahEUVw; Sun, 19 Jun 2016 20:19:18 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28B012D8DA; Sun, 19 Jun 2016 20:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4369; q=dns/txt; s=iport; t=1466392757; x=1467602357; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6tsgS9zVU9zjpKS5/XFShMqQWUfYovAsZ3BO4+HZ28A=; b=d8beE8LymkW1qBncMUY9BlIrImj6+joLv1jmyMfIhr8qHuUmgT6v5LBU yPM5f1EVZ+kkX2Oh4yzLQSjm5UjfQzDMX0ExB4ZBquwi+0Adl54CRi7XK FrODAPlOkQBdgW6vCSI1yQYnI1B1UZvEEVSV45dUtIYOUr9/0JHP7ex6H k=; X-IronPort-AV: E=Sophos;i="5.26,496,1459814400"; d="scan'208";a="114633310" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2016 03:19:17 +0000 Received: from [10.24.70.9] ([10.24.70.9]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5K3JEeC027978; Mon, 20 Jun 2016 03:19:14 GMT To: Liaison Statement Management Tool , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Joel Jaeggli , Tom Nadeau , Mahesh Jethanandani , Mehmet Ersue References: <20160518204443.14700.50752.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Sun, 19 Jun 2016 14:33:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160518204443.14700.50752.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 19 Jun 2016 22:43:47 -0700 Cc: NETMOD Working Group , "\\\"Kent Watsen\\\"" <"kwatsen@junip\""@ietfa.amsl.co>, joelja@bogus.com, IETF Chair , NETCONF , David Sinicrope Subject: Re: [netmod] New Liaison Statement, "Liaison to IETF on YANG Models to enable G.fast deployments" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 03:19:20 -0000 Dear all, The NETMOD and NETCONF WGs thank you for referencing the work of the IETF and contributing to the drafts you mention through the IETF process. This is by far the best way to complete the work in a timely manner and continues to foster the open and cooperative working relationship between the IETF and the Broadband Forum. In the mean time, the two drafts you note became WG documents: draft-ietf-netmod-entity and draft-ietf-netmod-intf-ext-yang-00. We encourage you to follow progress on data tracker https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ and https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ and through the participation you have noted. Regarding your interest to work on "forwarding/QoS and required protocols (e.g. layer 2 multicast model & DHCP)", please note that there are already a couple of forwarding related YANG data models, mainly L3 forwarding. There is also a QoS related YANG data model, draft-asechoud-netmod-qos-model, which we believe could become a WG document. And finally, a YANG multicast design team, https://trac.tools.ietf.org/wg/pim/trac/wiki/yang, focuses on producing PIM and IGMP/MLD YANG data models. Please work with the respective contributors so that the layer 2 specific data model aspects nicely fit in the overall data models. If you have interest in other related IETF work please don't hesitate to let us know. Please continue to keep us apprised of your work noted. Regards, Benoit (OPS AD) > Title: Liaison to IETF on YANG Models to enable G.fast deployments > Submission Date: 2016-05-18 > URL of the IETF Web page: https://datatracker.ietf.org/liaison/1476/ > > From: "Michael Fargano" > To: Benoit Claise ,Joel Jaeggli ,Mahesh Jethanandani ,Mehmet Ersue ,Jürgen Schönwälder , Tom Nadeau > Cc: Joel Jaeggli ,Mahesh Jethanandani ,David Sinicrope ,Jürgen Schönwälder ,Kent Watsen ,Mehmet Ersue ,NETCONF Data Modeling Language Discussion List ,The IETF Chair ,Lou Berger ,Benoit Claise ,Network Configuration Discussion List , > Response Contacts: > Technical Contacts: > Purpose: For information > > Body: The Broadband Forum is developing YANG models to meet the end 2016/early 2017 > G.fast deployment timeline announced by several service providers. Broadband Forum > practice is to base its YANG work on existing IETF YANG models and expertise. > > In the Broadband Forum meeting of 18-22 April, the Fiber to the Distribution Point (FTTdp) > Work Area agreed to work on developing YANG models based on draft-entitydt-netmodentity > & draft-wilton-netmod-intf-ext-yang for G.fast deployments meeting the above > timelines. Given our interest in these drafts, participants will work within the IETF > according to IETF processes, to help progress them. Please keep us apprised of progress > of these drafts. > > Further, we would like to inform you that our FTTdp Work Area is defining YANG models > for Broadband Forum specific context and use cases for : > > - forwarding/QoS and required protocols (e.g. layer 2 multicast model & DHCP) > - bulk data collection (evaluating draft-ietf-netconf-yang-push and related work), > - software image management, > - operational states (evaluating draft-ietf-netmod-opstate-reqs and related work) > > Once the models reach a level of maturity we plan to share these with IETF for review and > comment. Comments from IETF may be made via a liaison or BBF members may > comment directly. > > Please see below for information on our next meetings. > > Sincerely, > Michael Fargano, > Broadband Forum Technical Committee Chair > Attachments: > > Liaison to IETF on YANG Models to enable G.fast deployments > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-05-18-broadband-forum-ops-netconf-netmod-liaison-to-ietf-on-yang-models-to-enable-gfast-deployments-attachment-1.pdf > > . > From nobody Sun Jun 19 22:58:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D876D12D12B for ; Sun, 19 Jun 2016 22:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 55bs6O4t0IYR for ; Sun, 19 Jun 2016 22:58:54 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CF312D0B1 for ; Sun, 19 Jun 2016 22:58:53 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:9592:9c1b:da7d:9c06] (unknown [IPv6:2001:718:1a02:1:9592:9c1b:da7d:9c06]) by mail.nic.cz (Postfix) with ESMTPSA id 79CBC61105; Mon, 20 Jun 2016 07:58:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466402332; bh=9rM1vEsX50pyXhJNjWS2D5TflpEEQGuc/JyaFDs4LrY=; h=From:Date:To; b=WlUFgN2bTOhwRSsl//LRW9stRGlOYS1oqU9ZCV+ZYLVt/rDD1tM0WCUWYqWt5LHe1 GGlp76Gqoi0BK0qA1ci3r3pOZH7AiSZ6G5nY6dWnta7ZwZ220rrXnmYZ9UAWcQ2wK9 i1cTJE4ztwtXShzjca3lgcj8ylY6yqM2zEvax/EA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 20 Jun 2016 07:58:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE5B1A5-FE12-4A05-AA34-34B8136C2FDC@nic.cz> References: <20160617165442.9746.5342.idtracker@ietfa.amsl.com> To: Andy Bierman X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Protocol Action: 'The YANG 1.1 Data Modeling Language' to Proposed Standard (draft-ietf-netmod-rfc6020bis-14.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 05:58:56 -0000 > On 18 Jun 2016, at 01:47, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Jun 17, 2016 at 9:54 AM, The IESG = wrote: > The IESG has approved the following document: > - 'The YANG 1.1 Data Modeling Language' > (draft-ietf-netmod-rfc6020bis-14.txt) as Proposed Standard >=20 > This document is the product of the NETCONF Data Modeling Language > Working Group. >=20 > The IESG contact persons are Benoit Claise and Joel Jaeggli. >=20 > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ >=20 >=20 >=20 >=20 > great news! >=20 > So are we ready for a YANG 1.1 Interoperability Test yet? > Our client/server support is almost done -- I suspect some more = implementations > are in the same state. Maybe a bakeoff at IETF #97 in November? +1 Lada >=20 >=20 > Andy >=20 >=20 >=20 >=20 > Technical Summary >=20 > YANG is a data modeling language used to model configuration data, > state data, remote procedure calls, and notifications for network > management protocols like the Network Configuration Protocol > (NETCONF). This document defines YANG version 1.1. >=20 > Working Group Summary >=20 > This is an update of YANG 1.0 as defined in RFC 6020. The working > group used an issue tracker and a number of virtual interim meetings > to discuss all bug fix proposals and feature requests. The document > went through two WG last calls and there is broad consensus on the > final version. >=20 > Document Quality >=20 > Recent versions of the open source pyang implementation support this > specification. Additional commercial implementations are expected to > follow soon. >=20 > Personnel >=20 > Juergen Schoenwaelder is the document shepherd and Benoit Claise is > the responsible AD. >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jun 21 05:17:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1900B12B03B for ; Tue, 21 Jun 2016 05:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2RhIe5uqAoD for ; Tue, 21 Jun 2016 05:17:24 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F1112B00A for ; Tue, 21 Jun 2016 05:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=By0TF4gMkraiUCG5exfcu2dW/NCqvsr+9fcmk8s/XTY=; b=Mc/1PfF+Ys7tq+VrbL+8Tub1iLhmGzF9Jpfh1qYr7pUYfjceL7/gizzeXhsl+cFzoZOse4iJ2p0Krj0djb2zk0gqXU31BKDHa7FWnDPbdzGeg1JHamg9YjjyzaOZZ1oRqfwYcg5sx1Ct5OriU+Ldq8ecnkjsbMzNBDn6FIcHlv0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (81.151.165.8) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 21 Jun 2016 12:17:05 +0000 Message-ID: <019f01d1cbb6$950e8c20$4001a8c0@gateway.2wire.net> From: t.petch To: Martin Bjorklund References: <20160617165442.9746.5342.idtracker@ietfa.amsl.com> <9DE5B1A5-FE12-4A05-AA34-34B8136C2FDC@nic.cz> Date: Tue, 21 Jun 2016 13:10:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.165.8] X-ClientProxiedBy: HE1PR06CA0079.eurprd06.prod.outlook.com (10.164.28.175) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) X-MS-Office365-Filtering-Correlation-Id: 0339157f-243f-435f-5a1a-08d399cdf589 X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:l6k365IpPuaHFenDwpTvMzoxBpYf+E8TET/GMhv+HSkZo0MKTp5If/ow6PyUBjpKpnY05N5zAiBUg2UaitncauBsStMQjldyETZ1JsoOI2cGls/CexgQf8o4x9vVc1jk53W43RQ95B1ggS64TVytQ1Xq5gUCb0+y7O1ei+NEu16fgRi7NfxtxK+yav0QzLHY; 3:dzmCloU1HaZTJxI1WMKGt2yd5WSWWa8wQm76ad091Sf/BCkasWPRn9HXTmhlay49Z6cja0SJq21E3RMXHi15olihc5z9aGEtK0k0D/8ICY+UAdqQp0+xsBPV/QEEu3P7 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 25:pfVpj1xSNcG5MVOi5XRPLJ9f8GZhH1t5Vb3FWiZ2CLyWQKQwOEr+hoPvJL+DzOoUGmzVXdZ9HpxHG99B4I8eE/4xFo7ZTn0zRprjYtr5fTohm0YbIDDYCYaa/WK4xlmgT9sNbM5iW/cY5/r0EKJp+gTbzLQTZtlZEaH/G2xtLvBjfDsGvYqGrwksKMYK6IMnPRkNb8JbJx7vKhQov4bahh7/gVmt5RxU3+16psabGp4tVI9eh5Dl1qAStUNjEzXw3EW7ztYmvblaq2jk1GBOSL2X+eEd8WUq9gFKS9+p5ZuEK0FB9elrY9bhbYMgPv+MfzTbP4I1fLWIzcJC+zeS8YNxjk17HUvCdieXKM+pyP21s0HmBzp0l0k92kjEFT4D+QZG39HIXvGaUULJ3gdOCGK1Z+b3jV5f5wPHvIe/1WgJruNf2fHBTJAK1EemzlT6piSDH4I4usOwRKJYU7W6vDV+vNIrGlz0d4YmoCGP7gWQmDsdUBQaO2MhAMYmHIMFPq8HdJPr7tqKFGAqpB5JPeJeIXvvHl/QetlNX2Hw7l2dQDGRK8iwv1U8KnmEGq1Yht1OoUFZhcjFTQbdC9W9Znhdms0LBtxED/GcT2JqGqg63QSPumWBaGITXgGE3UjmmA+pJ5yI/u0zanzJS45AQcOd7enEQy36htBrkHBnW9h3HnzcY8zhHuFm+lskssCTswNzcvlhFpiqTv18nNOpLL1Ym755fktLx2eUIvRnBaHkhwIuCvE3HzL7zqALr5GSokkSB7IyanNq1y5ot8CFm+xemddNOuknTGc6RNnyGqp8YVJvxmGu5uN/0ajhsq3rgsRp7vm6n9ZmFmuzlkHgYw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(120809045254105)(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:3BPSDkrf9RjmLiin6y6tG7N6VrpcvFOcVVduGJ1Fp3/4pniA6dXuT4UxmIVa6suxM08khUBLi3MGMH0eIy694nKP8o1N6yXLYmSJ1LoOCnKDJ+32p2Sfe/aVXGVhIur0VY8koMapO6UuwnEnOEyjGcszNDPn9K1ZSlMQJ4Go3/Xqq9D4YhCeqNAqh3bN2rhfvh62+Lj8A7sONCZezqM3Yox+PPf6NCjtcVyKq6/p6ov0svwFJQHaa0WZ5gLGn01scjMVSqFTfCshAtn1tyeyBpiF+voK4wqjUui8ADg+u9eMjYKqBjzYCZxMKHkyK90KXbTb5bq5pqf1sD3rpyu/3lgMIR16Pr1sfZHSO+f4H8teZR3yQgT1JPwvNC7ofC9xrpbMq+joLODoyxe+bUULjVrkJOTcYlN++QOBd6b+0RYyF4+fk0BW01WDxHKAqxWeUxleMZZkthAZJ9xQt3pSR6EvQhWDqnA4jJRoKDp/MBQ= X-Forefront-PRVS: 098076C36C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(199003)(377454003)(189002)(24454002)(54534003)(13464003)(19580405001)(19580395003)(14496001)(42186005)(1556002)(116806002)(230783001)(23756003)(61296003)(9686002)(86362001)(575784001)(110136002)(1456003)(15975445007)(44736004)(33646002)(101416001)(50466002)(7846002)(92566002)(50226002)(77096005)(7736002)(2906002)(68736007)(106356001)(8676002)(81156014)(81166006)(84392002)(66066001)(189998001)(4326007)(62236002)(44716002)(97736004)(47776003)(105586002)(586003)(3846002)(6116002)(50986999)(81816999)(230700001)(76176999)(81686999)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB5PR07MB1622; 23:gToZ3bWugO1fp8baoc7gvoegxGouvIYiCI8dFAn?= =?iso-8859-1?Q?eSpyVqkwklFgF8qsP1XkZzSyvPlRdZ0Ug3ow5jjxjgpfCWNeNnwxiFpOEL?= =?iso-8859-1?Q?jGBO4geMqUzm0T2dny7GcXbjUbt9f+M0wUH/zsMayuf1xBZ2Git63Bi7Q2?= =?iso-8859-1?Q?SonJLJ1mjNvWdDjGXIK4zfWeS28nSUUAB0KdZRqtQjUGsqBpYTYEcbe4vZ?= =?iso-8859-1?Q?iHAL/SA35NmVA/JuTKAXMMYWFl7GJshJ6JeJ2ApNLGvTw2Jh7J4O4P+CLH?= =?iso-8859-1?Q?iYCeRQZy/vCAwD4ooDknix63VQssajmizgeZEoo7d5dxsCwyhBf5Br4gYR?= =?iso-8859-1?Q?vX1kBYikhK/Jm8TZkkucOoNytNn4zohQR8ck3KU4R5avCuD3Ct/hAjRIFo?= =?iso-8859-1?Q?QQksVcT1eFqFusNvTwV292JBRZ+QjpWe0Q+RLaoic1w5OJ+XM4B1ePBHGD?= =?iso-8859-1?Q?ILxdD0ZT2Ta9vJpejaRJWHh7bX7tIEm11DD1wud87CngnXsrUz6SEwO/LH?= =?iso-8859-1?Q?QYXONC//+39Dgg0olpyvZ/VjcugOFjcK6i3FMGOr7V4KRHTMWfGVMxq4dk?= =?iso-8859-1?Q?j/QEiFclL9OslzzWk8c5rCFBZhOAowydq77znz//Qf+MNxDQjuqadNPM3l?= =?iso-8859-1?Q?rUhf7LAQnhbZlTht3r7SIHAiV0tjjmmqTImYS79gSBeKxWF7heEMFsMXIz?= =?iso-8859-1?Q?6tgaTjWp1PEaGjl9Z6vd0VOo2virjPcL8sVf/3g44V4V730CczW3YS3ifn?= =?iso-8859-1?Q?2xi1mcbIXMQKPGM46kpCJ5IduZxd0zdDUe+acDZLW+gSeXNstneT+u2RPU?= =?iso-8859-1?Q?vaEtpde7edxT/EfSng+/7vno2Tc9encFbFUY8rrZ8OgivX2oODtKAxKIw/?= =?iso-8859-1?Q?KseFIE1hQyOzA5VhoBNeO7ae2M0c+35ggwCseQCka0fvPLpUhr89RMtKtD?= =?iso-8859-1?Q?0mXo9j/S/6KHJ8cPOgY8QgXQZEZWyCWlNqff8PCwW/Jj1mqxKvu3iFMT1g?= =?iso-8859-1?Q?o4DiXKihLOhZsoXMnK3Zlxh5EI7gm2V8thmHW0vPMO4fbv5uXy2b//lVYb?= =?iso-8859-1?Q?pKSPiztKngZNQ6plTixtbrsm/PPoE+r23jdyzmXe03gUMONAvIV55KAiBG?= =?iso-8859-1?Q?r6Svhi0/Gg4k0VjNDefF2JbrFIp9Hk0SmOqlTg27xaubTBdUQHOOPDpBOv?= =?iso-8859-1?Q?iqFKc6xOLWcj0L97oaYj75kl038Tnbdam6Y6YG5pjTdUCzL2i8JxqJS/q4?= =?iso-8859-1?Q?Gi8QHknuw4wQgkywr+lj1opRQtZpo+qlW7MZZjieTGLEBsNw3eA84pP/qi?= =?iso-8859-1?Q?XihEpnFfBZQRk4DBhnjQoRZIuXXsoQ/oJRuPT9aXoJLmDBeEGRi61lG97I?= =?iso-8859-1?Q?Olr4P1IFYxNn2E1wE/mtfZ7IOYyhWeLqtAq5hml/O0PYlKSN5VrsAIIGUJ?= =?iso-8859-1?Q?DzxtJ0+t7P601IfXi9KrrSzIx5mf9mV+RajHrk1lbP5gP807bIdSXH/xA?= =?iso-8859-1?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 6:7Un01u+N9qEl8sLUMdwJnq9XOUR6cWjaSYZids4wnrP5uAWeUFCX91VydLsIKs+bghDdw2ddepNESPFsQ6/I+TOMk+5nhyYrYGzRCuopmKUMRZpZTIZfHThKnoKdDTsHxfgqo0+/7ynu0hGF/rBzA95hQ0zJ8o6ncbjbKhLEu2lR/hC4yT/66bhCCP5NF/cYCP7H8YVssngOPbQQNw4riR0JSsj9h9eItz+654MZ1tcCACH9qHszAcq20ikJ+xFhpuQKaiZzTJZLmESrxtmanPl1EEhQcOsoAM6iRuaFSRc=; 5:Tx7mQNyuG4smfExzJEeBn1wbzNb0p77MMtc3d6FTnmMo4O+ULDbLqCmP7ze5zsUwBImIJQDOXwDtUge0lv5dVSzmJjYrIZhQoFXyDtVRYU0nn/y4TLkM8FKlqDUSLPBSyTzlnr1x2auIK7Aokcw+cA==; 24:M4Nia4uOzxQDP6MyEiGOsXedXqANQdotuhcu3uZyGLCFJ5+LYIBxS3/0QVr0zXZVa2Z3Y+35yREvjKO4e1YfgFd3rG2p4KPr1EEXYLvSE4o=; 7:p/aLZnncseG1pjmsc7x36xetkey/yokrMm0DjmI7VMJPtl9ljD7likgKdnMj9RuSxm3FiANkcWkFaQEOLmvt1U66uikMjkUp49MVeVsb8jVRDgKpqFR1BxBbxdRRBaVvyKUfPxIgq9FtJma17JI22RGyvkcSRM0FkVo8rhhR3olEjUfCB+s97i2R51CsWSZkReyVe3SOkd+kb0N4oie/TSieOLBoXmSXBnEVKzaPD1gLDuTJowVWzNvqV6TV1BA+ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 12:17:05.1702 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Protocol Action: 'The YANG 1.1 Data Modeling Language' to Proposed Standard (draft-ietf-netmod-rfc6020bis-14.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:17:26 -0000 Martin Is there any changelog available for the last four versions? The log I see stops at -10. Tom Petch ----- Original Message ----- From: "Ladislav Lhotka" To: "Andy Bierman" Cc: Sent: Monday, June 20, 2016 6:58 AM Subject: Re: [netmod] Protocol Action: 'The YANG 1.1 Data Modeling Language' to Proposed Standard (draft-ietf-netmod-rfc6020bis-14.txt) > > > On 18 Jun 2016, at 01:47, Andy Bierman wrote: > > > > > > > > On Fri, Jun 17, 2016 at 9:54 AM, The IESG wrote: > > The IESG has approved the following document: > > - 'The YANG 1.1 Data Modeling Language' > > (draft-ietf-netmod-rfc6020bis-14.txt) as Proposed Standard > > > > This document is the product of the NETCONF Data Modeling Language > > Working Group. > > > > The IESG contact persons are Benoit Claise and Joel Jaeggli. > > > > A URL of this Internet Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ > > > > > > > > > > great news! > > > > So are we ready for a YANG 1.1 Interoperability Test yet? > > Our client/server support is almost done -- I suspect some more implementations > > are in the same state. Maybe a bakeoff at IETF #97 in November? > > +1 > > Lada > > > > > > > Andy > > > > > > > > > > Technical Summary > > > > YANG is a data modeling language used to model configuration data, > > state data, remote procedure calls, and notifications for network > > management protocols like the Network Configuration Protocol > > (NETCONF). This document defines YANG version 1.1. > > > > Working Group Summary > > > > This is an update of YANG 1.0 as defined in RFC 6020. The working > > group used an issue tracker and a number of virtual interim meetings > > to discuss all bug fix proposals and feature requests. The document > > went through two WG last calls and there is broad consensus on the > > final version. > > > > Document Quality > > > > Recent versions of the open source pyang implementation support this > > specification. Additional commercial implementations are expected to > > follow soon. > > > > Personnel > > > > Juergen Schoenwaelder is the document shepherd and Benoit Claise is > > the responsible AD. > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jun 21 05:32:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E112312D0AB for ; Tue, 21 Jun 2016 05:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 QAZqD5Ba6rfA for ; Tue, 21 Jun 2016 05:32:28 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DFA5A12D0A0 for ; Tue, 21 Jun 2016 05:32:27 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id F16D11AE03EE; Tue, 21 Jun 2016 14:32:26 +0200 (CEST) Date: Tue, 21 Jun 2016 14:32:51 +0200 (CEST) Message-Id: <20160621.143251.1065923393604430909.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <019f01d1cbb6$950e8c20$4001a8c0@gateway.2wire.net> References: <9DE5B1A5-FE12-4A05-AA34-34B8136C2FDC@nic.cz> <019f01d1cbb6$950e8c20$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Protocol Action: 'The YANG 1.1 Data Modeling Language' to Proposed Standard (draft-ietf-netmod-rfc6020bis-14.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:32:33 -0000 t.petch wrote: > Martin > > Is there any changelog available for the last four versions? The log I > see stops at -10. No :( You'll have to use rfcdiff (which OTOH has the benefit that it is guearanteed to be correct :) /martin > > Tom Petch > > > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Andy Bierman" > Cc: > Sent: Monday, June 20, 2016 6:58 AM > Subject: Re: [netmod] Protocol Action: 'The YANG 1.1 Data Modeling > Language' to Proposed Standard (draft-ietf-netmod-rfc6020bis-14.txt) > > > > > > > On 18 Jun 2016, at 01:47, Andy Bierman wrote: > > > > > > > > > > > > On Fri, Jun 17, 2016 at 9:54 AM, The IESG > wrote: > > > The IESG has approved the following document: > > > - 'The YANG 1.1 Data Modeling Language' > > > (draft-ietf-netmod-rfc6020bis-14.txt) as Proposed Standard > > > > > > This document is the product of the NETCONF Data Modeling Language > > > Working Group. > > > > > > The IESG contact persons are Benoit Claise and Joel Jaeggli. > > > > > > A URL of this Internet Draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ > > > > > > > > > > > > > > > great news! > > > > > > So are we ready for a YANG 1.1 Interoperability Test yet? > > > Our client/server support is almost done -- I suspect some more > implementations > > > are in the same state. Maybe a bakeoff at IETF #97 in November? > > > > +1 > > > > Lada > > > > > > > > > > > Andy > > > > > > > > > > > > > > > Technical Summary > > > > > > YANG is a data modeling language used to model configuration data, > > > state data, remote procedure calls, and notifications for network > > > management protocols like the Network Configuration Protocol > > > (NETCONF). This document defines YANG version 1.1. > > > > > > Working Group Summary > > > > > > This is an update of YANG 1.0 as defined in RFC 6020. The working > > > group used an issue tracker and a number of virtual interim > meetings > > > to discuss all bug fix proposals and feature requests. The > document > > > went through two WG last calls and there is broad consensus on the > > > final version. > > > > > > Document Quality > > > > > > Recent versions of the open source pyang implementation support > this > > > specification. Additional commercial implementations are expected > to > > > follow soon. > > > > > > Personnel > > > > > > Juergen Schoenwaelder is the document shepherd and Benoit Claise > is > > > the responsible AD. > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Jun 21 05:45:59 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F76D12D7AE for ; Tue, 21 Jun 2016 05:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vSSts3L3qlW for ; Tue, 21 Jun 2016 05:45:56 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 E4FE512D797 for ; Tue, 21 Jun 2016 05:45:45 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id t129so18536003vka.1 for ; Tue, 21 Jun 2016 05:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=QVUVoQq6kg9Yf/Z1B4t6bu3AsAbbgN+jGaRlBXFzUXA=; b=addCxpRlD/Iw5RWR/vNao2HFe85qYUGpOhFUGyFtRqxKKxYOr+kf/qoZTNWQG2aCot fxHzTtTPikb+fs6IXwd7jzrlyuptgrBnL2n5cLhIDxTSn3iAgZ2j8eEXAidrt9Kf+/d1 PRTtpruXs0QkvbK2NhS1hoxv+u7nZMyxbEe1VlUMIRl5i3gd6CUFgJQnh2ZtLJSKw/TS ZS5f2c5SPvEpK6VUt2WSVlG6avFYNyiG7gl6yVfQO90d0Q5L9Ifw4yx5uIJSMD5i4KbZ EYXzB1FwlYTPfG8vihUlnZc1IfCXMvSNLZqVT/YbYqBCg9ZNGMvNVfvq7mzbvqnZaDm9 V7+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=QVUVoQq6kg9Yf/Z1B4t6bu3AsAbbgN+jGaRlBXFzUXA=; b=UwOJXcvnr5MlFql5ADhaJYpCzt7a9Cg8myuweYOAJk6CdYdRgOET8kthvjSCQEd38d aRNLFeLFsnAl7uCnPdu+ZpwTF3sj+2zwvTGV/X4+x/SUhCx/cNd9BHOx/lajDzZFCGu6 v5YPqQY++B78GFIuijgb6vhNHwaDeWplAl+DXWTN3Ktl4y27ohqhGwNglQXkEzLYcFk9 /YJ+pDyGKaV/7RJ5g9py6ROMxymmjrFxhwG57KCpEzlK4+Ag20r4zwAfxGgKYWPctFrf 3IZiU7crBltGg6Qlm9EAF/Eqo/kI1omjsfw0BgKk17G6jL/V5y/Byf/u+TZ5bffC11x/ PilQ== X-Gm-Message-State: ALyK8tIKANM+OedSsU5Fp3zjgZ3d6vr9PQT/owsT4JQqW6/bJ7frK98TnN/rV0jnImmJAQb4heFGDlnL5zKgzA== MIME-Version: 1.0 X-Received: by 10.31.108.216 with SMTP id j85mr9246126vki.68.1466513144997; Tue, 21 Jun 2016 05:45:44 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 05:45:44 -0700 (PDT) Date: Tue, 21 Jun 2016 05:45:44 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11478f3410fed90535c933c7 Archived-At: Subject: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:45:57 -0000 --001a11478f3410fed90535c933c7 Content-Type: text/plain; charset=UTF-8 Hi, YANG 1.1, sec. 7.8.4 says: The list's key nodes are encoded as subelements to the list's identifier element, in the same order as they are defined within the "key" statement. The rest of the list's child nodes are encoded as subelements to the list element, after the keys. Where does is say the server MUST reject list keys provided by the client that are out of order? Where does is say what error-tag is returned? thanks, Andy --001a11478f3410fed90535c933c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

YANG 1.1, sec. 7.8.4 says:

   The list's key nodes are encoded as subelements to t=
he list's
   identifier element, in the same order as they are defined within the
   "key" statement.

   The rest of the list's child nodes are encoded as subelements to the
   list element, after the keys.

Where does is say the server MUST= reject list keys provided by the client
that are out of order?=C2=A0 Wh= ere does is say what error-tag is returned?


thanks,
Andy

--001a11478f3410fed90535c933c7-- From nobody Tue Jun 21 05:49:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8297A12D80A for ; Tue, 21 Jun 2016 05:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 fUQ5TzVR1rIl for ; Tue, 21 Jun 2016 05:49:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3330712D5DB for ; Tue, 21 Jun 2016 05:49:43 -0700 (PDT) Received: from localhost (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 5DE571AE0198; Tue, 21 Jun 2016 14:49:42 +0200 (CEST) Date: Tue, 21 Jun 2016 14:50:06 +0200 (CEST) Message-Id: <20160621.145006.558079754984826704.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 12:49:50 -0000 Andy Bierman wrote: > Hi, > > YANG 1.1, sec. 7.8.4 says: > > The list's key nodes are encoded as subelements to the list's > identifier element, in the same order as they are defined within the > "key" statement. > > The rest of the list's child nodes are encoded as subelements to the > list element, after the keys. > > > Where does is say the server MUST reject list keys provided by the client > that are out of order? Nowhere. This text is unchnaged from 6020 (7.8.5). If you follow the Postel principle you would probably accept out-of-order keys. /martin From nobody Tue Jun 21 06:00:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D607128B44 for ; Tue, 21 Jun 2016 06:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL28WV5aQ9ZY for ; Tue, 21 Jun 2016 06:00:40 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 C5A6612D7B3 for ; Tue, 21 Jun 2016 06:00:39 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id j2so19000484vkg.2 for ; Tue, 21 Jun 2016 06:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yJvNdoGiBuVk/dAaGw1WvV7Cxbu9eCzjiFNNJQE9xy8=; b=qU2lhcqRIX06SgIqGnSFqh7SpiR5is9cRqmeStD4mr8sxftSWbCmh//VIdTnOAtYl8 2IBuOcCO4QqQRmGOA658mf52hPTFhU1ser41l2MqrsZVr73oHIl+mWyUHZBymOu1BQzC j4+4RLPjPp05VqUlopHFulwuSUBNCWYpaWn1UqlyU1HZa0z14J8eMGZIENXwws20aXM8 Gpyxzv+vUuWkiGUXRM5ua2t0mo5z/kp+heQXrKOKFfYvt4fPEzC5WYEhz0uuP6UDD3h9 Z+/KE4qOO1Bes3nh6ZfYfYO9hpf86f+TVxNXfKoq+uVTAxOGZaqShe+LUj5UpjP8d1m4 aGRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yJvNdoGiBuVk/dAaGw1WvV7Cxbu9eCzjiFNNJQE9xy8=; b=EewMYBUggABM2S+WEZLWejZovG2JAGJyJBbSrR2yKU4PLezC27PQT54/VJB6D3NHLo ErDX/FaZvyvKrnPtE1zd901/PZcyMt0aLom5JH5YhmX7tmg8lJp4mfeGrn0gx61kN0zi UD+IQozZ9pfjMfsJw9YJogWXGZcCx12d+9FSt4EVBiPvF/8JNauN1gSo33Ks8UKSQaJo V8qd/VMpq4l+UR8M4ADbr0ZJLEdCWgEzt4GjlxxjHLtVPvG2h7b8IIiy+3LoS5uUvPFn 7vjsezhrRnNPgXB4NtJyTT8Yp6sNEP7NljlvHi7WENCsv0+DtxbpphonWvb+00cYi5u7 WzdA== X-Gm-Message-State: ALyK8tJ2eH+A++yiyPNx7HChrPllSGeEtsh8VqUAZoi4alx8BwLOfYI5u13A0YkFwFxPBdMtia8eKM5x/w3z6w== MIME-Version: 1.0 X-Received: by 10.31.132.77 with SMTP id g74mr9827821vkd.121.1466514038934; Tue, 21 Jun 2016 06:00:38 -0700 (PDT) Received: by 10.103.20.2 with HTTP; Tue, 21 Jun 2016 06:00:38 -0700 (PDT) In-Reply-To: <20160621.145006.558079754984826704.mbj@tail-f.com> References: <20160621.145006.558079754984826704.mbj@tail-f.com> Date: Tue, 21 Jun 2016 06:00:38 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1144f9d85968cc0535c9683a Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 13:00:41 -0000 --001a1144f9d85968cc0535c9683a Content-Type: text/plain; charset=UTF-8 On Tue, Jun 21, 2016 at 5:50 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > YANG 1.1, sec. 7.8.4 says: > > > > The list's key nodes are encoded as subelements to the list's > > identifier element, in the same order as they are defined within the > > "key" statement. > > > > The rest of the list's child nodes are encoded as subelements to the > > list element, after the keys. > > > > > > Where does is say the server MUST reject list keys provided by the client > > that are out of order? > > Nowhere. This text is unchnaged from 6020 (7.8.5). If you follow the > Postel principle you would probably accept out-of-order keys. > > So some servers can reject the request and others can accept it? It would be nice if the client knew what to expect. Why is this text even in YANG 1.1 if it is not required. > /martin > > Andy --001a1144f9d85968cc0535c9683a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2016 at 5:50 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> YANG 1.1, sec. 7.8.4 says:
>
>=C2=A0 =C2=A0 The list's key nodes are encoded as subelements to th= e list's
>=C2=A0 =C2=A0 identifier element, in the same order as they are defined= within the
>=C2=A0 =C2=A0 "key" statement.
>
>=C2=A0 =C2=A0 The rest of the list's child nodes are encoded as sub= elements to the
>=C2=A0 =C2=A0 list element, after the keys.
>
>
> Where does is say the server MUST reject list keys provided by the cli= ent
> that are out of order?

Nowhere.=C2=A0 This text is unchnaged from 6020 (7.8.5).=C2=A0 If you follo= w the
Postel principle you would probably accept out-of-order keys.


So some servers can reject the request and others ca= n accept it?
It would be nice if the client knew what to expect.<= /div>
Why is this text even in YANG 1.1 if it is not required.=C2=A0


/martin


Andy<= /div>

--001a1144f9d85968cc0535c9683a-- From nobody Tue Jun 21 07:55:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E7712D7F2 for ; Tue, 21 Jun 2016 07:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 AeVYClzMU_BG for ; Tue, 21 Jun 2016 07:55:09 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 BD52C1288B8 for ; Tue, 21 Jun 2016 07:55:09 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-05v.sys.comcast.net with SMTP id FN3jbMQ0H3MWRFN52b0L4U; Tue, 21 Jun 2016 14:55:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466520908; bh=LKxY1oArQIETZGMsb7JIIlOSd/V7bZvycsnM8C24WhU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=BVtGg0Q2VS02FFAUUaERNC++DillMisXIlvB4qaFTkzL+FbmC1PG907XQa7cwlqjV oSr8exOZ4+6OFMBk9eOnYMR85ZYyp8qzPi6kMry4x1kz12RW5tVvqwA6YxALGS/7Ny j59hTrAzsK+Pe+tgxpF3v5bscBTENT8yxUNIPQTfjhrbaL+a3KjJRyElGtlDN2ZOka uRa1DmzXvGC2dEdyhrhK+WcC0kUGr8UX8wcUvXc1KMY19HIPSuhAXUGwkYg8UEr0AJ rEi5O2aWXoqHdk8mISF47jDBllIaSFoeMeb29FH3RnZ+ab5mnhth+wPSjlWTxEBmxD L0FbDGgZgxzMQ== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-08v.sys.comcast.net with comcast id 9Sv71t0091nMCLR01Sv7dt; Tue, 21 Jun 2016 14:55:08 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5LEt6ix019604; Tue, 21 Jun 2016 10:55:06 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5LEt6Ki019601; Tue, 21 Jun 2016 10:55:06 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Andy Bierman In-Reply-To: (andy@yumaworks.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 21 Jun 2016 10:55:06 -0400 Message-ID: <878txypp6d.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 14:55:12 -0000 Andy Bierman writes: > Where does is say the server MUST reject list keys provided by the client > that are out of order? Where does is say what error-tag is returned? Maybe this is due to my inexperience, but I read the text of 7.8.4, "A list is encoded ..." as "When translating an abstract data structue into XML, you encode ...". That is, these are the rules for how a server *writes* XML. What this leaves unspecified, or only implied, are the rules for *reading* XML. The correct solution, IMO, is that the text should explicitly address writing and reading seperately, or state that they are identical. (Generally, programming language specs describe input and output operations seperately.) Dale From nobody Tue Jun 21 08:24:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B077012D957 for ; Tue, 21 Jun 2016 08:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL1wWmg5e_m2 for ; Tue, 21 Jun 2016 08:24:45 -0700 (PDT) Received: from p3plsmtpa11-04.prod.phx3.secureserver.net (p3plsmtpa11-04.prod.phx3.secureserver.net [68.178.252.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB5C12D0C1 for ; Tue, 21 Jun 2016 08:24:45 -0700 (PDT) Received: from xiangliToshiba ([24.13.90.46]) by p3plsmtpa11-04.prod.phx3.secureserver.net with id 9TQj1t00E100Es801TQkgE; Tue, 21 Jun 2016 08:24:44 -0700 From: "Xiang Li" To: "'Andy Bierman'" References: <20160621.145006.558079754984826704.mbj@tail-f.com> In-Reply-To: Date: Tue, 21 Jun 2016 10:24:37 -0500 Message-ID: <006001d1cbd1$06593cd0$130bb670$@seguesoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01D1CBA7.1D844640" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHHCCgRYpQTG20P86wrRJJPvGM1IQDTD27NAUCKS4if+PL20A== Content-Language: en-us Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 15:24:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0061_01D1CBA7.1D844640 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > The list's key nodes are encoded as subelements to the list's > identifier element, in the same order as they are defined within = the > "key" statement. I read as the sentence above already implies that an out of order key is = an not ok,=20 Otherwise why bother to specify it? =20 When talking about encoding other leaf nodes, the spec says explicitly: =E2=80=9C =E2=80=A6Otherwise, the subelements are encoded in any order.=E2=80=9D =20 =20 If out of order keys is ok then what about encoding keys mixed with = other leaf nodes? =20 IMO Perhaps it is better if 6020bis can explicitly say:=20 =20 The list's key nodes must be encoded as subelements to the list's identifier element, in the same order as they are defined within the "key" statement. =20 =20 -Xiang =20 =20 =20 From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, June 21, 2016 8:01 AM To: Martin Bjorklund Cc: netmod@ietf.org Subject: Re: [netmod] list keys out of order =20 =20 =20 On Tue, Jun 21, 2016 at 5:50 AM, Martin Bjorklund > wrote: Andy Bierman > wrote: > Hi, > > YANG 1.1, sec. 7.8.4 says: > > The list's key nodes are encoded as subelements to the list's > identifier element, in the same order as they are defined within = the > "key" statement. > > The rest of the list's child nodes are encoded as subelements to = the > list element, after the keys. > > > Where does is say the server MUST reject list keys provided by the = client > that are out of order? Nowhere. This text is unchnaged from 6020 (7.8.5). If you follow the Postel principle you would probably accept out-of-order keys. =20 So some servers can reject the request and others can accept it? It would be nice if the client knew what to expect. Why is this text even in YANG 1.1 if it is not required.=20 =20 /martin =20 Andy =20 ------=_NextPart_000_0061_01D1CBA7.1D844640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

>=C2=A0=C2=A0 The list's key nodes are encoded = as subelements to the list's
>    identifier element, in = the same order as they are defined within the
>    = "key" statement.

I read as the sentence = above already implies that an out of order key is an not ok, =

Otherwise why bother to specify = it?

 

When talking about = encoding other leaf nodes, the spec says = explicitly:

=E2=80=9C =E2=80=A6Otherwise, = the

=C2=A0=C2=A0 subelements are encoded in any = order.=E2=80=9D

 

 

If =C2=A0out of order = keys is ok then what about encoding keys mixed with other leaf = nodes?

 

IMO Perhaps it is = better if 6020bis can explicitly say:

 

The list's key nodes = must be encoded as subelements to the list's

identifier element, in = the same order as they are defined within the

"key" = statement.

 

 

-Xiang

 

 

 

From:<= /b> = netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Tuesday, June 21, 2016 8:01 AM
To: = Martin Bjorklund <mbj@tail-f.com>
Cc: = netmod@ietf.org
Subject: Re: [netmod] list keys out of = order

 

 

 

On Tue, = Jun 21, 2016 at 5:50 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Andy Bierman <andy@yumaworks.com> = wrote:
> Hi,
>
> YANG 1.1, sec. 7.8.4 = says:
>
>    The list's key nodes are encoded as = subelements to the list's
>    identifier element, in = the same order as they are defined within the
>    = "key" statement.
>
>    The rest of the = list's child nodes are encoded as subelements to the
>  =   list element, after the keys.
>
>
> Where does = is say the server MUST reject list keys provided by the client
> = that are out of order?

Nowhere.  This text is unchnaged from = 6020 (7.8.5).  If you follow the
Postel principle you would = probably accept out-of-order keys.

 

So some servers can reject the request and others can = accept it?

It would be = nice if the client knew what to expect.

Why is this text even in YANG 1.1 if it is not = required. 

 


/martin

 

Andy

 

------=_NextPart_000_0061_01D1CBA7.1D844640-- From nobody Tue Jun 21 14:28:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D374F12D7FF for ; Tue, 21 Jun 2016 14:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 YyMXY20pC-HU for ; Tue, 21 Jun 2016 14:28:25 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 5FD9212D7DD for ; Tue, 21 Jun 2016 14:28:25 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 55AA8EDBEE31A; Tue, 21 Jun 2016 21:28:22 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u5LLSN4o027322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Jun 2016 21:28:24 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u5LLSKpW017674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jun 2016 21:28:23 GMT Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.174]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 21 Jun 2016 17:28:22 -0400 From: "Sterne, Jason (Nokia - CA)" To: Juergen Schoenwaelder Thread-Topic: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt Thread-Index: AQHRxxrDqcSbCbxdqk+sJ01FZToTSJ/soRcAgADZdQCAADAJwIAAb4SAgAZXLvA= Date: Tue, 21 Jun 2016 21:28:21 +0000 Message-ID: References: <20160615152932.GA31216@elstar.local> <20160617063826.GB34404@elstar.local> <20160617160929.GA35470@elstar.local> In-Reply-To: <20160617160929.GA35470@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 21:28:28 -0000 How about some of the following changes to shift the focus slightly from "S= yslog" to "configuring event logging" ? ################################### (A) Replace the introduction with the following: ################################### 1. Introduction Operating systems, processes and applications generate messages indicating their own status or the occurrence of events. These log event messages are useful for managing and/or debugging the network = and its services. =20 Since each process, application and operating system was written somewhat independently, there is limited uniformity to the content of log event messages. There is, however, some common structure to=20 log event messages and processing. The BSD Syslog protocol is a widely = adopted protocol that is used for transmission and processing of log event messages. Some of = the definitions and concepts from [RFC5424] are used in this model to creat= e a common framework for configuration of log event handling on a device. Essentially, an event logging process receives messages (from the kernel= , processes, applications or other event logging processes) and processes those. The processing involves logging to a local file, displaying on console, user terminal, and/or relaying to event logging processes on other machines. The processing is determined by the "facility" that originated the message and the "severity" assigned to the message by the facility. ################################### (B) Add the following paragraph somewhere in section "3. Design of the SYS= LOG Model" ################################### The syslog model employs the use of an extensible 'identity' for 'syslog-fa= cility' along with a pre-defined set of standard facilities based on [RFC54= 24]. The standard facilities are required when log event messages are trans= mitted from one device to another using the Syslog protocol [RFC5424] (i.e.= using the 'remote' log-action). Many vendors, however, use proprietary ext= ended facility lists to manage event logging so an extensible identity was = selected as the type for 'syslog-facility'. See Appendix A section A.1 for = an example of a vendor-specific extension of the syslog-facility identities= . ########################################## (C) Replace the definition of syslog-facility as follows ############################################ identity syslog-facility { description "This identity is used as a base for event log facilities. A standard set of facilities based on RFC 5424 is defined and it is expected that implementations may extend this list with proprietary facilities. The standard RFC 5424 facility values should be used for log events that are exchanged between devices using the Syslog protocol."; } ############################################## (D) Replace the definition of 'container remote' as follows ################################################## container remote { description "This container describes the configuration parameters for transmission of log event messages to another device using the Syslog protocol [RFC5424]."; Regards, Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, June 17, 2016 12:09 To: Sterne, Jason (Nokia - CA) Cc: netmod@ietf.org Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.t= xt Then this probably needs to be more clearly spelled out. /js On Fri, Jun 17, 2016 at 01:34:31PM +0000, Sterne, Jason (Nokia - CA) wrote: > Hi Juergen, >=20 > This model may be used in cases where no events are sent on any wire. On= ly events sent on a 'remote' log-action would need to conform to RFC5424. I= n that case there is the "destination-facility" override if needed. >=20 > But for many of the other uses of the model for just configuring logging = (and event filtering) to buffer, file, console, etc it is very useful to ha= ve the extensible facility concept. >=20 > Jason >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, June 17, 2016 2:38 > To: Sterne, Jason (Nokia - CA) > Cc: netmod@ietf.org > Subject: Re: [netmod] partial review of=20 > draft-ietf-netmod-syslog-model-08.txt >=20 > In ietf-syslog-types, there is a mapping of facility names to a limited n= umber space on the wire. Unfortunately, this mapping is not available in a = machine readable form. But for those names listed in RFC 5424, there is at = least a mapping defined in human readable form in the description clauses. = The examples given in A.1 are completely silent about which number is used = on the wire. >=20 > I think this is a problem if you consider setups where a relay is expecte= d to filter on facility values. When an originator uses facility 'vendor:fo= o', what will that facility be from the viewpoint of a relay? >=20 > /js >=20 > On Thu, Jun 16, 2016 at 09:45:06PM +0000, Sterne, Jason (Nokia - CA) wrot= e: > > Hi Juergen, > >=20 > > About the identities vs enum for 'facilities' -> I'm pretty sure it was= discussed on the list previously but I think the applicability of the mode= l is going to be much better if we allow extensible facilities. Several i= mplementations use proprietary facility names along with RFC5424 facility n= ames in a unified way to configure logging. > >=20 > > IMO this YANG model isn't exactly trying to match & reproduce RFC5424. = RFC5424 is more about the format of syslog messages on a wire. But this s= yslog YANG model is more about how devices configure logging. > >=20 > > So I'm strongly in favor of seeing the facilities stay as an identity. > >=20 > > Regards, > > Jason > >=20 > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen=20 > > Schoenwaelder > > Sent: Wednesday, June 15, 2016 11:30 > > To: netmod@ietf.org > > Subject: [netmod] partial review of=20 > > draft-ietf-netmod-syslog-model-08.txt > >=20 > > Hi, > >=20 > > Dan Romascanu encouraged me to look at this I-D as part of his efforts = to organize YANG document reviews. Since the YANG definitions are not consi= stent with the tree diagram, I have not really looked at the YANG definitio= ns yet. So the comments below are essentially about the surrounding documen= t structure, terminology, etc. > >=20 > > - Abstract: The 'which is used to convey event notification messages' > > may relate to 'the Syslog protocol' or 'a data model' and hence the > > sentence is I think potentially confusing. Perhaps simply remove the > > phrase altogether? Readers who do not know what SYSLOG is should > > stop reading here anyway. Or break the sentence into two to make the > > structure clearer. Perhaps add one more sentence describing what the > > scope of the data model is. > >=20 > > - The text uses Syslog, syslog, and SYSLOG. It is not clear what the > > difference is (if any). If there is no semantic difference, I > > suggest to pick one writing style (and 5424 seems to prefer all > > lowercase except in cases where a sentence starts etc). > >=20 > > - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 > > to 'The ietf-syslog Module' or something similar and consider > > changing the title of section 4 to "Syslog YANG Modules" since > > it contains the definitions of the modules themselves. > >=20 > > - In section 2, should 'monitor and control' be 'configure and > > monitor' in section 2? Are there actually definitions that support > > monitoring? Perhaps the scope is just configuration? Otherwise, I > > would have expected to see a bunch of basic counters (messages > > received, forwarded, dropped, the usual monitoring stuff). > >=20 > > - In section 2, s/network management agents such as NETCONF/network > > management protocols such as NETCONF/ > >=20 > > - In section 2, the phrase 'This module' is a hanging reference. There > > is no prior text talking about a module. Perhaps replace with 'The > > data model' > >=20 > > - I did not find the term 'message distributor' in RFC 5424. The > > figure first made me assume that only a console, log buffers, or log > > files are message distributors but later it was stated that relays > > and collectors (RFC 5424 defined terms) are also 'message > > distributors'. Perhaps it helps to clearly spell out terms imported > > from RFC 5424 and to clearly define any additional terms that go > > beyond what is defined in RFC 5424. > >=20 > > - Is it possible to shorten 'log-input-transports' to simply > > 'log-inputs' (en par with log-actions)? And since both containers > > are under syslog, perhaps even the 'log-' prefix is not needed and > > all we have are /syslog/inputs and /syslog/actions? (I generally > > find it useful to look at the resulting paths and whether they are > > 'engineer friendly'. > >=20 > > - I guess I have to define multiple /syslog/input/receiver in order to > > listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and > > [::]:514? This may be just find - just checking that this is the > > idea. > >=20 > > - I actually do not find the definition of log-input-transports in the > > YANG model. It seems the tree diagram is not consistent with the > > YANG model. So I can't judge what the structured-data boolean flag > > is doing or what the syslog-sign presence container would do for > > inputs. > >=20 > > - The security considerations are quite generic; I think the template > > asks for a more specific discussion. > >=20 > > - I am not sure why RFC 6020 is an informative reference and why all > > the normative references are actually normative. It might be useful > > to go over the list to make sure we get the normative / informative > > distinction right. > >=20 > > - My understanding is that RFC 5424 numbers facilities and there is a > > hard limit on the number of facilities that the protocol can > > distinguish. RFC 5424 says: > >=20 > > Facility values MUST be in the range of 0 to 23 inclusive. > >=20 > > Given this, the 'extending facilities' appendix does not make much > > sense to me. And given the fact that the number of facilities is > > fixed (which is due to the way things are encoded in RFC 5424), I am > > not even sure that using an identity instead of an enumeration is > > useful (except if we expect a future version of SYSLOG to use a very > > different encoding of facilities). I mean, to stay within the bounds > > of RFC 5424, all one can do is to add an identity that maps to an > > already allocated code point. > >=20 > > - Do not use 1.1.1.1 as an example IP address, consider using an IPv6 > > address from the IPv6 example address space. > >=20 > > - Section 4.3 should not be in Section 4 and the title 'A Syslog > > Example' is kind of misleading since the text shows NETCONF messages > > operating on the SYSLOG YANG data model. I suggest to move 4.3 to > > a new top-level section 5 "Usage Examples". Does it make sense to > > show some complete example configs for typical use cases? > >=20 > > - Before the YANG model definitions, it is a common idea to describe > > what is imported from which RFCs. For example, one of the YANG > > modules imports ietf-interfaces but there is no (normative) > > reference to the relevant RFC. See the first sentence in section 4 > > of RFC 7277 for an example how to do this. > >=20 > > - I suggest to remove the subsection title 3.1. or to change the title > > to "SYSLOG Data Model" and lifting it up to the top-level so that it > > becomes section 4. > >=20 > > As said above, I have not reviewed the YANG definitions yet since appar= ently it is not in sync with the rest of the document. But I thought I send= these comments now anyway so that they can already be taken into account. > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > >=20 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --=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 Jun 22 01:04:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3689312B047 for ; Wed, 22 Jun 2016 01:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 MzoyT5Yv2NaA for ; Wed, 22 Jun 2016 01:04:06 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD62128E19 for ; Wed, 22 Jun 2016 01:04:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EF3F9A14; Wed, 22 Jun 2016 10:04:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PuTxwhO0JiT8; Wed, 22 Jun 2016 10:03:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Jun 2016 10:03:58 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA36C20054; Wed, 22 Jun 2016 10:03:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JVhVS1lCpqTj; Wed, 22 Jun 2016 10:03:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67EA920047; Wed, 22 Jun 2016 10:03:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9033E3B2FDCB; Wed, 22 Jun 2016 10:03:52 +0200 (CEST) Date: Wed, 22 Jun 2016 10:03:52 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Nokia - CA)" Message-ID: <20160622080352.GA43589@elstar.local> Mail-Followup-To: "Sterne, Jason (Nokia - CA)" , "netmod@ietf.org" References: <20160615152932.GA31216@elstar.local> <20160617063826.GB34404@elstar.local> <20160617160929.GA35470@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: "netmod@ietf.org" Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 08:04:09 -0000 I have concerns that generally broadening the scope is the right direction. There are many event logging systems and not all of them follow the concepts used by syslog. I rather have this model specific to syslog (because this is something the IETF standardized, something we understand and it is a manageable scope). I would rather state clearly (in the appendix) that additional facilities may not work with the syslog protocol as defined in RFC 5424 and hence such facilities may only apply for local syslog-like logging functionality. /js On Tue, Jun 21, 2016 at 09:28:21PM +0000, Sterne, Jason (Nokia - CA) wrote: > How about some of the following changes to shift the focus slightly from "Syslog" to "configuring event logging" ? > > ################################### > (A) Replace the introduction with the following: > ################################### > > 1. Introduction > > Operating systems, processes and applications generate messages > indicating their own status or the occurrence of events. These > log event messages are useful for managing and/or debugging the network and its > services. > > Since each process, application and operating system was written > somewhat independently, there is limited uniformity to the content of > log event messages. There is, however, some common structure to > log event messages and processing. The BSD Syslog protocol is a widely adopted protocol that > is used for transmission and processing of log event messages. Some of the definitions and concepts from [RFC5424] are used in this model to create a common framework for configuration of log event handling on a device. > > Essentially, an event logging process receives messages (from the kernel, > processes, applications or other event logging processes) and processes > those. The processing involves logging to a local file, displaying > on console, user terminal, and/or relaying to event logging processes on > other machines. The processing is determined by the "facility" that > originated the message and the "severity" assigned to the message by > the facility. > > ################################### > (B) Add the following paragraph somewhere in section "3. Design of the SYSLOG Model" > ################################### > > The syslog model employs the use of an extensible 'identity' for 'syslog-facility' along with a pre-defined set of standard facilities based on [RFC5424]. The standard facilities are required when log event messages are transmitted from one device to another using the Syslog protocol [RFC5424] (i.e. using the 'remote' log-action). Many vendors, however, use proprietary extended facility lists to manage event logging so an extensible identity was selected as the type for 'syslog-facility'. See Appendix A section A.1 for an example of a vendor-specific extension of the syslog-facility identities. > > ########################################## > (C) Replace the definition of syslog-facility as follows > ############################################ > identity syslog-facility { > description > "This identity is used as a base for event log facilities. > A standard set of facilities based on RFC 5424 is defined > and it is expected that implementations may extend this > list with proprietary facilities. The standard > RFC 5424 facility values should be used for log events that > are exchanged between devices using the Syslog protocol."; > } > > ############################################## > (D) Replace the definition of 'container remote' as follows > ################################################## > > container remote { > description > "This container describes the configuration parameters for > transmission of log event messages to another device using > the Syslog protocol [RFC5424]."; > > > Regards, > Jason > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, June 17, 2016 12:09 > To: Sterne, Jason (Nokia - CA) > Cc: netmod@ietf.org > Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt > > Then this probably needs to be more clearly spelled out. > > /js > > On Fri, Jun 17, 2016 at 01:34:31PM +0000, Sterne, Jason (Nokia - CA) wrote: > > Hi Juergen, > > > > This model may be used in cases where no events are sent on any wire. Only events sent on a 'remote' log-action would need to conform to RFC5424. In that case there is the "destination-facility" override if needed. > > > > But for many of the other uses of the model for just configuring logging (and event filtering) to buffer, file, console, etc it is very useful to have the extensible facility concept. > > > > Jason > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, June 17, 2016 2:38 > > To: Sterne, Jason (Nokia - CA) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] partial review of > > draft-ietf-netmod-syslog-model-08.txt > > > > In ietf-syslog-types, there is a mapping of facility names to a limited number space on the wire. Unfortunately, this mapping is not available in a machine readable form. But for those names listed in RFC 5424, there is at least a mapping defined in human readable form in the description clauses. The examples given in A.1 are completely silent about which number is used on the wire. > > > > I think this is a problem if you consider setups where a relay is expected to filter on facility values. When an originator uses facility 'vendor:foo', what will that facility be from the viewpoint of a relay? > > > > /js > > > > On Thu, Jun 16, 2016 at 09:45:06PM +0000, Sterne, Jason (Nokia - CA) wrote: > > > Hi Juergen, > > > > > > About the identities vs enum for 'facilities' -> I'm pretty sure it was discussed on the list previously but I think the applicability of the model is going to be much better if we allow extensible facilities. Several implementations use proprietary facility names along with RFC5424 facility names in a unified way to configure logging. > > > > > > IMO this YANG model isn't exactly trying to match & reproduce RFC5424. RFC5424 is more about the format of syslog messages on a wire. But this syslog YANG model is more about how devices configure logging. > > > > > > So I'm strongly in favor of seeing the facilities stay as an identity. > > > > > > Regards, > > > Jason > > > > > > -----Original Message----- > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Wednesday, June 15, 2016 11:30 > > > To: netmod@ietf.org > > > Subject: [netmod] partial review of > > > draft-ietf-netmod-syslog-model-08.txt > > > > > > Hi, > > > > > > Dan Romascanu encouraged me to look at this I-D as part of his efforts to organize YANG document reviews. Since the YANG definitions are not consistent with the tree diagram, I have not really looked at the YANG definitions yet. So the comments below are essentially about the surrounding document structure, terminology, etc. > > > > > > - Abstract: The 'which is used to convey event notification messages' > > > may relate to 'the Syslog protocol' or 'a data model' and hence the > > > sentence is I think potentially confusing. Perhaps simply remove the > > > phrase altogether? Readers who do not know what SYSLOG is should > > > stop reading here anyway. Or break the sentence into two to make the > > > structure clearer. Perhaps add one more sentence describing what the > > > scope of the data model is. > > > > > > - The text uses Syslog, syslog, and SYSLOG. It is not clear what the > > > difference is (if any). If there is no semantic difference, I > > > suggest to pick one writing style (and 5424 seems to prefer all > > > lowercase except in cases where a sentence starts etc). > > > > > > - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 > > > to 'The ietf-syslog Module' or something similar and consider > > > changing the title of section 4 to "Syslog YANG Modules" since > > > it contains the definitions of the modules themselves. > > > > > > - In section 2, should 'monitor and control' be 'configure and > > > monitor' in section 2? Are there actually definitions that support > > > monitoring? Perhaps the scope is just configuration? Otherwise, I > > > would have expected to see a bunch of basic counters (messages > > > received, forwarded, dropped, the usual monitoring stuff). > > > > > > - In section 2, s/network management agents such as NETCONF/network > > > management protocols such as NETCONF/ > > > > > > - In section 2, the phrase 'This module' is a hanging reference. There > > > is no prior text talking about a module. Perhaps replace with 'The > > > data model' > > > > > > - I did not find the term 'message distributor' in RFC 5424. The > > > figure first made me assume that only a console, log buffers, or log > > > files are message distributors but later it was stated that relays > > > and collectors (RFC 5424 defined terms) are also 'message > > > distributors'. Perhaps it helps to clearly spell out terms imported > > > from RFC 5424 and to clearly define any additional terms that go > > > beyond what is defined in RFC 5424. > > > > > > - Is it possible to shorten 'log-input-transports' to simply > > > 'log-inputs' (en par with log-actions)? And since both containers > > > are under syslog, perhaps even the 'log-' prefix is not needed and > > > all we have are /syslog/inputs and /syslog/actions? (I generally > > > find it useful to look at the resulting paths and whether they are > > > 'engineer friendly'. > > > > > > - I guess I have to define multiple /syslog/input/receiver in order to > > > listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and > > > [::]:514? This may be just find - just checking that this is the > > > idea. > > > > > > - I actually do not find the definition of log-input-transports in the > > > YANG model. It seems the tree diagram is not consistent with the > > > YANG model. So I can't judge what the structured-data boolean flag > > > is doing or what the syslog-sign presence container would do for > > > inputs. > > > > > > - The security considerations are quite generic; I think the template > > > asks for a more specific discussion. > > > > > > - I am not sure why RFC 6020 is an informative reference and why all > > > the normative references are actually normative. It might be useful > > > to go over the list to make sure we get the normative / informative > > > distinction right. > > > > > > - My understanding is that RFC 5424 numbers facilities and there is a > > > hard limit on the number of facilities that the protocol can > > > distinguish. RFC 5424 says: > > > > > > Facility values MUST be in the range of 0 to 23 inclusive. > > > > > > Given this, the 'extending facilities' appendix does not make much > > > sense to me. And given the fact that the number of facilities is > > > fixed (which is due to the way things are encoded in RFC 5424), I am > > > not even sure that using an identity instead of an enumeration is > > > useful (except if we expect a future version of SYSLOG to use a very > > > different encoding of facilities). I mean, to stay within the bounds > > > of RFC 5424, all one can do is to add an identity that maps to an > > > already allocated code point. > > > > > > - Do not use 1.1.1.1 as an example IP address, consider using an IPv6 > > > address from the IPv6 example address space. > > > > > > - Section 4.3 should not be in Section 4 and the title 'A Syslog > > > Example' is kind of misleading since the text shows NETCONF messages > > > operating on the SYSLOG YANG data model. I suggest to move 4.3 to > > > a new top-level section 5 "Usage Examples". Does it make sense to > > > show some complete example configs for typical use cases? > > > > > > - Before the YANG model definitions, it is a common idea to describe > > > what is imported from which RFCs. For example, one of the YANG > > > modules imports ietf-interfaces but there is no (normative) > > > reference to the relevant RFC. See the first sentence in section 4 > > > of RFC 7277 for an example how to do this. > > > > > > - I suggest to remove the subsection title 3.1. or to change the title > > > to "SYSLOG Data Model" and lifting it up to the top-level so that it > > > becomes section 4. > > > > > > As said above, I have not reviewed the YANG definitions yet since apparently it is not in sync with the rest of the document. But I thought I send these comments now anyway so that they can already be taken into account. > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > 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 -- 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 Jun 22 04:46:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4644112D0E7 for ; Wed, 22 Jun 2016 04:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KxoxDpA9MMq for ; Wed, 22 Jun 2016 04:46:29 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7F64612D110 for ; Wed, 22 Jun 2016 04:46:28 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id BE9C51CC02C8; Wed, 22 Jun 2016 13:46:29 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20160621.145006.558079754984826704.mbj@tail-f.com> References: <20160621.145006.558079754984826704.mbj@tail-f.com> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 22 Jun 2016 13:46:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 11:46:32 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> Hi, >> >> YANG 1.1, sec. 7.8.4 says: >> >> The list's key nodes are encoded as subelements to the list's >> identifier element, in the same order as they are defined within the >> "key" statement. >> >> The rest of the list's child nodes are encoded as subelements to the >> list element, after the keys. >> >> >> Where does is say the server MUST reject list keys provided by the client >> that are out of order? > > Nowhere. This text is unchnaged from 6020 (7.8.5). If you follow the > Postel principle you would probably accept out-of-order keys. I agree. Note that in JSON encoding the order of keys isn't enforced (because it can't be). Lada > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jun 22 06:09:26 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FF0128E18; Wed, 22 Jun 2016 06:09:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160622130922.10975.63672.idtracker@ietfa.amsl.com> Date: Wed, 22 Jun 2016 06:09:22 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 13:09:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : YANG Module Classification Authors : Dean Bogdanovic Benoit Claise Carl Moberg Filename : draft-ietf-netmod-yang-model-classification-02.txt Pages : 12 Date : 2016-06-22 Abstract: The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules of configuration, state data and operations for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. A consistent terminology would help with the categorization of YANG modules, assist in the analysis the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG-related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 22 07:13:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F0012D52B for ; Wed, 22 Jun 2016 07:13:33 -0700 (PDT) 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, 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 pNmsUO8FCXeU for ; Wed, 22 Jun 2016 07:13:31 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DD312D19E for ; Wed, 22 Jun 2016 07:13:30 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-b9-576a9d0833a8 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 52.B3.18043.80D9A675; Wed, 22 Jun 2016 16:13:28 +0200 (CEST) Received: from [159.107.197.187] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.294.0; Wed, 22 Jun 2016 16:13:28 +0200 To: "Dale R. Worley" References: <87r3bxrv4w.fsf@hobgoblin.ariadne.com> From: Balazs Lengyel Message-ID: Date: Wed, 22 Jun 2016 16:13:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <87r3bxrv4w.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM2K7hC7n3Kxwg+lcFvMvNrJavDxR5sDk MXn/V2aPJUt+MgUwRXHZpKTmZJalFunbJXBltC6ZzlqwVbhi5p3prA2MN/m6GDk5JARMJB5O ns0OYYtJXLi3ng3EFhI4wihxplO5i5ELyF7LKHGiuY8ZJCEs4CGx494f1i5GDg4RAU2JjgU5 EPVGEvP/nWYEsZkFjCWevuoAs9mA4lP7z7OA2LwC9hLH3xxjArFZBFQletoWs4LYogIxEo23 D7ND1AhKnJz5BKyeE2jOsTNrwVYxA/U+2FoGMV5eYvvbOcwQazUkHl74yzqBUXAWku5ZCB2z kHQsYGRexShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYpAe3/LbawXjwueMhRgEORiUe3gc7 MsOFWBPLiitzDzFKcDArifCyzskKF+JNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEk NTs1tSC1CCbLxMEp1cCo6d/wu0WA6V59Xpnz2m03d91bUb6vV30lY+dep68vf2s+5PdxKFFl qelWPfq+jeukFJPQXsf9V3dsdAm4psssZNK43nvKedvJq113RH/8csjLLPfet8iiN2l3j19d lxpUduCP5De3d5kZKupHXFS3rLjcuaHbvO2c1HnbqYe2LHl17OJKn3JPJZbijERDLeai4kQA 7SnNr04CAAA= Archived-At: Cc: netmod@ietf.org, balazs.kovacs@ericsson.com Subject: Re: [netmod] Must on actions without input or output parameters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 14:13:33 -0000 On 2016-06-16 17:49, Dale R. Worley wrote: > Balazs Lengyel writes: >> We only want to allow starting myThing (calling the start action) if >> it is enabled. >> However we >> - can not put a must under action according to the RFC/draft >> - while the RFC would allow us to put an empty input under action with >> only the must statement in it, pyang complains about the absence of >> data definition nodes. > Reading the specification of the must statement (section 7.5.3), the > concept that must declares a *constraint*, which is evaluated at commit > time as specified in section 8. > > Reading 8.1, I see that it describes which constraints are applied at > what times. No only are they used to validate the datastore at commit > time, they also are used to validate the inputs and outputs of actions, > etc. The scope of the XPath expression in such a must is the input data > tree of the action, not the datastore. BALAZS: From 6.4.1. XPath Context "If the XPath expression is defined in a substatement to an "input" statement in an "rpc" or "action" statement, the accessible tree is the RPC or action operation instance, all state data in the server, and the running configuration datastore." So if I define a "must" in the input of an action the normal data tree IS visible. > So there is no way to specify in Yang a constraint on the datastore that > must be satisfied for an action to be valid. BALAZS: As stated above I don't think this is true > In regard to "input", it isn't said plainly in section 7.14, but the > ABNF makes clear that it must contain at least one data-def-stmt. But > if the action has no inputs, the input statement can be omitted. > > Dale BALAZS: You are correct about the ABNF. But I could still do: container myThing { leaf enabled { type boolean;} action start { input { leaf dummy-leaf-never-use-it { type empty; } // optional so I can just ignore it must "../enabled = 'true'"; } My question is why do I need to do this ugly solution? Is there a better way? Is there a reason why I really need the dummy leaf? Is there a reason why the rfc does not allow an input field with a single must statement in it? Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Jun 22 08:39:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF27512D8E3 for ; Wed, 22 Jun 2016 08:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 p7rd-4mkgEvf for ; Wed, 22 Jun 2016 08:39:32 -0700 (PDT) Received: from p3plsmtpa11-01.prod.phx3.secureserver.net (p3plsmtpa11-01.prod.phx3.secureserver.net [68.178.252.102]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F04412D73B for ; Wed, 22 Jun 2016 08:26:20 -0700 (PDT) Received: from xiangliToshiba ([24.13.90.46]) by p3plsmtpa11-01.prod.phx3.secureserver.net with id 9rSJ1t00Y100Es801rSKlR; Wed, 22 Jun 2016 08:26:20 -0700 From: "Xiang Li" To: "'Ladislav Lhotka'" , "'Martin Bjorklund'" , References: <20160621.145006.558079754984826704.mbj@tail-f.com> In-Reply-To: Date: Wed, 22 Jun 2016 10:26:11 -0500 Message-ID: <00e601d1cc9a$68c7f5e0$3a57e1a0$@seguesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHHCCgRYpQTG20P86wrRJJPvGM1IQDTD27NA1RXc5Kf6dR4IA== Content-Language: en-us Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:39:34 -0000 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav > Lhotka > Sent: Wednesday, June 22, 2016 6:47 AM > To: Martin Bjorklund ; andy@yumaworks.com > Cc: netmod@ietf.org > Subject: Re: [netmod] list keys out of order > > Martin Bjorklund writes: > > > Andy Bierman wrote: > >> Hi, > >> > >> YANG 1.1, sec. 7.8.4 says: > >> > >> The list's key nodes are encoded as subelements to the list's > >> identifier element, in the same order as they are defined within the > >> "key" statement. > >> > >> The rest of the list's child nodes are encoded as subelements to the > >> list element, after the keys. > >> > >> > >> Where does is say the server MUST reject list keys provided by the > >> client that are out of order? > > > > Nowhere. This text is unchnaged from 6020 (7.8.5). If you follow the > > Postel principle you would probably accept out-of-order keys. > > I agree. Note that in JSON encoding the order of keys isn't enforced (because > it can't be). Currently the text in spec says: ---------------------------------------------------------------------------- ----- The list's key nodes are encoded as subelements to the list's identifier element, in the same order as they are defined within the "key" statement. T e rest of the list's child nodes are encoded as subelements to the list element, after the keys. If the list defines RPC or action input or output parameters, the subelements are encoded in the same order as they are defined within the "list" statement. Otherwise, the subelements are encoded in any order. ---------------------------------------------------------------------------- ----- Clearly the texts above means the order of keys (and rpc input) is significant and required, while the order of none-key leafs is not. However, in https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06#page-8 ---------------------------------------------------------------------------- The ordering of array elements follows the same rules as the ordering of XML elements representing list entries in the XML encoding. Specifically, the "ordered-by" properties (sec. 7.7.7 in [I-D.ietf-netmod-rfc6020bis]) MUST be observed. Unlike the XML encoding, where list keys are required to precede any other siblings within a list entry, and appear in the order specified by the data model, the order of members in a JSON-encoded list entry is arbitrary because JSON objects are fundamentally unordered collections of members. ---------------------------------------------------------------------------- ----- I think this inconsistency in XML and JSON encoding is just confusing. My question is that is the order requirement of keys and RPC input parameters in XML is really needed? If not, IMO we should just remove it. -Xiang > Lada > > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jun 22 08:57:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3884612DE21 for ; Wed, 22 Jun 2016 08:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukWAIX_gK333 for ; Wed, 22 Jun 2016 08:57:26 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 D05AE12D5A3 for ; Wed, 22 Jun 2016 08:47:06 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id j2so67491689vkg.2 for ; Wed, 22 Jun 2016 08:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nMzcZBp87FtCi8xsiBJOmC9eJc88yBox0h6a1hj43Og=; b=nYXTCG40JTeqR1oTnVylRyk1/tNb8Wvw4+cTCg7HKkK8cEeafQM4I7lee2/I+oY0HU ngIWxeKvDb4wA1jN7GE+BQKhhlK1BUgxfyC/3WkgvIVemFgh76+O4G1dfp4kj1MbGlSz yzgY+0VF/Kbh3/MmoPI2BZcjj0LoXk5dRJG00/fQ6dRCnsca+SYkh5iWLiNmM2wmkWmg a3xr5q4bRoodJqN9FAk+/pz7eZP6GSBO5Cx4rDQWHnuxVzI6A8I+V9tYgFdCt1U+lK6G JN821kiic20RFWAZgSVAKBAEbPqQiTXQtlLTzTHvvcebFPcwOw2b3+ewcdSfPGDXbNKY mOzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nMzcZBp87FtCi8xsiBJOmC9eJc88yBox0h6a1hj43Og=; b=DYN1aJ0kGnF+719xYO6Y26Mc+RN8/cmL8ozSA7bjCh5at+UN3EOiFS+AFe1ZF+3o6i v3JqigbgkyV9n6nIe6PAFpVt/9Iy0HZATw5zt30CCGfV909WImja7AAkmmwC/pZbRWnv TGQvO1dM6l7McTXu+c15U+l+VYA/dZjNTO6IwE4T8f0pI0pj5x9JkJtZovAiPw8DPFjH HMWa49lFCom/GkgkjxIHjliPpyi/GnwiXNuV0w8dPicdua/cLhoHRkaGjvaoQdDvGW/s iO/IOzWim0wef2cCvYRpi9oN3P9LQwnOQ11ihQeg0bFC0bzwR81jbfpOwXnt1UIF7OlO i1qg== X-Gm-Message-State: ALyK8tI9Krpos0RlaBXZ/jEWkMqMrfKxEMP/LplV8bJdehIMrqtfTiwz1VoNfgYQSv2jElpHUP+3O9wkbEiuBw== X-Received: by 10.176.67.37 with SMTP id k34mr5959496uak.47.1466610425971; Wed, 22 Jun 2016 08:47:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Wed, 22 Jun 2016 08:47:05 -0700 (PDT) In-Reply-To: <00e601d1cc9a$68c7f5e0$3a57e1a0$@seguesoft.com> References: <20160621.145006.558079754984826704.mbj@tail-f.com> <00e601d1cc9a$68c7f5e0$3a57e1a0$@seguesoft.com> From: Andy Bierman Date: Wed, 22 Jun 2016 08:47:05 -0700 Message-ID: To: Xiang Li Content-Type: multipart/alternative; boundary=94eb2c05a69a76ddb30535dfd970 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:57:29 -0000 --94eb2c05a69a76ddb30535dfd970 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 22, 2016 at 8:26 AM, Xiang Li wrote: > > > > -----Original Message----- > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav > > Lhotka > > Sent: Wednesday, June 22, 2016 6:47 AM > > To: Martin Bjorklund ; andy@yumaworks.com > > Cc: netmod@ietf.org > > Subject: Re: [netmod] list keys out of order > > > > Martin Bjorklund writes: > > > > > Andy Bierman wrote: > > >> Hi, > > >> > > >> YANG 1.1, sec. 7.8.4 says: > > >> > > >> The list's key nodes are encoded as subelements to the list's > > >> identifier element, in the same order as they are defined within > the > > >> "key" statement. > > >> > > >> The rest of the list's child nodes are encoded as subelements to > the > > >> list element, after the keys. > > >> > > >> > > >> Where does is say the server MUST reject list keys provided by the > > >> client that are out of order? > > > > > > Nowhere. This text is unchnaged from 6020 (7.8.5). If you follow the > > > Postel principle you would probably accept out-of-order keys. > > > > I agree. Note that in JSON encoding the order of keys isn't enforced > (because > > it can't be). > > I checked our server and it accepts any node out of order, including keys, so I agree out-of-order keys SHOULD be accepted. Andy > Currently the text in spec says: > > ---------------------------------------------------------------------------- > ----- > The list's key nodes are encoded as subelements to the list's > identifier element, in the same order as they are defined within the > "key" statement. > > T e rest of the list's child nodes are encoded as subelements to the > list element, after the keys. If the list defines RPC or action > input or output parameters, the subelements are encoded in the same > order as they are defined within the "list" statement. Otherwise, > the subelements are encoded in any order. > > ---------------------------------------------------------------------------- > ----- > > Clearly the texts above means the order of keys (and rpc input) is > significant > and required, while the order of none-key leafs is not. > > However, in > https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06#page-8 > > ---------------------------------------------------------------------------- > The ordering of array elements follows the same rules as the ordering > of XML elements representing list entries in the XML encoding. > Specifically, the "ordered-by" properties (sec. 7.7.7 in > [I-D.ietf-netmod-rfc6020bis]) MUST be observed. > > Unlike the XML encoding, where list keys are required to precede any > other siblings within a list entry, and appear in the order specified > by the data model, the order of members in a JSON-encoded list entry > is arbitrary because JSON objects are fundamentally unordered > collections of members. > > > ---------------------------------------------------------------------------- > ----- > > I think this inconsistency in XML and JSON encoding is just confusing. > > My question is that is the order requirement of keys and RPC input > parameters > in XML is really needed? If not, IMO we should just remove it. > > -Xiang > > > > > Lada > > > > > > > > > > > /martin > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > --94eb2c05a69a76ddb30535dfd970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 22, 2016 at 8:26 AM, Xiang Li <xiangli@seguesoft.com> wrote:


> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav
> Lhotka
> Sent: Wednesday, June 22, 2016 6:47 AM
> To: Martin Bjorklund <mbj@tail-f.com>; andy@yumaworks.com
> Cc: netmod@ietf.o= rg
> Subject: Re: [netmod] list keys out of order
>
> Martin Bjorklund <mbj@tail-f.com> writes:
>
> > Andy Bierman <andy@yumaworks.com> wrote:
> >> Hi,
> >>
> >> YANG 1.1, sec. 7.8.4 says:
> >>
> >>=C2=A0 =C2=A0 The list's key nodes are encoded as subeleme= nts to the list's
> >>=C2=A0 =C2=A0 identifier element, in the same order as they ar= e defined within the
> >>=C2=A0 =C2=A0 "key" statement.
> >>
> >>=C2=A0 =C2=A0 The rest of the list's child nodes are encod= ed as subelements to the
> >>=C2=A0 =C2=A0 list element, after the keys.
> >>
> >>
> >> Where does is say the server MUST reject list keys provided b= y the
> >> client that are out of order?
> >
> > Nowhere.=C2=A0 This text is unchnaged from 6020 (7.8.5).=C2=A0 If= you follow the
> > Postel principle you would probably accept out-of-order keys.
>
> I agree. Note that in JSON encoding the order of keys isn't enforc= ed
(because
> it can't be).



I checked our server an= d it accepts any node out of order, including keys,
so I agree ou= t-of-order keys SHOULD be accepted.


Andy


Currently=C2=A0 the text in spec=C2=A0 says:
---------------------------------------------------------------------------= -
-----
The list's key nodes are encoded as subelements to the list's
=C2=A0 =C2=A0identifier element, in the same order as they are defined with= in the
=C2=A0 =C2=A0"key" statement.

T e rest of the list's child nodes are encoded as subelements to the =C2=A0 =C2=A0list element, after the keys.=C2=A0 If the list defines RPC or= action
=C2=A0 =C2=A0input or output parameters, the subelements are encoded in the= same
=C2=A0 =C2=A0order as they are defined within the "list" statemen= t.=C2=A0 Otherwise,
=C2=A0 =C2=A0the subelements are encoded in any order.
---------------------------------------------------------------------------= -
-----

Clearly the texts above means the order of keys (and rpc input) is
significant
and required, while the order of none-key leafs is not.

However, in
https://tools.ietf.org/html/draft-i= etf-netmod-yang-json-06#page-8
---------------------------------------------------------------------------= -
The ordering of array elements follows the same rules as the ordering
=C2=A0 =C2=A0of XML elements representing list entries in the XML encoding.=
=C2=A0 =C2=A0Specifically, the "ordered-by" properties (sec. 7.7.= 7 in
=C2=A0 =C2=A0[I-D.ietf-netmod-rfc6020bis]) MUST be observed.

=C2=A0 =C2=A0Unlike the XML encoding, where list keys are required to prece= de any
=C2=A0 =C2=A0other siblings within a list entry, and appear in the order sp= ecified
=C2=A0 =C2=A0by the data model, the order of members in a JSON-encoded list= entry
=C2=A0 =C2=A0is arbitrary because JSON objects are fundamentally unordered<= br> =C2=A0 =C2=A0collections of members.

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

I think this inconsistency in XML and JSON encoding is just confusing.

My question is that is the order requirement of keys and RPC input
parameters
=C2=A0in XML is really needed? If not, IMO we should just remove it.

-Xiang



> Lada
>
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.= org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--94eb2c05a69a76ddb30535dfd970-- From nobody Wed Jun 22 11:54:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A6712D640 for ; Wed, 22 Jun 2016 11:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=randy_presuhn@mindspring.com header.d=mindspring.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 JuLP57NOkbuv for ; Wed, 22 Jun 2016 11:54:09 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9534B12D600 for ; Wed, 22 Jun 2016 11:54:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=s3D8+WxS6HOXOmXl0eoBunOZbdIeNmJ0W9nisokEfQ+dgTn95Hy05Y9HANlGP4me; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1bFnHl-0007Cx-Ea for netmod@ietf.org; Wed, 22 Jun 2016 14:54:01 -0400 Received: from 76.254.48.21 by webmail.earthlink.net with HTTP; Wed, 22 Jun 2016 14:54:01 -0400 Message-ID: <10130465.1466621641409.JavaMail.wam@elwamui-hybrid.atl.sa.earthlink.net> Date: Wed, 22 Jun 2016 11:54:01 -0700 (GMT-07:00) From: Randy Presuhn To: "netmod@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b484d7840976cb7e8814af588e4ace14f38dfb2163954b8b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Archived-At: Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 18:54:11 -0000 Hi - > From: Andy Bierman > Sent: Jun 22, 2016 8:47 AM ... > Subject: Re: [netmod] list keys out of order ... > I checked our server and it accepts any node out of order, > including keys,so I agree out-of-order keys SHOULD be accepted. "SHOULD" isn't helpful from an interoperability perspective, since it effectively requires the sender to produce in-order keys, and gives no clue as to the circumstances under which rejecting out-of-order keys would be appropriate. If key order is irrelevant, and folks think it's helpful for senders to be able to send keys in whatever order they like, then the appropriate normative language would state that out-of-order keys *MUST* be accepted. Randy From nobody Wed Jun 22 12:01:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D530512DB2A for ; Wed, 22 Jun 2016 12:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKK-84gkAshK for ; Wed, 22 Jun 2016 12:01:27 -0700 (PDT) Received: from p3plsmtpa11-08.prod.phx3.secureserver.net (p3plsmtpa11-08.prod.phx3.secureserver.net [68.178.252.109]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB15E12D7B7 for ; Wed, 22 Jun 2016 12:01:11 -0700 (PDT) Received: from xiangliToshiba ([24.13.90.46]) by p3plsmtpa11-08.prod.phx3.secureserver.net with id 9v1A1t00E100Es801v1B7E; Wed, 22 Jun 2016 12:01:11 -0700 From: "Xiang Li" To: "'Randy Presuhn'" , References: <10130465.1466621641409.JavaMail.wam@elwamui-hybrid.atl.sa.earthlink.net> In-Reply-To: <10130465.1466621641409.JavaMail.wam@elwamui-hybrid.atl.sa.earthlink.net> Date: Wed, 22 Jun 2016 14:01:02 -0500 Message-ID: <013d01d1ccb8$6c109590$4431c0b0$@seguesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQF3kcvg9NcATuDWIn+EUY85OJmrJqCqS5qA Content-Language: en-us Archived-At: Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 19:01:29 -0000 > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy > Presuhn > Sent: Wednesday, June 22, 2016 1:54 PM > To: netmod@ietf.org > Subject: Re: [netmod] list keys out of order > > Hi - > > > From: Andy Bierman > > Sent: Jun 22, 2016 8:47 AM > ... > > Subject: Re: [netmod] list keys out of order > ... > > I checked our server and it accepts any node out of order, including > > keys,so I agree out-of-order keys SHOULD be accepted. > > "SHOULD" isn't helpful from an interoperability perspective, since it > effectively requires the sender to produce in-order keys, and gives no clue as > to the circumstances under which rejecting out-of-order keys would be > appropriate. agreed. > If key order is irrelevant, and folks think it's helpful for senders > to be able to send keys in whatever order they like, then the appropriate > normative language would state that out-of-order keys *MUST* be accepted. +1 -Xiang > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jun 22 12:38:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E8212D62A for ; Wed, 22 Jun 2016 12:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 JCaJORbc7xnW for ; Wed, 22 Jun 2016 12:38:30 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 AFCBF12D51A for ; Wed, 22 Jun 2016 12:38:30 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-01v.sys.comcast.net with SMTP id FnvFbN6UU13YVFnynbWUI8; Wed, 22 Jun 2016 19:38:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466624309; bh=Oq7FyOaLf8HY+5mGm42s0r5kG7KYcbDFPGMCARa/wDw=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=jp0nFlHjO/qwELkDIFo7X/+z7g2m3v3OVJkQSIzHdxuAKHeOLXcksnE5q8Lv1fTRE 3fKJti3ZW35e/Krzo1ShxXdVSSNWRYlccGL/a4UqxqTyFYVYm/F3a5NZdoRGao4xAx R9vNiYGo3gDZTcFwfxgjeBX0bxSG9OZw0WVp6NAWRPP34iibLFUszTFK+NSnl0SvhA fjejcoESbBN7AXhTI2e/cNyRWGiGK9D93An85g0gQmekiY0uFxcjx1Oa21SQmIxBkK qAmOaAgtDV0mtyICFfiKKj9z6IqKhvf2OhhcvHFj1xVqM424nXx7ehLLx9OlF7if1b jUPYa2tKmivLw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id 9veU1t00P1nMCLR01veVyQ; Wed, 22 Jun 2016 19:38:29 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5MJcSEW031705; Wed, 22 Jun 2016 15:38:28 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5MJcRNu031702; Wed, 22 Jun 2016 15:38:27 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Balazs Lengyel In-Reply-To: (balazs.lengyel@ericsson.com) Summary: Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 22 Jun 2016 15:38:27 -0400 Message-ID: <87eg7pnhe4.fsf@hobgoblin.ariadne.com> Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Must on actions without input or output parameters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 19:38:33 -0000 Balazs Lengyel writes: [edited] > container myThing { > leaf enabled { type boolean;} > action start { > input { > // optional so I can just ignore it > leaf dummy-leaf-never-use-it { type empty; } > must "../enabled = 'true'"; > } > > My question is why do I need to do this ugly solution? Is there a better > way? > Is there a reason why I really need the dummy leaf? > Is there a reason why the rfc does not allow an input field with a > single must statement in it? I suspect that is because nobody envisioned that an input statement with only a 'must' could be useful. You've provided a counterexample to that idea. Dale From nobody Wed Jun 22 13:00:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EE412D625 for ; Wed, 22 Jun 2016 13:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 jdRR8S2n0_1s for ; Wed, 22 Jun 2016 13:00:02 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (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 3F23512D1A2 for ; Wed, 22 Jun 2016 13:00:02 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-12v.sys.comcast.net with SMTP id FoIcbfCfvGpVBFoJdbhV9D; Wed, 22 Jun 2016 20:00:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1466625601; bh=49Q+zCx4PHhhiAaV7MEGVcrlolHCVl++LBnmg25E+Mg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=H3P8ix7zqBtduREoz82TF58CUNHbVZPf+HoTIsllTerjvXCcXOtH2UxIbcfu5i81P aVXyo8zM9UMbfbAdkmMihINCU+/PJgHcWRX347agAGURR5sYAgOin2vRFBiAVWeykg 7DwArOdlYUEa6LHq/Vk1o9inbk5aYOMce6dYymvmzxBaEJs9jknWjyLHFQV51gj/3/ BwNQ59yslrSWftonUXtvWJNkxi5xouOV0Fgk1VmJq5REnQm34LZCZwXkKijCvHbUg2 6c8XSujEP+XWVb//GS8EaEw5NKAK7KZu1sD1wqO4JZjN6U7ITx4bGwhDIIMT8lhKZU AhiBulHm2CZ6w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-12v.sys.comcast.net with comcast id 9w001t00Z1nMCLR01w01s5; Wed, 22 Jun 2016 20:00:01 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5MK00KB001453 for ; Wed, 22 Jun 2016 16:00:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5MJxxbN001449; Wed, 22 Jun 2016 15:59:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org In-Reply-To: (balazs.lengyel@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 22 Jun 2016 15:59:59 -0400 Message-ID: <87a8idnge8.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [netmod] Must on actions without input or output parameters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 20:00:08 -0000 Balazs Lengyel writes: > BALAZS: From 6.4.1. XPath Context > "If the XPath expression is defined in a substatement to an "input" > statement in an "rpc" or "action" statement, the accessible tree > is the RPC or action operation instance, all state data in the > server, and the running configuration datastore." > > So if I define a "must" in the input of an action the normal data tree > IS visible. Interesting... I'm not sure, but I think that the spec may omit something: 6.4.1: o If the XPath expression is defined in a substatement to an "input" statement in an "rpc" or "action" statement, the accessible tree is the RPC or action operation instance, all state data in the server, and the running configuration datastore. The root node has top-level data nodes in all modules as children. Additionally, for an RPC, the root node also has the node representing the RPC operation being defined as a child. The node representing the operation being defined has the operation's input parameters as children. 6.4.1.1: Given the following module: module example-a { yang-version 1.1; namespace urn:example:a; prefix a; container a { list b { key id; leaf id { type string; } notification down { leaf reason { type string; } } action reset { input { leaf delay { type uint32; } } output { leaf result { type string; } } } } } [...] } The accessible tree for an action invocation of "reset" on /a/ b[id="1"] with the "when" parameter set to "10" would be: 1 10 2 // possibly other top-level nodes here I don't see where the insertion of the action node (the "reset") into the datastore tree is specified for XPath evaluation. (7.15 describes how the combined XML is encoded for the request and response, and 6.4.1 describes the combined tree for input nodes for RPCs.) Dale From nobody Wed Jun 22 15:27:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A1612DAE1; Wed, 22 Jun 2016 15:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb9WdE54cwe1; Wed, 22 Jun 2016 15:27:47 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 D7FFC12DD08; Wed, 22 Jun 2016 15:18:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.122.226; Date: Wed, 22 Jun 2016 18:18:07 -0400 Message-ID: Importance: normal From: Susan Hares To: Juergen Schoenwaelder , Andy Bierman MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_179441927726590" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netmod-chairs@ietf.org, netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 22:27:49 -0000 ----_com.samsung.android.email_179441927726590 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QW5keSBhbmQgSnVlcmdlbjoKVGhlIEkyUlMgZGF0YSBtb2RlbHMgaGF2ZSBjb25zdHJhaW50cyBv biBpbnN0YWxsaW5nIHJvdXRlcyAoSTJSUyByaWIpLCBmaWx0ZXJzIChpMnJzIGZiLXJpYiksIGFu ZCB0b3BvbG9neSB0ZXJtaW5hdGlvbiBwb2ludHMgdGhhdCBkZXBlbmQgb24gdGhlIGV4aXN0ZW5j ZSBvZiBpbnRlcmZhY2VzLiDCoEl0IHdvdWxkIGJlIGhlbHBmdWwgdG8ga25vdyB0aGF0IHRoZXJl IGlzIGFncmVlbWVudCBvciBkaXNhZ3JlZW1lbnQgb24gSnVlcmdlbidzIGFuc3dlci4KVGhhbmsg eW91LApTdWUKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJlQgNEcg TFRFIHNtYXJ0cGhvbmUtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTogSnVl cmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+ IERhdGU6IDYvMTcvMjAxNiAgMzoxOSBQTSAgKEdNVC0wNTowMCkgVG86IEFuZHkgQmllcm1hbiA8 YW5keUB5dW1hd29ya3MuY29tPiBDYzogbmV0bW9kLWNoYWlyc0BpZXRmLm9yZywgbmV0bW9kIFdH IDxuZXRtb2RAaWV0Zi5vcmc+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBPcHN0YXRlIHNvbHV0aW9u cyBkaXNjdXNzaW9uczogdXBkYXRlIGFuZCByZXF1ZXN0IGZvcgogIFdHaW5wdXQgCk9uIEZyaSwg SnVuIDE3LCAyMDE2IGF0IDExOjMzOjM4QU0gLTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZToKPiAK PiBJTU8gdGhpcyBoYXMgYWx3YXlzIGJlZW4gYSBwcm90b2NvbCBpc3N1ZS4KPiBUaGUgc3RhdGUg b2YgdGhlIGRhdGEgZGVwZW5kcyBvbiB0aGUgaW50ZXJhY3Rpb24gbW9kZWwgYW5kIHRoYXQgZGVw ZW5kcyBvbgo+IHRoZSBwcm90b2NvbC4KPiBFLmcuLCBob3cgZG9lcyBjb25maXJtZWQtY29tbWl0 IGZhY3RvciBpbnRvIHRoZSBzdGF0ZSBtYWNoaW5lPwo+IFRoZSBjb25maWcgbWF5IGJlIGFwcGxp ZWQgYnV0IGFsc28gdGVtcG9yYXJ5LCBwZW5kaW5nIGNvbmZpcm1hdGlvbi4KPiAKPiBXaGF0IGlm IGEgWUFORyBwcm90b2NvbCBtYW5kYXRlZCB0aGF0IDxvaz4gbWVhbnMgYXBwbGllZCwgbm90IGp1 c3QgaW50ZW5kZWQ/Cj4gVGhhdCBpbnRlcmFjdGlvbiBtb2RlbCB3b3VsZCBub3QgbmVlZCBzZXBh cmF0ZSBkYXRhc3RvcmVzIGZvciBpbnRlbmRlZCB2cy4KPiBhcHBsaWVkLgo+IChPbmUgc29sdXRp b24gYXBwcm9hY2ggaXMgdG8gdXBkYXRlIE5FVENPTkYgdG8gcHJvdmlkZSB0aGlzIGludGVyYWN0 aW9uCj4gbW9kZWwuKQo+CgpZb3UgY2FuIGhhdmUgY29uZmlndXJhdGlvbiBmb3IgYW4gaW50ZXJm YWNlIGluIDxydW5uaW5nPiB0aGF0IGRvZXMgbm90CmdldCBhcHBsaWVkIGJlY2F1c2UgdGhlIGlu dGVyZmFjZSBpcyBjdXJyZW50bHkgbm90IHByZXNlbnQuIEkgZG8gbm90CnRoaW5rIHRoYXQgdGhp cyBpcyBhIHByb3RvY29sIHNlbWFudGljcyBpc3N1ZS4KCi9qcwoKLS0gCkp1ZXJnZW4gU2Nob2Vu d2FlbGRlcsKgwqDCoMKgwqDCoMKgwqDCoMKgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SApQaG9uZTogKzQ5IDQyMSAyMDAgMzU4N8KgwqDCoMKgwqDCoMKgwqAgQ2FtcHVzIFJpbmcgMSB8 IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkKRmF4OsKgwqAgKzQ5IDQyMSAyMDAgMzEwM8KgwqDCoMKg wqDCoMKgwqAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPgoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApu ZXRtb2RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QK ----_com.samsung.android.email_179441927726590 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkFuZHkgYW5kIEp1ZXJnZW46 PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgSTJSUyBkYXRhIG1vZGVscyBoYXZlIGNvbnN0 cmFpbnRzIG9uIGluc3RhbGxpbmcgcm91dGVzIChJMlJTIHJpYiksIGZpbHRlcnMgKGkycnMgZmIt cmliKSwgYW5kIHRvcG9sb2d5IHRlcm1pbmF0aW9uIHBvaW50cyB0aGF0IGRlcGVuZCBvbiB0aGUg ZXhpc3RlbmNlIG9mIGludGVyZmFjZXMuICZuYnNwO0l0IHdvdWxkIGJlIGhlbHBmdWwgdG8ga25v dyB0aGF0IHRoZXJlIGlzIGFncmVlbWVudCBvciBkaXNhZ3JlZW1lbnQgb24gSnVlcmdlbidzIGFu c3dlci48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rIHlvdSw8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PlN1ZTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXpl Ojg1JTtjb2xvcjojNTc1NzU3Ij5TZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFu IEFUJmFtcDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1z aXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0t LS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBKdWVyZ2VuIFNj aG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsg PC9kaXY+PGRpdj5EYXRlOiA2LzE3LzIwMTYgIDM6MTkgUE0gIChHTVQtMDU6MDApIDwvZGl2Pjxk aXY+VG86IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OyA8L2Rpdj48ZGl2 PkNjOiBuZXRtb2QtY2hhaXJzQGlldGYub3JnLCBuZXRtb2QgV0cgJmx0O25ldG1vZEBpZXRmLm9y ZyZndDsgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogW25ldG1vZF0gT3BzdGF0ZSBzb2x1dGlvbnMg ZGlzY3Vzc2lvbnM6IHVwZGF0ZSBhbmQgcmVxdWVzdCBmb3IKICBXR2lucHV0IDwvZGl2PjxkaXY+ PGJyPjwvZGl2PjwvZGl2Pk9uIEZyaSwgSnVuIDE3LCAyMDE2IGF0IDExOjMzOjM4QU0gLTA3MDAs IEFuZHkgQmllcm1hbiB3cm90ZTo8YnI+Jmd0OyA8YnI+Jmd0OyBJTU8gdGhpcyBoYXMgYWx3YXlz IGJlZW4gYSBwcm90b2NvbCBpc3N1ZS48YnI+Jmd0OyBUaGUgc3RhdGUgb2YgdGhlIGRhdGEgZGVw ZW5kcyBvbiB0aGUgaW50ZXJhY3Rpb24gbW9kZWwgYW5kIHRoYXQgZGVwZW5kcyBvbjxicj4mZ3Q7 IHRoZSBwcm90b2NvbC48YnI+Jmd0OyBFLmcuLCBob3cgZG9lcyBjb25maXJtZWQtY29tbWl0IGZh Y3RvciBpbnRvIHRoZSBzdGF0ZSBtYWNoaW5lPzxicj4mZ3Q7IFRoZSBjb25maWcgbWF5IGJlIGFw cGxpZWQgYnV0IGFsc28gdGVtcG9yYXJ5LCBwZW5kaW5nIGNvbmZpcm1hdGlvbi48YnI+Jmd0OyA8 YnI+Jmd0OyBXaGF0IGlmIGEgWUFORyBwcm90b2NvbCBtYW5kYXRlZCB0aGF0ICZsdDtvayZndDsg bWVhbnMgYXBwbGllZCwgbm90IGp1c3QgaW50ZW5kZWQ/PGJyPiZndDsgVGhhdCBpbnRlcmFjdGlv biBtb2RlbCB3b3VsZCBub3QgbmVlZCBzZXBhcmF0ZSBkYXRhc3RvcmVzIGZvciBpbnRlbmRlZCB2 cy48YnI+Jmd0OyBhcHBsaWVkLjxicj4mZ3Q7IChPbmUgc29sdXRpb24gYXBwcm9hY2ggaXMgdG8g dXBkYXRlIE5FVENPTkYgdG8gcHJvdmlkZSB0aGlzIGludGVyYWN0aW9uPGJyPiZndDsgbW9kZWwu KTxicj4mZ3Q7PGJyPjxicj5Zb3UgY2FuIGhhdmUgY29uZmlndXJhdGlvbiBmb3IgYW4gaW50ZXJm YWNlIGluICZsdDtydW5uaW5nJmd0OyB0aGF0IGRvZXMgbm90PGJyPmdldCBhcHBsaWVkIGJlY2F1 c2UgdGhlIGludGVyZmFjZSBpcyBjdXJyZW50bHkgbm90IHByZXNlbnQuIEkgZG8gbm90PGJyPnRo aW5rIHRoYXQgdGhpcyBpcyBhIHByb3RvY29sIHNlbWFudGljcyBpc3N1ZS48YnI+PGJyPi9qczxi cj48YnI+LS0gPGJyPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0eSBC cmVtZW4gZ0dtYkg8YnI+UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1l biB8IEdlcm1hbnk8YnI+RmF4OiZuYnNwOyZuYnNwOyArNDkgNDIxIDIwMCAzMTAzJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtodHRwOi8vd3d3Lmph Y29icy11bml2ZXJzaXR5LmRlLyZndDs8YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+bmV0bW9kQGll dGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPGJy PjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_179441927726590-- From nobody Wed Jun 22 15:29:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C73012DD07 for ; Wed, 22 Jun 2016 15:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x63NTGZ8RJ9U for ; Wed, 22 Jun 2016 15:29:27 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::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 680E712DD50 for ; Wed, 22 Jun 2016 15:29:26 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id u64so81714266vkf.3 for ; Wed, 22 Jun 2016 15:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tHqlR21vZq+6fXNBtLe0/jMx4EgGgeUzmx+5/Ig6XTc=; b=q7vG8seNmmizA80Mf8ZM0+qflaDh+KyepvcnOqHOBKA12y8SgGcR+pfoU/ifcFCdGi AEZ0sCe8qZ2h+OzQTjDK0wddp88JdvMVlZx4mxskIeii9MV5ZuAtWAV/8c5oru6Ic5eS /TLpPtVzgGtm5wsK/5Ko1LYtMZgKOCafBKlHKWJbralnYS/hRwRX3Wm8SG06bjAtTlnx fv1U4qGW6/VgV7W3DmKize3wjQreIr7pytDtIR5CX1errg7VTiDf/8mc4NB817i6fNtj l1ciN+DguOcn5IqtmT1NFjHF70oBj/QxFSlQXIwRcQet7vcW6cOLOCynUMoMYlMn0RS1 Vh/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tHqlR21vZq+6fXNBtLe0/jMx4EgGgeUzmx+5/Ig6XTc=; b=Fjp174gS+u4ThfItJEuxP/g0nZKCkYbwNtPVsIoS9K7FmYvg3T0ZqK8bq8GptXaKEv fM/HS8iQkgUu/2/gxWRrxxbbnTi1pyLgS08xhidUj3MdY6RiUgIHPHy3kM51DIjo9eFJ aZ7mnJFlhZQr1gZvG2z4HCNBbMKCEOAeuOrLs+nwtJ49l9MTk1woqtpwOR2ZJIjFNm4I ju/aZ2Vt904g3B+Fsk4eRAaVffA9cw1GRCADf0rPHE5vkZZykrQBMEt8sByWtKi+6I7r FCDw221Ycss+cvhPlnd7072qPDIN9v1df+tZIDaTPlGmmbKt1p2FOfI58M5lt+/5g2A2 +LYw== X-Gm-Message-State: ALyK8tJ2ujpXyiSIaheYBcBybLy0rc6m2BT0JSmzosu1cjPyBhA7EzUpYKwNn10iuy5C8xsR6PUuPLYVCDXF2A== X-Received: by 10.176.67.37 with SMTP id k34mr7054987uak.47.1466634565445; Wed, 22 Jun 2016 15:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Wed, 22 Jun 2016 15:29:24 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Wed, 22 Jun 2016 15:29:24 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=94eb2c05a69a4a03700535e5781b Archived-At: Cc: netmod-chairs@ietf.org, netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 22:29:30 -0000 --94eb2c05a69a4a03700535e5781b Content-Type: text/plain; charset=UTF-8 On Wed, Jun 22, 2016 at 3:18 PM, Susan Hares wrote: > Andy and Juergen: > > The I2RS data models have constraints on installing routes (I2RS rib), > filters (i2rs fb-rib), and topology termination points that depend on the > existence of interfaces. It would be helpful to know that there is > agreement or disagreement on Juergen's answer. > > Thank you, > > I don't know what issues need to be resolved. The NETCONF iietf-interfaces module allows interfaces to be configured that are not enabled or present. IMO this is unrelated to the content=all query parameter, which just filters retrieval nodes based on the config-stmt. Sue > > > Andy > > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone > -------- Original message -------- > From: Juergen Schoenwaelder > Date: 6/17/2016 3:19 PM (GMT-05:00) > To: Andy Bierman > Cc: netmod-chairs@ietf.org, netmod WG > Subject: Re: [netmod] Opstate solutions discussions: update and request > for WGinput > > On Fri, Jun 17, 2016 at 11:33:38AM -0700, Andy Bierman wrote: > > > > IMO this has always been a protocol issue. > > The state of the data depends on the interaction model and that depends > on > > the protocol. > > E.g., how does confirmed-commit factor into the state machine? > > The config may be applied but also temporary, pending confirmation. > > > > What if a YANG protocol mandated that means applied, not just > intended? > > That interaction model would not need separate datastores for intended > vs. > > applied. > > (One solution approach is to update NETCONF to provide this interaction > > model.) > > > > You can have configuration for an interface in that does not > get applied because the interface is currently not present. I do not > think that this is a protocol semantics issue. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --94eb2c05a69a4a03700535e5781b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 22, 2016 at 3:18 PM, Susan Hares <shares@ndzh.com> wrote:
Andy and Juergen:

The I2RS data models have constraints on installing= routes (I2RS rib), filters (i2rs fb-rib), and topology termination points = that depend on the existence of interfaces.=C2=A0 It would be helpful to kn= ow that there is agreement or disagreement on Juergen's answer.

Thank you,

I don't know what issues need to be resolved.
Th= e NETCONF iietf-interfaces module allows
interfaces to be configu= red that are not enabled or present.

IMO this is u= nrelated to the content=3Dall query parameter, which just filters retrieval= nodes
based on the config-stmt.


Sue




An= dy
=C2=A0

Sent via the Sa= msung Galaxy Note5, an AT&T 4G LTE smartphone
-------- Original message --------
=
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
= Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput

On Fri, Jun 17, 2016 at 11:33:38AM -07= 00, Andy Bierman wrote:
>
> IMO this has always been a protoco= l issue.
> The state of the data depends on the interaction model and= that depends on
> the protocol.
> E.g., how does confirmed-com= mit factor into the state machine?
> The config may be applied but al= so temporary, pending confirmation.
>
> What if a YANG protoco= l mandated that <ok> means applied, not just intended?
> That i= nteraction model would not need separate datastores for intended vs.
>= ; applied.
> (One solution approach is to update NETCONF to provide t= his interaction
> model.)
>

You can have configuration f= or an interface in <running> that does not
get applied because the= interface is currently not present. I do not
think that this is a proto= col semantics issue.

/js

--
Juergen Schoenwaelder=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Jacobs University Bremen gGmbH
Phone: +49 421 2= 00 3587=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Campus Ring 1 | 287= 59 Bremen | Germany
Fax:=C2=A0=C2=A0 +49 421 200 3103=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <http://www.jacobs-university.de/>

____= ___________________________________________
netmod mailing list
netmod@ietf.org
http= s://www.ietf.org/mailman/listinfo/netmod

--94eb2c05a69a4a03700535e5781b-- From nobody Wed Jun 22 23:40:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A86812DF23 for ; Wed, 22 Jun 2016 23:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 f4rIVagAsr5Y for ; Wed, 22 Jun 2016 23:40:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F7112DF14 for ; Wed, 22 Jun 2016 23:40:36 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:143b:70f2:6c:b1a9] (unknown [IPv6:2001:718:1a02:1:143b:70f2:6c:b1a9]) by mail.nic.cz (Postfix) with ESMTPSA id 264C2600CF; Thu, 23 Jun 2016 08:40:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1466664034; bh=GtQYO8WPGi+PHegGh3EbEHOuoUCN9T1iOpEcWDbkTuo=; h=From:Date:To; b=TYDF0sYTbSrD1TGtj9gCDRALzfdv4gfVmtLOg5eMNc8QxVrJYXLT/24jecxjnXmb9 6FztZaiq0zvEaaq2sXPrgD4ZA5qRnqxcFiJzLv2AKbr08CxKC7EzqC3govg4f+KOQJ rCfSt3p4y/zfQ94k229bECYMzCUp7lbUWGSDI+sc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <10130465.1466621641409.JavaMail.wam@elwamui-hybrid.atl.sa.earthlink.net> Date: Thu, 23 Jun 2016 08:40:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10130465.1466621641409.JavaMail.wam@elwamui-hybrid.atl.sa.earthlink.net> To: Randy Presuhn X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] list keys out of order X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 06:40:39 -0000 > On 22 Jun 2016, at 20:54, Randy Presuhn = wrote: >=20 > Hi - >=20 >> From: Andy Bierman >> Sent: Jun 22, 2016 8:47 AM > ... >> Subject: Re: [netmod] list keys out of order > ... >> I checked our server and it accepts any node out of order, >> including keys,so I agree out-of-order keys SHOULD be accepted. >=20 > "SHOULD" isn't helpful from an interoperability perspective, > since it effectively requires the sender to produce in-order > keys, and gives no clue as to the circumstances under which > rejecting out-of-order keys would be appropriate. If key > order is irrelevant, and folks think it's helpful for senders > to be able to send keys in whatever order they like, then the > appropriate normative language would state that out-of-order > keys *MUST* be accepted. Then IMO the text about key order can be dumped altogether. Lada >=20 > Randy >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jun 23 01:00:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3314712D12B for ; Thu, 23 Jun 2016 01:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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=-1.426] 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 E7GHZPzD-adV for ; Thu, 23 Jun 2016 01:00:26 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) by ietfa.amsl.com (Postfix) with ESMTP id D494D12D0DD for ; Thu, 23 Jun 2016 01:00:25 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 999) id DBB6C6018B; Thu, 23 Jun 2016 10:00:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1466668823; bh=d2/DC+sB5ez4bXJAJUgHjbFiN9RocH0I3azg8v3aqy0=; h=to:date:subject:from; b=moRL6HkTjXmOKlSBwQWjcmmjNymFul1n3ssTAuTW/exBz0ttN4n04/x4v23YCX7/5 ta3jH3wGWX2R8ZZMDcCtV/aSnnuoBkCF+AgHP+OofLhMwJE/cBjjH+6/NewDx8n86g tVztTLzppT5AoA0IJQZgpSXE0BFlzQmwTmXSnmH4= content-type: text/plain; charset="utf-8" to: netmod@ietf.org User-Agent: SOGoMail 2.3.12 MIME-Version: 1.0 date: Thu, 23 Jun 2016 10:00:23 +0200 message-id: <3bae-576b9700-13-61500e0@96249122> X-Forward: 2001:67c:1220:80c:2424:9396:cfa4:691b from: =?utf-8?q?Michal_Va=C5=A1ko?= content-transfer-encoding: quoted-printable Archived-At: Subject: [netmod] ietf-ipfix-psamp module invalid pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 08:00:29 -0000 Hi, I noticed that the module ietf-ipfix-psamp from the RFC 6728 contains w= hat is to my understanding an invalid string. This tring represents the= pattern for typedefs ieNameType and nameType, they both include "\S" i= n double-quoted string, which according to RFC 6020 section 6.1.3 shoul= d be "\\S". What is interesting is that on netconf central [1] these patterns are e= nclosed in single-quotes ('), which makes them valid. However, the revi= sion of that module is the same as the one from the RFC 6728, so they s= hould not differ. Also, pyang loads the invalid module without problem.= Nevertheless, when asked to print it in YANG, it encodes the patterns = properly, using "\\" for the backslashes. I would personally welcome an additional sentence in RFC 6020 section 6= .1.3 about how backslash with any character following other than n,t,",= and \ is an invalid character sequence in a string, it is not directly= implied. Still, I believe the pattern is invalid, since "\S" cannot be= interpreted as "\S" because that string is encoded in YANG as "\\S". Regards, Michal Vasko [1] http://www.netconfcentral.org/modulereport/ietf-ipfix-psamp From nobody Thu Jun 23 01:56:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E8A12DF90 for ; Thu, 23 Jun 2016 01:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 px-bslLkDpMD for ; Thu, 23 Jun 2016 01:56:30 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432B212DF85 for ; Thu, 23 Jun 2016 01:55:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7EF7EF1; Thu, 23 Jun 2016 10:55:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hILDMsfw5FAs; Thu, 23 Jun 2016 10:55:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 23 Jun 2016 10:55:52 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7513420058; Thu, 23 Jun 2016 10:55:52 +0200 (CEST) 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 6_FwPEmahuBD; Thu, 23 Jun 2016 10:55:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B644420047; Thu, 23 Jun 2016 10:55:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EAC073B31D8C; Thu, 23 Jun 2016 10:55:50 +0200 (CEST) Date: Thu, 23 Jun 2016 10:55:50 +0200 From: Juergen Schoenwaelder To: Michal =?utf-8?B?VmHFoWtv?= Message-ID: <20160623085550.GA45670@elstar.local> Mail-Followup-To: Michal =?utf-8?B?VmHFoWtv?= , netmod@ietf.org References: <3bae-576b9700-13-61500e0@96249122> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <3bae-576b9700-13-61500e0@96249122> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] ietf-ipfix-psamp module invalid pattern X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 08:56:37 -0000 On Thu, Jun 23, 2016 at 10:00:23AM +0200, Michal Vaško wrote: > > I would personally welcome an additional sentence in RFC 6020 section 6.1.3 about how backslash with any character following other than n,t,", and \ is an invalid character sequence in a string, it is not directly implied. Still, I believe the pattern is invalid, since "\S" cannot be interpreted as "\S" because that string is encoded in YANG as "\\S". > Please check out section 6.1.3 of draft-ietf-netmod-rfc6020bis-14.txt [1]. https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ I believe we have clarified this in YANG 1.1. It might be useful to post an errata for RFC 6728 to enclose the affected pattern into single quoted strings instead of double quoted strings. /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 Jun 23 04:50:35 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76F512B076 for ; Thu, 23 Jun 2016 04:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5C_3wsrcfan for ; Thu, 23 Jun 2016 04:50:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 091C312B044 for ; Thu, 23 Jun 2016 04:50:27 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 157481CC02C8; Thu, 23 Jun 2016 13:50:27 +0200 (CEST) From: Ladislav Lhotka To: "Dale R. Worley" , netmod@ietf.org In-Reply-To: <87a8idnge8.fsf@hobgoblin.ariadne.com> References: <87a8idnge8.fsf@hobgoblin.ariadne.com> User-Agent: Notmuch/0.22 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 23 Jun 2016 13:50:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Must on actions without input or output parameters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 11:50:33 -0000 "Dale R. Worley" writes: > Balazs Lengyel writes: >> BALAZS: From 6.4.1. XPath Context >> "If the XPath expression is defined in a substatement to an "input" >> statement in an "rpc" or "action" statement, the accessible tree >> is the RPC or action operation instance, all state data in the >> server, and the running configuration datastore." >> >> So if I define a "must" in the input of an action the normal data tree >> IS visible. > > Interesting... > > I'm not sure, but I think that the spec may omit something: > > 6.4.1: > > o If the XPath expression is defined in a substatement to an "input" > statement in an "rpc" or "action" statement, the accessible tree > is the RPC or action operation instance, all state data in the > server, and the running configuration datastore. The root node > has top-level data nodes in all modules as children. > Additionally, for an RPC, the root node also has the node > representing the RPC operation being defined as a child. The node > representing the operation being defined has the operation's input > parameters as children. > > 6.4.1.1: > > Given the following module: > > module example-a { > yang-version 1.1; > namespace urn:example:a; > prefix a; > > container a { > list b { > key id; > leaf id { > type string; > } > notification down { > leaf reason { > type string; > } > } > action reset { > input { > leaf delay { > type uint32; > } > } > output { > leaf result { > type string; > } > } > } > } > } > [...] > } > > The accessible tree for an action invocation of "reset" on /a/ > b[id="1"] with the "when" parameter set to "10" would be: > > > > 1 > > 10 > > > > 2 > > > // possibly other top-level nodes here > > I don't see where the insertion of the action node (the "reset") into > the datastore tree is specified for XPath evaluation. (7.15 describes It probably isn't. A further complication is that an action instance itself contains a "branch" of a normal data tree, so properly defining the accessible tree becomes quite tricky. Lada > how the combined XML is encoded for the request and response, and 6.4.1 > describes the combined tree for input nodes for RPCs.) > > Dale > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jun 24 08:19:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B80012DB74 for ; Fri, 24 Jun 2016 08:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 gXi-S35sYZTc for ; Fri, 24 Jun 2016 08:19:15 -0700 (PDT) Received: from umail.netcracker.com (umail.netcracker.com [84.47.142.180]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD2F12DB67 for ; Fri, 24 Jun 2016 08:18:58 -0700 (PDT) From: Dmytro Gassanov To: "netmod@ietf.org" Thread-Topic: ACL YANG Data Model and Thread-Index: AdHOKa5i+BrqSXM/QwS0Q2w9V9nUnA== Date: Fri, 24 Jun 2016 15:18:54 +0000 Message-ID: <758B725BE006CD4CBCAA07E695A749E57D0BC2A9@umaildb3.netcracker.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_758B725BE006CD4CBCAA07E695A749E57D0BC2A9umaildb3netcrac_" MIME-Version: 1.0 X-KSE-ServerInfo: mailgwrus.netcracker.com, 9 X-KSE-AntiSpam-Interceptor-Info: internally-submitted e-mail X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean, bases: 24.06.2016 10:24:00 X-KSE-Attachment-Filter-Scan-Result: Clean Archived-At: Subject: [netmod] ACL YANG Data Model and X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 15:19:17 -0000 --_000_758B725BE006CD4CBCAA07E695A749E57D0BC2A9umaildb3netcrac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Everybody, I read the latest revision of "Network Access Control List (ACL) YANG Data = Model" and paid attention to +--rw matches leaf. As far as I understood, currently it does not have matches regarding: * Type of application * TOS - IP Precedence (RFC 791) * COS - 802.1q * Time (time based ACL) What do you think, is it make sense to add these attributes to the leaf? Thank you. Best regards, Dmytro Gassanov, Netcracker Technology +380 44 238-8727 | ext. 6825 | office +380 67 441-5834 | mobile We are Netcracker, and we are focused forward ________________________________ The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons= or entities other than the intended recipient is prohibited. If you receiv= ed this in error, please contact the sender and delete the material from an= y computer. --_000_758B725BE006CD4CBCAA07E695A749E57D0BC2A9umaildb3netcrac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Everybody,

 

I read the latest revision of “Network Access = Control List (ACL) YANG Data Model” and paid attention to +--rw m= atches leaf.

 

As far as I understood, currently it does not have m= atches regarding:

·         Type of application

·         TOS - IP Precedence (RFC 791)

·         COS - 802.1q

·         Time (time based ACL)

 

What do you think, is it make sense to add these att= ributes to the leaf?

 

Thank you.

 

Best regards,

 

Dmytro Gassanov,
+380 44 238-8727 | ext. 6825 | office
+380 67 441-5834 | mobile<= br>
We are Netcracker, and we are focused forward

 

=  

=

The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons or entities other than the inte= nded recipient is prohibited. If you received this in error, please contact= the sender and delete the material from any computer.  

--_000_758B725BE006CD4CBCAA07E695A749E57D0BC2A9umaildb3netcrac_-- From nobody Fri Jun 24 08:31:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEB812DB81 for ; Fri, 24 Jun 2016 08:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm1dFOLhfP_s for ; Fri, 24 Jun 2016 08:31:50 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 4541712DB92 for ; Fri, 24 Jun 2016 08:31:23 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id s63so98364281ioi.3 for ; Fri, 24 Jun 2016 08:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=fiyGfDiT6AM5vETb/gQRex8L9Sf4FjefmWPFiTcaork=; b=XR5IqTdyn0jw8bSlb/DBYlX1LmUPBVkqDsORbkN2YLwRXqSSn8Ej5mYYPfvcqmGEeh Fh9Tk/+2Dbq9PJJsHoBBgNqwE2BiCEhtGZVTfszs/QxQc0hMB9WPBDEbNS8LqdDJh0oe 6KOUoeVhwiONfRRM5HYS5qoXt2V0+rsJNBJlyZDChftvY3oihdwIXzyYaOMVFgNXngsl GulCei5FcpGoVg9qdrUnS5abA6FIRn+xhZnlKLGj4Krg9c82OIqJ3RA2mk9zX/AJkitm vBbMs9ql+GMYaikuQgpw5sPyyaJ2s//Uh7k1SSo6CNtZhUoBhpCZ4RGPU01Xex0HtiR4 6NpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=fiyGfDiT6AM5vETb/gQRex8L9Sf4FjefmWPFiTcaork=; b=nHeZQH3NFVTdQZT0Q0KMOIfljTI5b6blNPgR/kIb4ZggPNpa+sSlh72fDWejzf6y5N CdjY15qKUftylYWDOJqHPx/YATeomiYJeygMKE6a45++jU0nQhF1z0CXu8WJ1Kk51OvE ImMnb7NsMkf8UasFdhW53GpRWViUb+ISkmlbH0CCMtmzmdPRdElZt9AQE0xg0c4oNEtz 1dfkLmAVW+j13dXpxZRpU/iBiLXUhmKa7VVxZoyNTRlLli+/aRkP8dgUJCh3FhWmL1mR 35/Ty885pYP453mi2hrRFzcck0ff19DQqSYIhTaS4JoWJwflsGNj1SmkwT0Z5eo6y48Z Un0g== X-Gm-Message-State: ALyK8tKM277TfLcyso/86gB/ZvUZS+dWvwzAgGx+XEKVDl0BMuDLFVlG9z0mIKdGQaZaKA== X-Received: by 10.107.164.211 with SMTP id d80mr6289282ioj.130.1466782282489; Fri, 24 Jun 2016 08:31:22 -0700 (PDT) Received: from [192.168.128.73] ([192.64.64.178]) by smtp.gmail.com with ESMTPSA id o133sm1770522itg.5.2016.06.24.08.31.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 24 Jun 2016 08:31:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A3F84C42-9BA9-4070-9DAC-C8DA4CAB773E" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <758B725BE006CD4CBCAA07E695A749E57D0BC2A9@umaildb3.netcracker.com> Date: Fri, 24 Jun 2016 11:31:20 -0400 Message-Id: References: <758B725BE006CD4CBCAA07E695A749E57D0BC2A9@umaildb3.netcracker.com> To: Dmytro Gassanov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] ACL YANG Data Model and X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 15:31:55 -0000 --Apple-Mail=_A3F84C42-9BA9-4070-9DAC-C8DA4CAB773E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dmytro, We had those discussions and as those are not widely supported, we = decided not to add it to the base model. The point is that additional = match conditions are easily added via augmentation. An example is shown = in module efxample-newco-acl Dean > On Jun 24, 2016, at 11:18 AM, Dmytro Gassanov = wrote: >=20 > Hello Everybody, > =20 > I read the latest revision of =E2=80=9CNetwork Access Control List = (ACL) YANG Data Model=E2=80=9D and paid attention to +--rw matches leaf. > =20 > As far as I understood, currently it does not have matches regarding: > =C2=B7 Type of application > =C2=B7 TOS - IP Precedence (RFC 791) > =C2=B7 COS - 802.1q=20 > =C2=B7 Time (time based ACL) > =20 > What do you think, is it make sense to add these attributes to the = leaf? > =20 > Thank you. > =20 > Best regards, > =20 > Dmytro Gassanov,=20 > Netcracker Technology=20 >=20 > +380 44 238-8727 | ext. 6825 | office > +380 67 441-5834 | mobile >=20 > We are Netcracker, and we are focused forward > =20 > =20 >=20 >=20 > The information transmitted herein is intended only for the person or = entity to which it is addressed and may contain confidential, = proprietary and/or privileged material. Any review, retransmission, = dissemination or other use of, or taking of any action in reliance upon, = this information by persons or entities other than the intended = recipient is prohibited. If you received this in error, please contact = the sender and delete the material from any computer. =20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_A3F84C42-9BA9-4070-9DAC-C8DA4CAB773E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dmytro,

We = had those discussions and as those are not widely supported, we decided = not to add it to the base model. The point is that additional match = conditions are easily added via augmentation. An example is shown in = module efxample-newco-acl

Dean

On = Jun 24, 2016, at 11:18 AM, Dmytro Gassanov <dmytro.gassanov@NetCracker.com> wrote:

Hello Everybody,
 
I read = the latest revision of =E2=80=9CNetwork Access Control List (ACL) YANG = Data Model=E2=80=9D and paid attention to +--rw matches leaf.
 
As far as = I understood, currently it does not have matches regarding:
=C2=B7         Type = of application
=C2=B7         TOS - = IP Precedence (RFC 791)
=C2=B7         COS - = 802.1q 
=C2=B7         Time = (time based ACL)
 
What do you think, is it make sense to add these attributes = to the leaf?
 
Thank you.
 
Best = regards,
 
Dmytro = Gassanov, 
Netcracker Technology 

+380 44 = 238-8727 | ext. 6825 | office
+380 67 = 441-5834 | mobile

We are = Netcracker, and we are focused forward
 
 


The information = transmitted herein is intended only for the person or entity to which it = is addressed and may contain confidential, proprietary and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon, this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from any computer.  


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

= --Apple-Mail=_A3F84C42-9BA9-4070-9DAC-C8DA4CAB773E-- From nobody Fri Jun 24 08:39:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADA412DBEE for ; Fri, 24 Jun 2016 08:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 hy5q9u9CD_OA for ; Fri, 24 Jun 2016 08:39:19 -0700 (PDT) Received: from umail.netcracker.com (umail.netcracker.com [84.47.142.180]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6D312DBD6 for ; Fri, 24 Jun 2016 08:38:53 -0700 (PDT) From: Dmytro Gassanov To: "netmod@ietf.org" Thread-Topic: NETMOD SYSLOG YANG Model / additional attributes Thread-Index: AdHOLEYlg6CJLt1JSTGYCjKeAaDPBQ== Date: Fri, 24 Jun 2016 15:38:50 +0000 Message-ID: <758B725BE006CD4CBCAA07E695A749E57D0BC2E3@umaildb3.netcracker.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_758B725BE006CD4CBCAA07E695A749E57D0BC2E3umaildb3netcrac_" MIME-Version: 1.0 X-KSE-ServerInfo: mailgwrus.netcracker.com, 9 X-KSE-AntiSpam-Interceptor-Info: internally-submitted e-mail X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean, bases: 24.06.2016 10:24:00 X-KSE-Attachment-Filter-Scan-Result: Clean Archived-At: Cc: Andrew Veitch Subject: [netmod] NETMOD SYSLOG YANG Model / additional attributes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 15:39:21 -0000 --_000_758B725BE006CD4CBCAA07E695A749E57D0BC2E3umaildb3netcrac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Everybody, I also read the latest revision of "SYSLOG YANG Model" and did not found at= tributes regarding "Timestamp format" and "Sequence number". >From my understanding these attributes are important. What do you think about adding these attributes? Thank you. Best regards, Dmytro Gassanov, Netcracker Technology +380 44 238-8727 | ext. 6825 | office +380 67 441-5834 | mobile We are Netcracker, and we are focused forward ________________________________ The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons= or entities other than the intended recipient is prohibited. If you receiv= ed this in error, please contact the sender and delete the material from an= y computer. --_000_758B725BE006CD4CBCAA07E695A749E57D0BC2E3umaildb3netcrac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Everybody,

 

I also read the latest revision of “SYSLOG YAN= G Model” and did not found attributes regarding “Timestamp form= at” and “Sequence number”.

 

From my understanding these attributes are important= .

 

What do you think about adding these attributes?

 

Thank you.

 

Best regards,

 

Dmytro Gassanov,
+380 44 238-8727 | ext. 6825 | office
+380 67 441-5834 | mobile<= br>
We are Netcracker, and we are focused forward

 

=  

=

The information transmitted herein is intended only for the person or entit= y to which it is addressed and may contain confidential, proprietary and/or= privileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by persons or entities other than the inte= nded recipient is prohibited. If you received this in error, please contact= the sender and delete the material from any computer.  

--_000_758B725BE006CD4CBCAA07E695A749E57D0BC2E3umaildb3netcrac_-- From nobody Fri Jun 24 09:02:48 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD1712DC74; Fri, 24 Jun 2016 09:00:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160041.10933.93380.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:41 -0700 Archived-At: Cc: netmod@ietf.org Subject: [netmod] netmod - Requested sessions have been scheduled for IETF 96 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:42 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netmod Session 1 (2:00:00) Tuesday, Afternoon Session II 1620-1820 Room Name: Tiergarten size: 110 --------------------------------------------- netmod Session 2 (2:00:00) Monday, Afternoon Session II 1540-1740 Room Name: Schoeneberg size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: NETCONF Data Modeling Language Area Name: Operations and Management Area Session Requester: Lou Berger Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: netconf rtgwg Second Priority: i2rs anima Third Priority: saag Special Requests: --------------------------------------------------------- From nobody Sat Jun 25 13:23:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C4912D0B2 for ; Sat, 25 Jun 2016 13:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 fCEkUDqR1HPV for ; Sat, 25 Jun 2016 13:23:45 -0700 (PDT) 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 49B0212B039 for ; Sat, 25 Jun 2016 13:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1064; q=dns/txt; s=iport; t=1466886225; x=1468095825; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=/5QCEmqW8/RMV23D92q4DG9pw1NdnHEqhIN3HGN4bBk=; b=KMGXOR2L9UYdpUrGlOZXgY/8f+++17NTzrcMwilx4xO0Of228o++hGlj enc2tsrWuPXVqwcjR5OfBJ4XZJ7fcJPcHECdOcDgexG1I2RRFXFLtCtL4 58KXds9BKwnVVHkkYk4/ukGpekeNe5wNSKU5OJbUNfWtVbHVo0xMyJpJV Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgDC525X/49dJa1cgz5WK1K6KoF7F?= =?us-ascii?q?wuFLEoCgSI4FAEBAQEBAQFlJ4RNAQEDAQEBASAPAQU2EAsLGgImAgInMAYBDAY?= =?us-ascii?q?CAQGIJAgOtxGQEAEBAQEBAQEBAQEBAQEBAQEBARoFgQGFJ4F3CIJOh0GCWgWOb?= =?us-ascii?q?4oSjjeBaYRUgwuFXI9/HjaEEBwyiU4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,528,1459814400"; d="scan'208";a="122595683" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jun 2016 20:23:44 +0000 Received: from [10.82.209.11] (rtp-vpn4-267.cisco.com [10.82.209.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u5PKNhsj014775; Sat, 25 Jun 2016 20:23:44 GMT To: NETMOD Working Group , Juergen Schoenwaelder References: <5552F457.2040002@cisco.com> From: Benoit Claise Message-ID: Date: Sat, 25 Jun 2016 13:23:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5552F457.2040002@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Next NETMOD chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 20:23:47 -0000 Dear all, As discussed with Jürgen Schönwälder some time ago, Jürgen decided to remain a NETMOD chair until YANG 1.1 was done. That milestone is now reached: the document is in the RFC-editor queue. Today, again in coordination with Jürgen, I took the necessary admin action to officially release him of his chair position. We should all be grateful to Jürgen for his years of service as NETMOD chair. Regards, Benoit > Dear all, > > As you probably know from a previous message to the list, Jürgen > announced his plans to step down as co-chair. > Please welcome Kent Watsen, who has accepted to serve as NETMOD co-chair. > As agreed with Jürgen, the NETMOD WG will run with three chairs until > the YANG 1.1 work is completed. > That important YANG 1.1 milestone is the point in time Jürgen decided > to pass the baton. > > Thanks to Kent and Jürgen. > > Regards, Benoit > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sat Jun 25 13:45:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDA212D122 for ; Sat, 25 Jun 2016 13:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 Fd_XNWDg35Tm for ; Sat, 25 Jun 2016 13:45:26 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379C912B05B for ; Sat, 25 Jun 2016 13:45:25 -0700 (PDT) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id B8lN1t0023vXPcr018lPLX; Sat, 25 Jun 2016 22:45:24 +0200 To: Benoit Claise , NETMOD Working Group , Juergen Schoenwaelder References: <5552F457.2040002@cisco.com> From: "Bert Wijnen (IETF)" Message-ID: <7f5e1bc7-4d1e-e642-6606-a7015710a078@bwijnen.net> Date: Sat, 25 Jun 2016 22:45:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] Next NETMOD chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 20:45:28 -0000 Thanks Juergen. Bert On 25/06/16 22:23, Benoit Claise wrote: > Dear all, > > As discussed with Jürgen Schönwälder some time ago, Jürgen decided to remain a NETMOD chair until YANG 1.1 was done. That milestone > is now reached: the document is in the RFC-editor queue. > Today, again in coordination with Jürgen, I took the necessary admin action to officially release him of his chair position. > > We should all be grateful to Jürgen for his years of service as NETMOD chair. > > Regards, Benoit > >> Dear all, >> >> As you probably know from a previous message to the list, Jürgen announced his plans to step down as co-chair. >> Please welcome Kent Watsen, who has accepted to serve as NETMOD co-chair. >> As agreed with Jürgen, the NETMOD WG will run with three chairs until the YANG 1.1 work is completed. >> That important YANG 1.1 milestone is the point in time Jürgen decided to pass the baton. >> >> Thanks to Kent and Jürgen. >> >> Regards, Benoit >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sat Jun 25 13:52:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1035512B05B for ; Sat, 25 Jun 2016 13:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEoCMZSkyI1O for ; Sat, 25 Jun 2016 13:52:20 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0094.outbound.protection.outlook.com [104.47.2.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50CF412D08F for ; Sat, 25 Jun 2016 13:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sq4syqaWCK9A4Zvx0jPXF6dVhCj0rh84lxflyhXxELY=; b=MCH1lfmihv021efFoLd9J3oU5nKNBVNqD/vyqT23gYECy3vmxYwKRoLghVWOXAHtoC+NM3G/0Opk+yHi6wqk5LmEtrUCMc2JWxEw1ENCEMOALnMRbZQsDkxbboAlOlyP4tdulwX8EqRRYuITSGzAP0KykUCKGMSz+0Pgf9aPN+Q= Received: from AMXPR07MB215.eurprd07.prod.outlook.com (10.242.73.17) by AMXPR07MB213.eurprd07.prod.outlook.com (10.242.73.11) with Microsoft SMTP Server (TLS) id 15.1.523.12; Sat, 25 Jun 2016 20:52:17 +0000 Received: from AMXPR07MB215.eurprd07.prod.outlook.com ([169.254.11.152]) by AMXPR07MB215.eurprd07.prod.outlook.com ([169.254.11.152]) with mapi id 15.01.0523.015; Sat, 25 Jun 2016 20:52:17 +0000 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "Bert Wijnen (IETF)" , Benoit Claise , NETMOD Working Group , "Juergen Schoenwaelder" Thread-Topic: [netmod] Next NETMOD chair Thread-Index: AQHRzyKGzjsetjFNzEqE8G7E7nT0Zp/6qJcw Date: Sat, 25 Jun 2016 20:52:17 +0000 Message-ID: References: <5552F457.2040002@cisco.com> <7f5e1bc7-4d1e-e642-6606-a7015710a078@bwijnen.net> In-Reply-To: <7f5e1bc7-4d1e-e642-6606-a7015710a078@bwijnen.net> 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=mehmet.ersue@nokia.com; x-originating-ip: [217.251.27.151] x-ms-office365-filtering-correlation-id: d0ead8f3-78d7-4760-69f9-08d39d3a9859 x-microsoft-exchange-diagnostics: 1; AMXPR07MB213; 6:VAnitF8FLmtRZIQXSFGDMWWnH4HxS0xypuqmVSFKjnJhDAjwro/VifCJwWQc5HMsulGzdT78dCyp1RiQpE3haXY2zBtBGDD8hKS7uesAiUEYlOqRZ0R++DESy85YI/bbMRXoQXziAz6dH9ZVMRPScMct9YwkNPANdYQCN3WaBp6UBo2bacl97mdiEPmj+Kl7jd/DqrFDnZoOQA4ahflnpiiZbelBy48w+dcsEWKy+7wLxg+A94JgkbxMfd5O1l1xbQSgFDPFu7OJn9g9oj88UG/R8qyBhlZ8HJX/rELdd3K3WGYp4VD3DyBTbTbJDZAw; 5:00/ykb530+NgATeDWMjiFeBXwUw5kVzSnk4W/f6+etF/D/Hh4Ul0uxNOpY99hM2ASvtMc0OoeuAbGVXr0afX+dPwh8+OlABqpew79404Ya87VZ6G4SBTeIBH62zfrQV/v5WNb9cGy0RS9zt74ChIKw==; 24:hsK3NHTtg0n9F2N7fRtId+xO4xGz9psNY5HxPziO21nhOqBh6sUJQceSs3ozHVQfC9GlvGNnBbEwNr/363bi3OCep8jrDauCQik0PfMbXEY=; 7:7xLDaSrwUxz/ML36dggkSb5yqOBqf5UF3KjVTN/+X2hYP232bnZAfCNe3ao6s2s+Ttts9prra0Dc7+CB7bVYbybEktQn4mwe99rxYYxxJ/Xoa8m0YlyeVjzQ9kvFJ3yo7ec88sitaVcaoNkzxMoapyknyDfgfWS8jrsMwznpu3C7urJBBTxhf737lKF85snD4NXPu845Nda7AnSTCh6whHG0WO012BYK1qJSqicgDCK9QtY7R+wHzZNpQGFyL0JNsXhaR0+zYd+6N9M6vWfsdA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB213; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMXPR07MB213; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB213; x-forefront-prvs: 09840A4839 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(13464003)(50986999)(122556002)(9686002)(86362001)(7696003)(107886002)(76176999)(33656002)(54356999)(8936002)(189998001)(5001770100001)(76576001)(7736002)(11100500001)(105586002)(19580405001)(92566002)(106356001)(74316001)(106116001)(19580395003)(87936001)(5002640100001)(2900100001)(66066001)(15975445007)(8676002)(68736007)(97736004)(3280700002)(2906002)(81156014)(81166006)(586003)(101416001)(6116002)(3846002)(3660700001)(5003600100003)(2950100001)(7846002)(305945005)(102836003)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB213; H:AMXPR07MB215.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2016 20:52:17.7182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB213 Archived-At: Subject: Re: [netmod] Next NETMOD chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 20:52:23 -0000 KzENCg0KTWVobWV0IA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9k IFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJ0IFdpam5l biAoSUVURikNClNlbnQ6IFNhdHVyZGF5LCBKdW5lIDI1LCAyMDE2IDEwOjQ1IFBNDQpUbzogQmVu b2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+OyBORVRNT0QgV29ya2luZyBHcm91cCA8bmV0 bW9kQGlldGYub3JnPjsgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGU+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gTmV4dCBORVRNT0QgY2hh aXINCg0KVGhhbmtzIEp1ZXJnZW4uDQoNCkJlcnQNCg0KT24gMjUvMDYvMTYgMjI6MjMsIEJlbm9p dCBDbGFpc2Ugd3JvdGU6DQo+IERlYXIgYWxsLA0KPg0KPiBBcyBkaXNjdXNzZWQgd2l0aCBKw7xy Z2VuIFNjaMO2bnfDpGxkZXIgc29tZSB0aW1lIGFnbywgSsO8cmdlbiBkZWNpZGVkIHRvIHJlbWFp biBhIE5FVE1PRCBjaGFpciB1bnRpbCBZQU5HIDEuMSB3YXMgZG9uZS4gVGhhdCBtaWxlc3RvbmUN Cj4gaXMgbm93IHJlYWNoZWQ6IHRoZSBkb2N1bWVudCBpcyBpbiB0aGUgUkZDLWVkaXRvciBxdWV1 ZS4NCj4gVG9kYXksIGFnYWluIGluIGNvb3JkaW5hdGlvbiB3aXRoIErDvHJnZW4sIEkgdG9vayB0 aGUgbmVjZXNzYXJ5IGFkbWluIGFjdGlvbiB0byBvZmZpY2lhbGx5IHJlbGVhc2UgaGltIG9mIGhp cyBjaGFpciBwb3NpdGlvbi4NCj4NCj4gV2Ugc2hvdWxkIGFsbCBiZSBncmF0ZWZ1bCB0byBKw7xy Z2VuIGZvciBoaXMgeWVhcnMgb2Ygc2VydmljZSBhcyBORVRNT0QgY2hhaXIuDQo+DQo+IFJlZ2Fy ZHMsIEJlbm9pdA0KPg0KPj4gRGVhciBhbGwsDQo+Pg0KPj4gQXMgeW91IHByb2JhYmx5IGtub3cg ZnJvbSBhIHByZXZpb3VzIG1lc3NhZ2UgdG8gdGhlIGxpc3QsIErDvHJnZW4gYW5ub3VuY2VkIGhp cyBwbGFucyB0byBzdGVwIGRvd24gYXMgY28tY2hhaXIuDQo+PiBQbGVhc2Ugd2VsY29tZSBLZW50 IFdhdHNlbiwgd2hvIGhhcyBhY2NlcHRlZCB0byBzZXJ2ZSBhcyBORVRNT0QgY28tY2hhaXIuDQo+ PiBBcyBhZ3JlZWQgd2l0aCBKw7xyZ2VuLCB0aGUgTkVUTU9EIFdHIHdpbGwgcnVuIHdpdGggdGhy ZWUgY2hhaXJzIHVudGlsIHRoZSBZQU5HIDEuMSB3b3JrIGlzIGNvbXBsZXRlZC4NCj4+IFRoYXQg aW1wb3J0YW50IFlBTkcgMS4xIG1pbGVzdG9uZSBpcyB0aGUgcG9pbnQgaW4gdGltZSBKw7xyZ2Vu IGRlY2lkZWQgdG8gcGFzcyB0aGUgYmF0b24uDQo+Pg0KPj4gVGhhbmtzIHRvIEtlbnQgYW5kIErD vHJnZW4uDQo+Pg0KPj4gUmVnYXJkcywgQmVub2l0DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+ IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5l dG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCg== From nobody Sat Jun 25 16:46:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223AD12B03E for ; Sat, 25 Jun 2016 16:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzWqOn-VzImf for ; Sat, 25 Jun 2016 16:46:40 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0AB5212B007 for ; Sat, 25 Jun 2016 16:46:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.57.184; Date: Sat, 25 Jun 2016 18:46:27 -0500 Message-ID: Importance: normal From: Susan Hares To: Benoit Claise , NETMOD Working Group , Juergen Schoenwaelder MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_759013836644560" X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] Next NETMOD chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2016 23:46:42 -0000 ----_com.samsung.android.email_759013836644560 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SnVlcmdlbgpUaGFuayB5b3UgZm9yIGFsbCB5b3VyIGhhcmQgd29yayBvbiB5YW5nIDEuMS4KU3Vl CgoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZUIDRHIExURSBzbWFy dHBob25lLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IEJlbm9pdCBDbGFp c2UgPGJjbGFpc2VAY2lzY28uY29tPiBEYXRlOiA2LzI1LzIwMTYgIDM6MjMgUE0gIChHTVQtMDY6 MDApIFRvOiBORVRNT0QgV29ya2luZyBHcm91cCA8bmV0bW9kQGlldGYub3JnPiwgSnVlcmdlbiBT Y2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IFN1Ympl Y3Q6IFJlOiBbbmV0bW9kXSBOZXh0IE5FVE1PRCBjaGFpciAKRGVhciBhbGwsCgpBcyBkaXNjdXNz ZWQgd2l0aCBKw7xyZ2VuIFNjaMO2bnfDpGxkZXIgc29tZSB0aW1lIGFnbywgSsO8cmdlbiBkZWNp ZGVkIHRvIApyZW1haW4gYSBORVRNT0QgY2hhaXIgdW50aWwgWUFORyAxLjEgd2FzIGRvbmUuIFRo YXQgbWlsZXN0b25lIGlzIG5vdyAKcmVhY2hlZDogdGhlIGRvY3VtZW50IGlzIGluIHRoZSBSRkMt ZWRpdG9yIHF1ZXVlLgpUb2RheSwgYWdhaW4gaW4gY29vcmRpbmF0aW9uIHdpdGggSsO8cmdlbiwg SSB0b29rIHRoZSBuZWNlc3NhcnkgYWRtaW4gCmFjdGlvbiB0byBvZmZpY2lhbGx5IHJlbGVhc2Ug aGltIG9mIGhpcyBjaGFpciBwb3NpdGlvbi4KCldlIHNob3VsZCBhbGwgYmUgZ3JhdGVmdWwgdG8g SsO8cmdlbiBmb3IgaGlzIHllYXJzIG9mIHNlcnZpY2UgYXMgTkVUTU9EIApjaGFpci4KClJlZ2Fy ZHMsIEJlbm9pdAoKPiBEZWFyIGFsbCwKPgo+IEFzIHlvdSBwcm9iYWJseSBrbm93IGZyb20gYSBw cmV2aW91cyBtZXNzYWdlIHRvIHRoZSBsaXN0LCBKw7xyZ2VuIAo+IGFubm91bmNlZCBoaXMgcGxh bnMgdG8gc3RlcCBkb3duIGFzIGNvLWNoYWlyLgo+IFBsZWFzZSB3ZWxjb21lIEtlbnQgV2F0c2Vu LCB3aG8gaGFzIGFjY2VwdGVkIHRvIHNlcnZlIGFzIE5FVE1PRCBjby1jaGFpci4KPiBBcyBhZ3Jl ZWQgd2l0aCBKw7xyZ2VuLCB0aGUgTkVUTU9EIFdHIHdpbGwgcnVuIHdpdGggdGhyZWUgY2hhaXJz IHVudGlsIAo+IHRoZSBZQU5HIDEuMSB3b3JrIGlzIGNvbXBsZXRlZC4KPiBUaGF0IGltcG9ydGFu dCBZQU5HIDEuMSBtaWxlc3RvbmUgaXMgdGhlIHBvaW50IGluIHRpbWUgSsO8cmdlbiBkZWNpZGVk IAo+IHRvIHBhc3MgdGhlIGJhdG9uLgo+Cj4gVGhhbmtzIHRvIEtlbnQgYW5kIErDvHJnZW4uCj4K PiBSZWdhcmRzLCBCZW5vaXQKPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+IG5ldG1vZEBpZXRmLm9yZwo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXRtb2QgbWFpbGluZyBsaXN0Cm5l dG1vZEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZAo= ----_com.samsung.android.email_759013836644560 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pkp1ZXJnZW48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlRoYW5rIHlvdSBmb3IgYWxsIHlvdXIgaGFyZCB3b3JrIG9uIHlhbmcg MS4xLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U3VlPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48 ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciPlNlbnQgdmlhIHRoZSBTYW1z dW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rp dj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFs TWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48 ZGl2PkZyb206IEJlbm9pdCBDbGFpc2UgJmx0O2JjbGFpc2VAY2lzY28uY29tJmd0OyA8L2Rpdj48 ZGl2PkRhdGU6IDYvMjUvMjAxNiAgMzoyMyBQTSAgKEdNVC0wNjowMCkgPC9kaXY+PGRpdj5Ubzog TkVUTU9EIFdvcmtpbmcgR3JvdXAgJmx0O25ldG1vZEBpZXRmLm9yZyZndDssIEp1ZXJnZW4gU2No b2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0OyA8 L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbbmV0bW9kXSBOZXh0IE5FVE1PRCBjaGFpciA8L2Rpdj48 ZGl2Pjxicj48L2Rpdj48L2Rpdj5EZWFyIGFsbCw8YnI+PGJyPkFzIGRpc2N1c3NlZCB3aXRoIErD vHJnZW4gU2Now7Zud8OkbGRlciBzb21lIHRpbWUgYWdvLCBKw7xyZ2VuIGRlY2lkZWQgdG8gPGJy PnJlbWFpbiBhIE5FVE1PRCBjaGFpciB1bnRpbCBZQU5HIDEuMSB3YXMgZG9uZS4gVGhhdCBtaWxl c3RvbmUgaXMgbm93IDxicj5yZWFjaGVkOiB0aGUgZG9jdW1lbnQgaXMgaW4gdGhlIFJGQy1lZGl0 b3IgcXVldWUuPGJyPlRvZGF5LCBhZ2FpbiBpbiBjb29yZGluYXRpb24gd2l0aCBKw7xyZ2VuLCBJ IHRvb2sgdGhlIG5lY2Vzc2FyeSBhZG1pbiA8YnI+YWN0aW9uIHRvIG9mZmljaWFsbHkgcmVsZWFz ZSBoaW0gb2YgaGlzIGNoYWlyIHBvc2l0aW9uLjxicj48YnI+V2Ugc2hvdWxkIGFsbCBiZSBncmF0 ZWZ1bCB0byBKw7xyZ2VuIGZvciBoaXMgeWVhcnMgb2Ygc2VydmljZSBhcyBORVRNT0QgPGJyPmNo YWlyLjxicj48YnI+UmVnYXJkcywgQmVub2l0PGJyPjxicj4mZ3Q7IERlYXIgYWxsLDxicj4mZ3Q7 PGJyPiZndDsgQXMgeW91IHByb2JhYmx5IGtub3cgZnJvbSBhIHByZXZpb3VzIG1lc3NhZ2UgdG8g dGhlIGxpc3QsIErDvHJnZW4gPGJyPiZndDsgYW5ub3VuY2VkIGhpcyBwbGFucyB0byBzdGVwIGRv d24gYXMgY28tY2hhaXIuPGJyPiZndDsgUGxlYXNlIHdlbGNvbWUgS2VudCBXYXRzZW4sIHdobyBo YXMgYWNjZXB0ZWQgdG8gc2VydmUgYXMgTkVUTU9EIGNvLWNoYWlyLjxicj4mZ3Q7IEFzIGFncmVl ZCB3aXRoIErDvHJnZW4sIHRoZSBORVRNT0QgV0cgd2lsbCBydW4gd2l0aCB0aHJlZSBjaGFpcnMg dW50aWwgPGJyPiZndDsgdGhlIFlBTkcgMS4xIHdvcmsgaXMgY29tcGxldGVkLjxicj4mZ3Q7IFRo YXQgaW1wb3J0YW50IFlBTkcgMS4xIG1pbGVzdG9uZSBpcyB0aGUgcG9pbnQgaW4gdGltZSBKw7xy Z2VuIGRlY2lkZWQgPGJyPiZndDsgdG8gcGFzcyB0aGUgYmF0b24uPGJyPiZndDs8YnI+Jmd0OyBU aGFua3MgdG8gS2VudCBhbmQgSsO8cmdlbi48YnI+Jmd0Ozxicj4mZ3Q7IFJlZ2FyZHMsIEJlbm9p dDxicj4mZ3Q7PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPiZndDsgbmV0bW9kQGlldGYu b3JnPGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8 YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+bmV0bW9kQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_759013836644560-- From nobody Sun Jun 26 23:14:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA58712B03A for ; Sun, 26 Jun 2016 23:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.426 X-Spam-Level: X-Spam-Status: No, score=-8.426 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=-1.426] 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 wb6dyA3RjiHt for ; Sun, 26 Jun 2016 23:14:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E259912B01D for ; Sun, 26 Jun 2016 23:14:22 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:37:630b:44d4:7253] (unknown [IPv6:2001:718:1a02:1:37:630b:44d4:7253]) by mail.nic.cz (Postfix) with ESMTPSA id 649B660828; Mon, 27 Jun 2016 08:14:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1467008061; bh=SAkv1YEgiBtTKAjN7JMpjhn1gGvy5JHO6w7S0CengfI=; h=From:Date:To; b=JrjYRpTsUaeQ2ou2s4t+iG3gXEsdK0ySb7cMG2oXitX0xJTcSnL1jqiWuascP+C+3 A7yNq6skN7ocNBEzpW1OaBsz0mh2LkWLa6bEMc293WysLrtRPBjI+IELEvlsf9wR+A v7z7itYNPot3kCJpq2OH5xyxY523XtLQ2ICZXn6c= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 27 Jun 2016 08:14:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5552F457.2040002@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3124) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Next NETMOD chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 06:14:26 -0000 > On 25 Jun 2016, at 22:23, Benoit Claise wrote: >=20 > Dear all, >=20 > As discussed with J=C3=BCrgen Sch=C3=B6nw=C3=A4lder some time ago, = J=C3=BCrgen decided to remain a NETMOD chair until YANG 1.1 was done. = That milestone is now reached: the document is in the RFC-editor queue. > Today, again in coordination with J=C3=BCrgen, I took the necessary = admin action to officially release him of his chair position. >=20 > We should all be grateful to J=C3=BCrgen for his years of service as = NETMOD chair. Indeed, well done, J=C3=BCrgen. Thanks, Lada >=20 > Regards, Benoit >=20 >> Dear all, >>=20 >> As you probably know from a previous message to the list, J=C3=BCrgen = announced his plans to step down as co-chair. >> Please welcome Kent Watsen, who has accepted to serve as NETMOD = co-chair. >> As agreed with J=C3=BCrgen, the NETMOD WG will run with three chairs = until the YANG 1.1 work is completed. >> That important YANG 1.1 milestone is the point in time J=C3=BCrgen = decided to pass the baton. >>=20 >> Thanks to Kent and J=C3=BCrgen. >>=20 >> Regards, Benoit >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jun 27 03:20:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C79012D162 for ; Mon, 27 Jun 2016 03:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGrVgYyZEYii for ; Mon, 27 Jun 2016 03:20:04 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [IPv6:2001:1900:3001:11::28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE23212D13D for ; Mon, 27 Jun 2016 03:20:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E6B841E5D61; Mon, 27 Jun 2016 03:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RH-_i3jRhIBE; Mon, 27 Jun 2016 03:19:24 -0700 (PDT) Received: from [192.168.1.100] (host81-132-48-184.range81-132.btcentralplus.com [81.132.48.184]) by c8a.amsl.com (Postfix) with ESMTPSA id 5DC4E1E5D5D; Mon, 27 Jun 2016 03:19:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: William Lupton In-Reply-To: <339D00A3-FB6A-4D24-B449-60D96CAA2A9B@broadband-forum.org> Date: Mon, 27 Jun 2016 11:20:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A4AC80F-A917-45BE-B0DE-88384552709B@broadband-forum.org> References: <339D00A3-FB6A-4D24-B449-60D96CAA2A9B@broadband-forum.org> To: netmod@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [netmod] Canonical order: linkage and meta X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 10:20:06 -0000 All, No-one replied to this. Fair enough, because it probably seems a rather = trivial question! But I wanted to point out that a practical consequence = of the description being a long way down a module is that the license = text could easily be missed (assuming it=E2=80=99s in the top-level = description, which is the usual IETF - and BBF - practice). In one BBF = module (lots of includes, each of which has a revision-date and uses 3 = lines), the top-level description begins at line 149 out of 204. OK, we could put a comment nearer the top of the file that points the = reader further down the file, or we could move the license text into a = comment near the top of the file. But usual YANG practice (and I like = this) seems to be to prefer to put information into YANG statements = rather than into comments. Thoughts? Thanks, William > On 9 Jun 2016, at 12:30, William Lupton = wrote: >=20 > All, >=20 > RFC 6020bis says =E2=80=9CThe ABNF grammar [RFC5234] [RFC7405] defines = the canonical order. To improve module readability, it is RECOMMENDED = that clauses be entered in this order.=E2=80=9D >=20 > The ABNF places linkage-stmts (import, include) before meta-stmts = (organization, contact, description, reference) but if there are a lot = of linkage statements (which will be the case in the main module if = there are a large number of submodules=E2=80=A6 as there are for some of = the modules that BBF is defining) this means that the description can be = a fair way down the module. >=20 > Would there be any support for regarding placement of the meta = statements before the linkage statements as not being a violation of = canonical order? Note (this might be inadvertent) that the ABNF actually = defines =E2=80=9Cmeta-stmts=E2=80=9D before =E2=80=9Clinkage-stmts=E2=80=9D= . >=20 > Thanks, > William From nobody Mon Jun 27 03:39:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2237612D108; Mon, 27 Jun 2016 03:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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=-1.426, 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 HMszAXebSOIf; Mon, 27 Jun 2016 03:39:54 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D709012D0A2; Mon, 27 Jun 2016 03:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=298; q=dns/txt; s=iport; t=1467023993; x=1468233593; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=dii2FHdMf5A1vKrNMe/+OdhMonOjUDrWmWDTzpLACtY=; b=IcTacE6q9BSXkaEtTd77sOZIoSEtTIe/V0INn1zLvUovIi21VdBZZH3I wfV65DC+B+GT8ELR71a5lZyU70PVx4ejjpq+cUNii+yY1rG0iPLiBYMCZ 9rUt3OyBgEA2QtUALLql/pGH0ZaCT/jiGtqtAcxg3tKawMV6fA27WKyQH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAQCZ/nBX/xbLJq1bhBQrunmBeySFd?= =?us-ascii?q?IFmFAEBAQEBAQFlJ4R2FUE1AiYCXw0IAQGILA6uLo97AQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEYBYEBhSeBd4oXgloBBJkBhgiIL4FTAYd0hVyPfx42g3I6iikBAQE?= X-IronPort-AV: E=Sophos;i="5.26,536,1459814400"; d="scan'208";a="635392921" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 10:39:51 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u5RAdoND015419; Mon, 27 Jun 2016 10:39:51 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: <6771d54b-96f4-4d17-4a2e-6574f54aaa8c@cisco.com> Date: Mon, 27 Jun 2016 12:39:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod-chairs@ietf.org" , draft-ietf-netmod-yang-model-classification@ietf.org Subject: [netmod] draft-ietf-netmod-yang-model-classification-02.txt posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 10:39:55 -0000 Dear all, We have posted draft-ietf-netmod-yang-model-classification version 2 https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ We believe that we have addressed all the open issues, and that this draft is ready for WGLC. Regards, Carl, Dean, and Benoit From nobody Mon Jun 27 04:04:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBED12D122 for ; Mon, 27 Jun 2016 04:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 JE9AmgGPId3J for ; Mon, 27 Jun 2016 04:04:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CBF12D115 for ; Mon, 27 Jun 2016 04:04:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9778CFB0; Mon, 27 Jun 2016 13:04:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WzlzTVyREHuv; Mon, 27 Jun 2016 13:03:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 27 Jun 2016 13:04:00 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28B782005F; Mon, 27 Jun 2016 13:04:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CMXB1m733xG9; Mon, 27 Jun 2016 13:03:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E5EB20058; Mon, 27 Jun 2016 13:03:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 71BDA3B3BDF7; Mon, 27 Jun 2016 13:03:58 +0200 (CEST) Date: Mon, 27 Jun 2016 13:03:58 +0200 From: Juergen Schoenwaelder To: William Lupton Message-ID: <20160627110358.GB52882@elstar.local> Mail-Followup-To: William Lupton , netmod@ietf.org References: <339D00A3-FB6A-4D24-B449-60D96CAA2A9B@broadband-forum.org> <9A4AC80F-A917-45BE-B0DE-88384552709B@broadband-forum.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <9A4AC80F-A917-45BE-B0DE-88384552709B@broadband-forum.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Canonical order: linkage and meta X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 11:04:07 -0000 I think changing the canonical format because some people may miss the copyright since they have to scroll down a bit is not really worth the pain of having different canonical formats out there. And something like // please scroll down to see the license does seem to sovle the problem. /js On Mon, Jun 27, 2016 at 11:20:02AM +0100, William Lupton wrote: > All, > > No-one replied to this. Fair enough, because it probably seems a rather trivial question! But I wanted to point out that a practical consequence of the description being a long way down a module is that the license text could easily be missed (assuming it’s in the top-level description, which is the usual IETF - and BBF - practice). In one BBF module (lots of includes, each of which has a revision-date and uses 3 lines), the top-level description begins at line 149 out of 204. > > OK, we could put a comment nearer the top of the file that points the reader further down the file, or we could move the license text into a comment near the top of the file. But usual YANG practice (and I like this) seems to be to prefer to put information into YANG statements rather than into comments. > > Thoughts? > > Thanks, > William > > > On 9 Jun 2016, at 12:30, William Lupton wrote: > > > > All, > > > > RFC 6020bis says “The ABNF grammar [RFC5234] [RFC7405] defines the canonical order. To improve module readability, it is RECOMMENDED that clauses be entered in this order.” > > > > The ABNF places linkage-stmts (import, include) before meta-stmts (organization, contact, description, reference) but if there are a lot of linkage statements (which will be the case in the main module if there are a large number of submodules… as there are for some of the modules that BBF is defining) this means that the description can be a fair way down the module. > > > > Would there be any support for regarding placement of the meta statements before the linkage statements as not being a violation of canonical order? Note (this might be inadvertent) that the ABNF actually defines “meta-stmts” before “linkage-stmts”. > > > > Thanks, > > William > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 27 04:13:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D76712D11F for ; Mon, 27 Jun 2016 04:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] 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 IeonUPfu5AgZ for ; Mon, 27 Jun 2016 04:13:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (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 48F8712D110 for ; Mon, 27 Jun 2016 04:13:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ENAQCsCHFX/yYyC4dbGgEBAQGCcy1Wf?= =?us-ascii?q?QaNJKpvgg+BOUIigWuECwIcgRA4FAEBAQEBAQEDYieCQTkGBy4BAQEnAg8gIQE?= =?us-ascii?q?BGQEBAQEDEhEROhcEAgEIDQMBBAEBAQICBh0DAgICMBQBCAgCBAESCBqIDgENo?= =?us-ascii?q?3mKUI99AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSiETIRCFYJqK4IvBZkBAYY?= =?us-ascii?q?HihhOhAaDIoVFj38eNoNwboh4AX4BAQE?= X-IPAS-Result: =?us-ascii?q?A2ENAQCsCHFX/yYyC4dbGgEBAQGCcy1WfQaNJKpvgg+BOUI?= =?us-ascii?q?igWuECwIcgRA4FAEBAQEBAQEDYieCQTkGBy4BAQEnAg8gIQEBGQEBAQEDEhERO?= =?us-ascii?q?hcEAgEIDQMBBAEBAQICBh0DAgICMBQBCAgCBAESCBqIDgENo3mKUI99AQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBHIEBhSiETIRCFYJqK4IvBZkBAYYHihhOhAaDIoVFj?= =?us-ascii?q?38eNoNwboh4AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,536,1459828800"; d="scan'208";a="160012309" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Jun 2016 07:13:16 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 27 Jun 2016 07:13:16 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Mon, 27 Jun 2016 13:13:14 +0200 From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (Nokia - DE/Munich)" , "Bert Wijnen (IETF)" , Benoit Claise , NETMOD Working Group , Juergen Schoenwaelder Thread-Topic: [netmod] Next NETMOD chair Thread-Index: AQHRzx+A7TG8n7sdOkCLjIgu7vj9bZ/66cmAgAAB8ICAAj+woA== Date: Mon, 27 Jun 2016 11:13:14 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA7521C0EB@AZ-FFEXMB04.global.avaya.com> References: <5552F457.2040002@cisco.com> <7f5e1bc7-4d1e-e642-6606-a7015710a078@bwijnen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Next NETMOD chair X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 11:13:22 -0000 VGhhbmtzIGZvciB0aGUgc3BsZW5kaWQgam9iIGRvbmUsIEp1ZXJnZW4hDQoNClJlZ2FyZHMsDQoN CkRhbg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbmV0bW9kIFtt YWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcnN1ZSwNCj4gTWVo bWV0IChOb2tpYSAtIERFL011bmljaCkNCj4gU2VudDogU2F0dXJkYXksIEp1bmUgMjUsIDIwMTYg MTE6NTIgUE0NCj4gVG86IEJlcnQgV2lqbmVuIChJRVRGKTsgQmVub2l0IENsYWlzZTsgTkVUTU9E IFdvcmtpbmcgR3JvdXA7IEp1ZXJnZW4NCj4gU2Nob2Vud2FlbGRlcg0KPiBTdWJqZWN0OiBSZTog W25ldG1vZF0gTmV4dCBORVRNT0QgY2hhaXINCj4gDQo+ICsxDQo+IA0KPiANCj4gDQo+IE1laG1l dA0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiANCj4gRnJvbTog bmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZXJ0 IFdpam5lbg0KPiAoSUVURikNCj4gDQo+IFNlbnQ6IFNhdHVyZGF5LCBKdW5lIDI1LCAyMDE2IDEw OjQ1IFBNDQo+IA0KPiBUbzogQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+OyBORVRN T0QgV29ya2luZyBHcm91cA0KPiA8bmV0bW9kQGlldGYub3JnPjsgSnVlcmdlbiBTY2hvZW53YWVs ZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLQ0KPiB1bml2ZXJzaXR5LmRlPg0KPiANCj4gU3Vi amVjdDogUmU6IFtuZXRtb2RdIE5leHQgTkVUTU9EIGNoYWlyDQo+IA0KPiANCj4gDQo+IFRoYW5r cyBKdWVyZ2VuLg0KPiANCj4gDQo+IA0KPiBCZXJ0DQo+IA0KPiANCj4gDQo+IE9uIDI1LzA2LzE2 IDIyOjIzLCBCZW5vaXQgQ2xhaXNlIHdyb3RlOg0KPiANCj4gPiBEZWFyIGFsbCwNCj4gDQo+ID4N Cj4gDQo+ID4gQXMgZGlzY3Vzc2VkIHdpdGggSsO8cmdlbiBTY2jDtm53w6RsZGVyIHNvbWUgdGlt ZSBhZ28sIErDvHJnZW4gZGVjaWRlZCB0bw0KPiByZW1haW4gYSBORVRNT0QgY2hhaXIgdW50aWwg WUFORyAxLjEgd2FzIGRvbmUuIFRoYXQgbWlsZXN0b25lDQo+IA0KPiA+IGlzIG5vdyByZWFjaGVk OiB0aGUgZG9jdW1lbnQgaXMgaW4gdGhlIFJGQy1lZGl0b3IgcXVldWUuDQo+IA0KPiA+IFRvZGF5 LCBhZ2FpbiBpbiBjb29yZGluYXRpb24gd2l0aCBKw7xyZ2VuLCBJIHRvb2sgdGhlIG5lY2Vzc2Fy eSBhZG1pbiBhY3Rpb24NCj4gdG8gb2ZmaWNpYWxseSByZWxlYXNlIGhpbSBvZiBoaXMgY2hhaXIg cG9zaXRpb24uDQo+IA0KPiA+DQo+IA0KPiA+IFdlIHNob3VsZCBhbGwgYmUgZ3JhdGVmdWwgdG8g SsO8cmdlbiBmb3IgaGlzIHllYXJzIG9mIHNlcnZpY2UgYXMgTkVUTU9EDQo+IGNoYWlyLg0KPiAN Cj4gPg0KPiANCj4gPiBSZWdhcmRzLCBCZW5vaXQNCj4gDQo+ID4NCj4gDQo+ID4+IERlYXIgYWxs LA0KPiANCj4gPj4NCj4gDQo+ID4+IEFzIHlvdSBwcm9iYWJseSBrbm93IGZyb20gYSBwcmV2aW91 cyBtZXNzYWdlIHRvIHRoZSBsaXN0LCBKw7xyZ2VuDQo+IGFubm91bmNlZCBoaXMgcGxhbnMgdG8g c3RlcCBkb3duIGFzIGNvLWNoYWlyLg0KPiANCj4gPj4gUGxlYXNlIHdlbGNvbWUgS2VudCBXYXRz ZW4sIHdobyBoYXMgYWNjZXB0ZWQgdG8gc2VydmUgYXMgTkVUTU9EIGNvLQ0KPiBjaGFpci4NCj4g DQo+ID4+IEFzIGFncmVlZCB3aXRoIErDvHJnZW4sIHRoZSBORVRNT0QgV0cgd2lsbCBydW4gd2l0 aCB0aHJlZSBjaGFpcnMgdW50aWwNCj4gdGhlIFlBTkcgMS4xIHdvcmsgaXMgY29tcGxldGVkLg0K PiANCj4gPj4gVGhhdCBpbXBvcnRhbnQgWUFORyAxLjEgbWlsZXN0b25lIGlzIHRoZSBwb2ludCBp biB0aW1lIErDvHJnZW4gZGVjaWRlZCB0bw0KPiBwYXNzIHRoZSBiYXRvbi4NCj4gDQo+ID4+DQo+ IA0KPiA+PiBUaGFua3MgdG8gS2VudCBhbmQgSsO8cmdlbi4NCj4gDQo+ID4+DQo+IA0KPiA+PiBS ZWdhcmRzLCBCZW5vaXQNCj4gDQo+ID4+DQo+IA0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K PiANCj4gPj4gbmV0bW9kQGlldGYub3JnDQo+IA0KPiA+PiBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19uZXRtb2QmZD1Dd0lHYVEmYz1CRnBXUXc4YnN1DQo+IEtwbDFTZ2laSDY0USZyPUk0 ZHpHeFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBocEJzRkEmbT1vT1ANCj4gblpkNnZo Z014ck9vMTRWZmV5X3U2UzlOWlNGZFlIOWNSMVR4OUptcyZzPW5vaWFmWHBNLQ0KPiBGdVJvQW93 TVNqdGZ3dXBKd0R2QklaWl8tc1FCSnRXZ0lnJmU9DQo+IA0KPiA+DQo+IA0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiA+IG5ldG1vZCBt YWlsaW5nIGxpc3QNCj4gDQo+ID4gbmV0bW9kQGlldGYub3JnDQo+IA0KPiA+IGh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUN3SUdhUSZjPUJGcFdRdzhic3UNCj4gS3BsMVNn aVpINjRRJnI9STRkekd4UjMxT2NOWENKZlF6dmxzaUxRZnVjQlhSdWNQdmRycGhwQnNGQSZtPW9P UA0KPiBuWmQ2dmhnTXhyT28xNFZmZXlfdTZTOU5aU0ZkWUg5Y1IxVHg5Sm1zJnM9bm9pYWZYcE0t DQo+IEZ1Um9Bb3dNU2p0Znd1cEp3RHZCSVpaXy1zUUJKdFdnSWcmZT0NCj4gDQo+IA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IG5l dG1vZCBtYWlsaW5nIGxpc3QNCj4gDQo+IG5ldG1vZEBpZXRmLm9yZw0KPiANCj4gaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9Q3dJR2FRJmM9QkZwV1F3OGJzdQ0KPiBLcGwx U2dpWkg2NFEmcj1JNGR6R3hSMzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09 b09QDQo+IG5aZDZ2aGdNeHJPbzE0VmZleV91NlM5TlpTRmRZSDljUjFUeDlKbXMmcz1ub2lhZlhw TS0NCj4gRnVSb0Fvd01TanRmd3VwSndEdkJJWlpfLXNRQkp0V2dJZyZlPQ0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxp bmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGlu Zm9fbmV0bW9kJmQ9Q3dJR2FRJmM9QkZwV1F3OGJzdQ0KPiBLcGwxU2dpWkg2NFEmcj1JNGR6R3hS MzFPY05YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09b09QDQo+IG5aZDZ2aGdNeHJP bzE0VmZleV91NlM5TlpTRmRZSDljUjFUeDlKbXMmcz1ub2lhZlhwTS0NCj4gRnVSb0Fvd01TanRm d3VwSndEdkJJWlpfLXNRQkp0V2dJZyZlPQ0K From nobody Mon Jun 27 07:48:21 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB35712D78E; Mon, 27 Jun 2016 07:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 BQBwTL4yZdHe; Mon, 27 Jun 2016 07:48:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A76B12D621; Mon, 27 Jun 2016 07:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yQcHZ9trWDMMKdKfmar4yYJxYmlh19Mi/c1gGi5VTkU=; b=PkHnNk91/b/SVnCnGK/BXXcvZXGUYV7rvqfJTMMvK3byAKJzU71X4lQUj+hRmeFlITsJc27ZPiGnjsSQCTj5NT4nlYvt/+xOBbtR/iJfMXIcd7RSakhCr/nZPWIRbRIL2Eh/pAhzcoOkNXvm50SkBiQ9dRWK3y5AgbBrzZWnTi0= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Mon, 27 Jun 2016 14:44:52 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Mon, 27 Jun 2016 14:44:52 +0000 From: Kent Watsen To: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" , "Lou Berger" Thread-Topic: [netmod] Opstate solutions discussions: update and request for WGinput Thread-Index: AQHRyKtriAUTbkyKIUqPd3s4x2EFBZ/t+QmAgAADJwCAAACqgIAPM6yA Date: Mon, 27 Jun 2016 14:44:52 +0000 Message-ID: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.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.17.0.160611 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: 94dc474e-6edf-407c-6ca6-08d39e999930 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:zzDqLCFramYWQmdlrrNBuoWSbmrg78ctQP30I0aZHLRzcoJID6f3tbr5wuPRZU00SkvPLArZD7UwiW3qN0I/1nZp9jom2PD2TsqODIsT7pKljkr1ukpV+WugWqVjNn3WZuqtwS75jHimtnzHOywFSzX0qbuStbtH+w8aozxrT93ux5cXfsjyknPvhEjr6IO91TG0PMSqS38BWeLmVkJizWdGacQYOhkDxacKofB8+KzwfeYqN0C+zAJZgdOeq5UPES/3C9dfF7+dI2xxfr7O6zGuWzVesbFjtcb+uCoCRHS98tKil2E8BEXn38NHOlLGQ2DdSy96p35Md6VDKKBjxg==; 5:lfXqlnjFA045d6f0nCfSdmxvIxJRfq40tAaTNvppzFNzviFkJoWRZO5qJ6K8vBCVkZ2LFb2r9AogyTWhVCGynCQaYJIC1rqPAb0/vEdJuCq4xn24LoPVrHr0uZkf6NkSTd1C6a++RHQ8ZdOgFi/J5A==; 24:SwB0tjfp7fJCN/amMn/aDc2xFCGQ8JV0BuWWrmDcu5nkyYPEkFVCmmpAVhdqTBDSRpegl45sxSt66LSIKjCYJoN2uyYfLOsK3zmuQo1PJ6M=; 7:3Ygiao/5LHnGkHPtMCFG4i3CxGLtGL1QM/iCZF25T/FvHSceA2IXzHW4NBg8WKvu+TuJNABnzQUvCTCD/9sctkDq4lfGYqTKkOqLG6vRO2LyLtTdiE/w6q/gsGtB6LcdVwWVAiW5T2y6AS2JanCHpwe+Hci2d36lZfPc7tO2sjW1dN+MaXILKu6Cr+larZkzG+WsuIWGl+ox4LQFGA4kn+4tW+5lVy1WAEoL81RmyTR52yt1fWd98Bs2R007B1YD x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(138986009662008)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(53754006)(19300405004)(122556002)(83716003)(5002640100001)(16236675004)(93886004)(8936002)(7736002)(68736007)(2906002)(7846002)(19580395003)(10710500007)(19580405001)(99286002)(10400500002)(19617315012)(7110500001)(86362001)(54356999)(50986999)(19625215002)(11100500001)(106116001)(87936001)(561944003)(106356001)(66066001)(15650500001)(105586002)(97736004)(4001350100001)(3660700001)(3280700002)(102836003)(6116002)(3846002)(2420400007)(33656002)(7906003)(8676002)(4326007)(92566002)(77096005)(586003)(101416001)(82746002)(189998001)(36756003)(15975445007)(76176999)(2950100001)(2900100001)(5001770100001)(83506001)(81156014)(81166006)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.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_A3DA5DFE5EBC49C6959FEB01C826AE56junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2016 14:44:52.6013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 14:48:19 -0000 --_000_A3DA5DFE5EBC49C6959FEB01C826AE56junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W2FzIGEgY29udHJpYnV0b3JdDQoNCknigJltIGZvciDigJhC4oCZIGFzIHdlbGwsIGluIGNhc2Ug aXQgd2FzbuKAmXQgb2J2aW91cyBmcm9tIFsyXSAgKExvdeKAmXMgcmVmIGJlbG93KS4NCg0KS2Vu dA0KDQoNCkZyb206ICJLaXJhbiBLb3VzaGlrIEFncmFoYXJhIFNyZWVuaXZhc2EgKGtrb3VzaGlr KSIgPGtrb3VzaGlrQGNpc2NvLmNvbT4NCkRhdGU6IEZyaWRheSwgSnVuZSAxNywgMjAxNiBhdCAy OjM2IFBNDQpUbzogTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4NCkNjOiAibmV0bW9kLWNo YWlyc0BpZXRmLm9yZyIgPG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc+LCAibmV0bW9kQGlldGYub3Jn IiA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIE9wc3RhdGUgc29sdXRp b25zIGRpc2N1c3Npb25zOiB1cGRhdGUgYW5kIHJlcXVlc3QgZm9yIFdHaW5wdXQNClJlc2VudC1G cm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NClJlc2VudC1UbzogPGouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4sIDxsYmVyZ2VyQGxhYm4ubmV0PiwgS2VudCBXYXRzZW4g PGt3YXRzZW5AanVuaXBlci5uZXQ+LCA8bWlzaHJhLmFzaGVzaEBvdXRsb29rLmNvbT4NClJlc2Vu dC1EYXRlOiBGcmlkYXksIEp1bmUgMTcsIDIwMTYgYXQgMjozNiBQTQ0KDQpIaSBBbGwNCknigJlk IGxpa2UgdG8gc3VwcG9ydCBPcHRpb24gQiBiZWxvdy4NCj4+ICAgICBCKSBubyBleHBsaWNpdCBz dXBwb3J0IGlzIHJlcXVpcmVkIGZvciBtb2RlbHMgdG8gc3VwcG9ydA0KPj4gICAgICAgIGFwcGxp ZWQgY29uZmlndXJhdGlvbiAtLSBhbmQgdGhhdCB0aGUgV0cgbmVlZHMgdG8NCj4+ICAgICAgICBm b3JtYWxpemUgYW4gb3BzdGF0ZSBzb2x1dGlvbiBiYXNlZCBvbiB0aGUgYXBwcm9hY2gNCj4+ICAg ICAgICBkaXNjdXNzZWQgaW4gWzRdIGFuZCBbNV0uDQoNClRoYW5rcw0KS2lyYW4NCg0KDQo+PiBB bGwsDQo+Pg0KPj4gV2Ugd2FudCB0byBwcm92aWRlIGFuIHVwZGF0ZSBiYXNlZCBvbiB0aGUgb2Zm IGxpbmUgZGlzY3Vzc2lvbnMNCj4+IHJlbGF0ZWQgdG8gT3BTdGF0ZSBTb2x1dGlvbnMgdGhhdCB3 ZSBoYXZlIGJlZW4gaGF2aW5nIGFuZCBzb2xpY2l0DQo+PiBpbnB1dCBmcm9tIHRoZSBXRy4NCj4+ DQo+PiBBbGwgYXV0aG9ycyBvZiBjdXJyZW50IHNvbHV0aW9uIGRyYWZ0cyBbMSwyLDNdIHRvZ2V0 aGVyIHdpdGggdGhvc2UNCj4+IHdobyBoZWxwZWQgY29uZHVjdCB0aGUgc29sdXRpb25zIGFuYWx5 c2lzKiB3ZXJlIGludml0ZWQgdG8gdGhlIHRoZXNlDQo+PiBkaXNjdXNzaW9ucyAtLSB3aXRoIHRo ZSBvYmplY3RpdmUgb2YgY29taW5nIHVwIHdpdGggYSBzaW5nbGUNCj4+IGNvbnNvbGlkYXRlZCBw cm9wb3NhbCB0byBicmluZyB0byB0aGUgV0cuIChJL0xvdSBhY3RlZCBhcyBmYWNpbGl0YXRvcg0K Pj4gYXMgS2VudCBhbmQgSnVlcmdlbiB3ZXJlIGFuZCBhcmUgaW52b2x2ZWQgd2l0aCB0aGUgdGVj aG5pY2FsIGRldGFpbHMuKQ0KPj4NCj4+IFRoZSBkaXNjdXNzaW9ucyBoYXZlIHlpZWxkZWQgc29t ZSByZXN1bHRzIGJ1dCwgdW5mb3J0dW5hdGVseSwNCj4+IG5vdCBhIHNpbmdsZSBjb25zb2xpZGF0 ZWQgcHJvcG9zYWwgYXMgaG9wZWQsIGJ1dCByYXRoZXIgdHdvDQo+PiBhbHRlcm5hdGUgZGlyZWN0 aW9ucyAtLSBhbmQgY2xlYXJseSB3ZSBuZWVkIHRvIGNob29zZSBvbmU6DQo+Pg0KPj4gICAgIDEp IEFkb3B0IHRoZSBjb252ZW50aW9ucyBmb3IgcmVwcmVzZW50aW5nIHN0YXRlL2NvbmZpZw0KPj4g ICAgICAgIGJhc2VkIG9uIFNlY3Rpb24gNiBvZiBbMV0uDQo+Pg0KPj4gICAgICAgIEZyb20gYSBt b2RlbCBkZWZpbml0aW9uIHBlcnNwZWN0aXZlLCB0aGVzZSBjb252ZW50aW9ucw0KPj4gICAgICAg IGltcGFjdCBldmVyeSBtb2RlbCBhbmQgZXZlcnkgbW9kZWwgd3JpdGVyLg0KPj4NCj4+ICAgICAy KSBNb2RlbCBPcFN0YXRlIHVzaW5nIGEgcmV2aXNlZCBsb2dpY2FsIGRhdGFzdG9yZSBkZWZpbml0 aW9uDQo+PiAgICAgICAgYXMgaW50cm9kdWNlZCBpbiBbNF0gYW5kIGFsc28gY292ZXJlZCBpbiBb NV0uIFRoZXJlIGlzDQo+PiAgICAgICAgYWxzbyBhIHZhcmlhbnQgb2YgdGhpcyB0aGF0IHdlIGJl bGlldmUgZG9lc24ndCBzaWduaWZpY2FudGx5DQo+PiAgICAgICAgaW1wYWN0IHRoaXMgY2hvaWNl Lg0KPj4NCj4+ICAgICAgICBXaXRoIHRoaXMgYXBwcm9hY2gsIG1vZGVsIGRlZmluaXRpb25zIG5l ZWQgbm8gZXhwbGljaXQNCj4+ICAgICAgICBjaGFuZ2VzIHRvIHN1cHBvcnQgYXBwbGllZCBjb25m aWd1cmF0aW9uLg0KPj4NCj4+ID5Gcm9tIGEgdGVjaG5vbG9neS9XRyBzdGFuZHBvaW50LCB3ZSBi ZWxpZXZlIGFuIGFwcHJvYWNoDQo+PiB0aGF0IGRvZXNuJ3QgaW1wYWN0IGV2ZXJ5IG1vZGVsIHdy aXR0ZW4gKGkuZS4sICMyKSBpcyBzdXBlcmlvci4NCj4+IFRoZSBjb3VudGVycG9pbnQgdG8gdGhp cyBpcyB0aGF0IHRoZSBjb252ZW50aW9ucyBiYXNlZA0KPj4gYXBwcm9hY2ggKGkuZS4sICMxKSBp cyBhdmFpbGFibGUgdG9kYXkgYW5kIGJlaW5nIGZvbGxvd2VkIGluDQo+PiBPcGVuQ29uZmlnIGRl ZmluZWQgbW9kZWxzLg0KPj4NCj4+IFdlIHdvdWxkIGxpa2UgdG8gaGVhciBvcGluaW9ucyBvbiB0 aGlzIGZyb20gdGhlIFdHIGJlZm9yZQ0KPj4gZGVjbGFyaW5nIG9uZSBvZiB0aGUgZm9sbG93aW5n IGFzIHRoZSBXRyBkaXJlY3Rpb246DQo+Pg0KPj4gICAgIEEpIG1vZGVscyB0aGF0IHdpc2ggdG8g c3VwcG9ydCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gTVVTVA0KPj4gICAgICAgIGZvbGxvdyBjb252 ZW50aW9ucyBiYXNlZCBvbiBbMV0gLS0gYW5kIHRoZSBXRyBuZWVkcyB0bw0KPj4gICAgICAgIGZv cm1hbGl6ZSB0aGVzZSBjb252ZW50aW9ucy4NCj4+IG9yDQo+PiAgICAgQikgbm8gZXhwbGljaXQg c3VwcG9ydCBpcyByZXF1aXJlZCBmb3IgbW9kZWxzIHRvIHN1cHBvcnQNCj4+ICAgICAgICBhcHBs aWVkIGNvbmZpZ3VyYXRpb24gLS0gYW5kIHRoYXQgdGhlIFdHIG5lZWRzIHRvDQo+PiAgICAgICAg Zm9ybWFsaXplIGFuIG9wc3RhdGUgc29sdXRpb24gYmFzZWQgb24gdGhlIGFwcHJvYWNoDQo+PiAg ICAgICAgZGlzY3Vzc2VkIGluIFs0XSBhbmQgWzVdLg0KPj4NCj4+IFdlIGludGVuZCB0byBjbG9z ZSBvbiB0aGlzIGNob2ljZSBiZWZvcmUgQmVybGluLg0KPj4NCj4+IFRoYW5rIHlvdSwNCj4+IExv dSAoYW5kIGNvLWNoYWlycykNCj4+DQo+PiBbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3RhdGUtMDENCj4+IFsyXSBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZS0wMg0KPj4gWzNdIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aWx0b24tbmV0bW9kLW9wc3RhdGUteWFu Zy0wMg0KPj4gWzRdDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2hvZW53 LW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDANCj4+IFs1XQ0KPiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtd2lsdG9uLW5ldG1vZC1yZWZpbmVkLWRhdGFzdG9yZXMtMDANCj4+ ICogLSBDaHJpcyBILiBhbmQgQWNlZSBMLg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4g bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRt b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== --_000_A3DA5DFE5EBC49C6959FEB01C826AE56junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <1A48E665354041429EEE39DFD7FCEE39@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlthcyBhIGNvbnRyaWJ1dG9yXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkni gJltIGZvciDigJhC4oCZIGFzIHdlbGwsIGluIGNhc2UgaXQgd2FzbuKAmXQgb2J2aW91cyBmcm9t IFsyXSZuYnNwOyAoTG914oCZcyByZWYgYmVsb3cpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFu Pg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mcXVv dDtLaXJhbiBLb3VzaGlrIEFncmFoYXJhIFNyZWVuaXZhc2EgKGtrb3VzaGlrKSZxdW90OyAmbHQ7 a2tvdXNoaWtAY2lzY28uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEp1bmUgMTcs IDIwMTYgYXQgMjozNiBQTTxicj4NCjxiPlRvOiA8L2I+TG91IEJlcmdlciAmbHQ7bGJlcmdlckBs YWJuLm5ldCZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O25ldG1vZC1jaGFpcnNAaWV0Zi5vcmcm cXVvdDsgJmx0O25ldG1vZC1jaGFpcnNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtuZXRtb2RAaWV0Zi5v cmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtuZXRtb2RdIE9wc3RhdGUgc29sdXRpb25zIGRpc2N1c3Npb25zOiB1cGRhdGUgYW5kIHJlcXVl c3QgZm9yIFdHaW5wdXQ8YnI+DQo8Yj5SZXNlbnQtRnJvbTogPC9iPiZsdDthbGlhcy1ib3VuY2Vz QGlldGYub3JnJmd0Ozxicj4NCjxiPlJlc2VudC1UbzogPC9iPiZsdDtqLnNjaG9lbndhZWxkZXJA amFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7LCAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDssIEtlbnQg V2F0c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0OywgJmx0O21pc2hyYS5hc2hlc2hAb3V0 bG9vay5jb20mZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5GcmlkYXksIEp1bmUgMTcsIDIw MTYgYXQgMjozNiBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2siPkhpIEFsbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+ SeKAmWQgbGlrZSB0byBzdXBwb3J0IE9wdGlvbiBCIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO0IpIG5vIGV4cGxpY2l0IHN1cHBvcnQgaXMgcmVxdWlyZWQgZm9y IG1vZGVscyB0byBzdXBwb3J0PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgYXBwbGllZCBjb25maWd1cmF0aW9uIC0tIGFuZCB0aGF0IHRoZSBXRyBuZWVkcyB0bzxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvcm1hbGl6ZSBhbiBvcHN0YXRl IHNvbHV0aW9uIGJhc2VkIG9uIHRoZSBhcHByb2FjaDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGRpc2N1c3NlZCBpbiBbNF0gYW5kIFs1XS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtj b2xvcjpibGFjayI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj5LaXJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2siPjxicj4NCiZndDsmZ3Q7 IEFsbCw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdlIHdhbnQgdG8gcHJvdmlkZSBhbiB1 cGRhdGUgYmFzZWQgb24gdGhlIG9mZiBsaW5lIGRpc2N1c3Npb25zPGJyPg0KJmd0OyZndDsgcmVs YXRlZCB0byBPcFN0YXRlIFNvbHV0aW9ucyB0aGF0IHdlIGhhdmUgYmVlbiBoYXZpbmcgYW5kIHNv bGljaXQ8YnI+DQomZ3Q7Jmd0OyBpbnB1dCBmcm9tIHRoZSBXRy48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IEFsbCBhdXRob3JzIG9mIGN1cnJlbnQgc29sdXRpb24gZHJhZnRzIFsxLDIsM10g dG9nZXRoZXIgd2l0aCB0aG9zZTxicj4NCiZndDsmZ3Q7IHdobyBoZWxwZWQgY29uZHVjdCB0aGUg c29sdXRpb25zIGFuYWx5c2lzKiB3ZXJlIGludml0ZWQgdG8gdGhlIHRoZXNlPGJyPg0KJmd0OyZn dDsgZGlzY3Vzc2lvbnMgLS0gd2l0aCB0aGUgb2JqZWN0aXZlIG9mIGNvbWluZyB1cCB3aXRoIGEg c2luZ2xlPGJyPg0KJmd0OyZndDsgY29uc29saWRhdGVkIHByb3Bvc2FsIHRvIGJyaW5nIHRvIHRo ZSBXRy4gKEkvTG91IGFjdGVkIGFzIGZhY2lsaXRhdG9yPGJyPg0KJmd0OyZndDsgYXMgS2VudCBh bmQgSnVlcmdlbiB3ZXJlIGFuZCBhcmUgaW52b2x2ZWQgd2l0aCB0aGUgdGVjaG5pY2FsIGRldGFp bHMuKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGRpc2N1c3Npb25zIGhhdmUgeWll bGRlZCBzb21lIHJlc3VsdHMgYnV0LCB1bmZvcnR1bmF0ZWx5LDxicj4NCiZndDsmZ3Q7IG5vdCBh IHNpbmdsZSBjb25zb2xpZGF0ZWQgcHJvcG9zYWwgYXMgaG9wZWQsIGJ1dCByYXRoZXIgdHdvPGJy Pg0KJmd0OyZndDsgYWx0ZXJuYXRlIGRpcmVjdGlvbnMgLS0gYW5kIGNsZWFybHkgd2UgbmVlZCB0 byBjaG9vc2Ugb25lOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOzEpIEFkb3B0IHRoZSBjb252ZW50aW9ucyBmb3IgcmVwcmVzZW50aW5nIHN0YXRlL2NvbmZp Zzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJhc2VkIG9uIFNlY3Rp b24gNiBvZiBbMV0uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBGcm9tIGEgbW9kZWwgZGVmaW5pdGlvbiBwZXJzcGVjdGl2ZSwgdGhlc2UgY29u dmVudGlvbnM8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpbXBhY3Qg ZXZlcnkgbW9kZWwgYW5kIGV2ZXJ5IG1vZGVsIHdyaXRlci48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsyKSBNb2RlbCBPcFN0YXRlIHVzaW5nIGEgcmV2aXNl ZCBsb2dpY2FsIGRhdGFzdG9yZSBkZWZpbml0aW9uPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgYXMgaW50cm9kdWNlZCBpbiBbNF0gYW5kIGFsc28gY292ZXJlZCBpbiBb NV0uIFRoZXJlIGlzPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYWxz byBhIHZhcmlhbnQgb2YgdGhpcyB0aGF0IHdlIGJlbGlldmUgZG9lc24ndCBzaWduaWZpY2FudGx5 PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW1wYWN0IHRoaXMgY2hv aWNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgV2l0aCB0aGlzIGFwcHJvYWNoLCBtb2RlbCBkZWZpbml0aW9ucyBuZWVkIG5vIGV4cGxpY2l0 PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2hhbmdlcyB0byBzdXBw b3J0IGFwcGxpZWQgY29uZmlndXJhdGlvbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDtGcm9tIGEgdGVjaG5vbG9neS9XRyBzdGFuZHBvaW50LCB3ZSBiZWxpZXZlIGFuIGFwcHJvYWNo PGJyPg0KJmd0OyZndDsgdGhhdCBkb2Vzbid0IGltcGFjdCBldmVyeSBtb2RlbCB3cml0dGVuIChp LmUuLCAjMikgaXMgc3VwZXJpb3IuPGJyPg0KJmd0OyZndDsgVGhlIGNvdW50ZXJwb2ludCB0byB0 aGlzIGlzIHRoYXQgdGhlIGNvbnZlbnRpb25zIGJhc2VkPGJyPg0KJmd0OyZndDsgYXBwcm9hY2gg KGkuZS4sICMxKSBpcyBhdmFpbGFibGUgdG9kYXkgYW5kIGJlaW5nIGZvbGxvd2VkIGluPGJyPg0K Jmd0OyZndDsgT3BlbkNvbmZpZyBkZWZpbmVkIG1vZGVscy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IFdlIHdvdWxkIGxpa2UgdG8gaGVhciBvcGluaW9ucyBvbiB0aGlzIGZyb20gdGhlIFdH IGJlZm9yZTxicj4NCiZndDsmZ3Q7IGRlY2xhcmluZyBvbmUgb2YgdGhlIGZvbGxvd2luZyBhcyB0 aGUgV0cgZGlyZWN0aW9uOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO0EpIG1vZGVscyB0aGF0IHdpc2ggdG8gc3VwcG9ydCBhcHBsaWVkIGNvbmZpZ3VyYXRp b24gTVVTVDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvbGxvdyBj b252ZW50aW9ucyBiYXNlZCBvbiBbMV0gLS0gYW5kIHRoZSBXRyBuZWVkcyB0bzxicj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvcm1hbGl6ZSB0aGVzZSBjb252ZW50aW9u cy48YnI+DQomZ3Q7Jmd0OyBvcjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtCKSBu byBleHBsaWNpdCBzdXBwb3J0IGlzIHJlcXVpcmVkIGZvciBtb2RlbHMgdG8gc3VwcG9ydDxicj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFwcGxpZWQgY29uZmlndXJhdGlv biAtLSBhbmQgdGhhdCB0aGUgV0cgbmVlZHMgdG88YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBmb3JtYWxpemUgYW4gb3BzdGF0ZSBzb2x1dGlvbiBiYXNlZCBvbiB0aGUg YXBwcm9hY2g8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkaXNjdXNz ZWQgaW4gWzRdIGFuZCBbNV0uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXZSBpbnRlbmQg dG8gY2xvc2Ugb24gdGhpcyBjaG9pY2UgYmVmb3JlIEJlcmxpbi48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IFRoYW5rIHlvdSw8YnI+DQomZ3Q7Jmd0OyBMb3UgKGFuZCBjby1jaGFpcnMpPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBbMV0gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3RhdGUtMDEiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vcGVuY29uZmlnLW5ldG1v ZC1vcHN0YXRlLTAxPC9hPjxicj4NCiZndDsmZ3Q7IFsyXSA8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQta3dhdHNlbi1uZXRtb2Qtb3BzdGF0ZS0wMiIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWt3YXRzZW4tbmV0bW9k LW9wc3RhdGUtMDI8L2E+PGJyPg0KJmd0OyZndDsgWzNdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC13aWx0b24tbmV0bW9kLW9wc3RhdGUteWFuZy0wMiIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbHRvbi1uZXRt b2Qtb3BzdGF0ZS15YW5nLTAyPC9hPjxicj4NCiZndDsmZ3Q7IFs0XTxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaG9lbnctbmV0bW9kLXJldmlz ZWQtZGF0YXN0b3Jlcy0wMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNjaG9lbnctbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wMDwvYT48YnI+ DQomZ3Q7Jmd0OyBbNV08YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC13aWx0b24tbmV0bW9kLXJlZmluZWQtZGF0YXN0b3Jlcy0wMCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbHRvbi1uZXRtb2Qt cmVmaW5lZC1kYXRhc3RvcmVzLTAwPC9hPjxicj4NCiZndDsmZ3Q7ICogLSBDaHJpcyBILiBhbmQg QWNlZSBMLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IG5l dG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGll dGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+DQomZ3Q7 PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5l dG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_A3DA5DFE5EBC49C6959FEB01C826AE56junipernet_-- From nobody Mon Jun 27 07:59:30 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A5412D7E7; Mon, 27 Jun 2016 07:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 f5Tg-5kJOPsX; Mon, 27 Jun 2016 07:59:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A0F12D7E9; Mon, 27 Jun 2016 07:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vdN1Lke/qUjhj4cKUeWsjggboTTRkBaflgeT5UKq3Nc=; b=Z5yj24BOZiflkAaWodCCKHEdk+cMwoyPXcK72H6D/gYEPHa6s/QGPjj/4gNDIsd4s7P7fZzSQSskw8LRrrVrLAsmC4SbXUAxA3xWSXvXHrSL0ItNDRa9xSVN24RCOdTfPcqbS+RamELDLZniEB7BDUEcAHZr37Exq04LPalIZf8= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.528.16; Mon, 27 Jun 2016 14:53:02 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Mon, 27 Jun 2016 14:53:02 +0000 From: Kent Watsen To: Andy Bierman , t.petch Thread-Topic: [netmod] Opstate solutions discussions: update and request for WGinput Thread-Index: AQHRyKtriAUTbkyKIUqPd3s4x2EFBZ/t+QmAgAKWo1OAAFwVAIAMRwuA Date: Mon, 27 Jun 2016 14:53:01 +0000 Message-ID: <7357209C-5F45-4ACE-AE18-F5BD9D2D1E2D@juniper.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.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.17.0.160611 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: e534cc52-b1f2-41bc-c245-08d39e9abce7 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:f67MvfrG823SAmuWQR6sDRcTlS0DC9t94e4ak9cXflreIvrEkoXqW/QrUtDR+sWekpPXQFyJQOiAnWssV2ur6pAtVI8u0CuLekZpVpJUMCvINSSOiB2hWUlS56xk06hxpopy5Yyq0spkQc3Afz4KWbbBtIOUzmhii2Ud3lLi8EOVB1kBdAHaTWDcNxqxY359SMdaYvpwVN0tEjgWzDPXDhZyZQ5zIJdF3nLB7SvMRRvBQNAn3jJsvl7AltKAVygvuH2LhH6K3Hq1YLdS61WPnoYfIIOuzvDBBkBoG8muJr/+PNEbLKWy17h6Rm7IKTJteWGr+SpRE2NGSZDSiei8+A==; 5:DmiJnV+uIR0i9dzxACqSjdttuTCM2Y3cnsc2ZhuZZ0OVsFkbOwHmp+hJCsy959V9yQNDWFPZ+LnjFF8SPeAkKlErxVg2sh0Bt8l62yae3V4NEJ40A8mFEBSM1+sRyMIaN0xKOumvwBol5pFjoq+fJQ==; 24:HequgMIp/tAgiLV07evRAUupuzXX7TJgNrYWhhD7Bmg1acW0SFYaFMlbN+hgZmR2BgbHSAQccfFOlhvm00NSrdLBIfbHA65g4q0CG+kgTtg=; 7:3dDMyJY+n6b0ON9czkT4gginF2l4WzWAPG8Uw9h72vGjjs4Jmg67V8F0vEUFOTz5ZMUYBgCroHzmMOtPJieAAiIL4Q2CUSlkNXokBO0MCX7SERqmfXhnZf5ZZQeajwB4uPe4oTOK+VVSI3iouh2cgVf9U1BSJ0hOhFHTOj84JGIeeSe60TkL2/2sYDiku22LQK55OvXcOODsaVM9+XMF/6lneqV1nEc3jIFTJ/THt8RWA85XhfZ4GXXPnLFNzxHp x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(189002)(199003)(5002640100001)(36756003)(3660700001)(92566002)(93886004)(15975445007)(77096005)(8676002)(122556002)(3846002)(99286002)(6116002)(102836003)(2900100001)(2950100001)(19625215002)(2906002)(10400500002)(101416001)(76176999)(54356999)(19580395003)(86362001)(4001350100001)(8666005)(83506001)(66066001)(97736004)(83716003)(19300405004)(81156014)(82746002)(8936002)(7846002)(586003)(106116001)(68736007)(106356001)(105586002)(87936001)(189998001)(4326007)(16236675004)(3280700002)(7736002)(11100500001)(81166006)(50986999)(5001770100001)(33656002)(7059030)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.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_7357209C5F454ACEAE18F5BD9D2D1E2Djunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2016 14:53:01.9968 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451 Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 14:59:28 -0000 --_000_7357209C5F454ACEAE18F5BD9D2D1E2Djunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W2FzIGEgY29udHJpYnV0b3JdDQoNClNvLCBJIHNlZSBhIHN0cm9uZyBwcmVmZXJlbmNlIGZvciBP cHRpb24gQiB3aGljaCBpcyBhbGwgdmVyeSBsb2dpY2FsLCBhcw0KQWNlZSBwb2ludHMgb3V0LiAg QnV0IE9wdGlvbiBCIEkgc2VlIGFzIGJlaW5nIGEgZnVuZGFtZW50YWwgY2hhbmdlIHRvDQpSRkM2 MjQxLCBzbyBpZiB0aGUgbmV0bW9kIFdHIHRha2VzIHRoYXQgZGVjaXNpb24sIHRoZW4gaXQgaXMg c3RhbXBpbmcgb24NCnRoZSBuZXRjb25mIFdHLiAgUGVyaGFwcyB0aGUgV0cgc2hvdWxkIGJlIG1l cmdlZCwgbm93IHRoYXQgNjAyMGJpcyBpcyBvbg0KaXRzIHdheSwgYnV0IGZvciB0aGUgbW9tZW50 LCBJIGJlbGlldmUgdGhhdCBjaGFuZ2VzIHRvIE5FVENPTkYgbmVlZCB0aGUNCmNvbnNlbnN1cyBv ZiAgdGhlIE5FVENPTkYgV0cuDQoNCkkgZGlzYWdyZWUuDQpJIGhhdmUgaW1wbGVtZW50ZWQgTkVU Q09ORiBhbmQgUkVTVENPTkYgYW5kIEkgZG8gbm90IHNlZSBhbnkgcHJvYmxlbXMgd2l0aA0KYWRk aW5nIGFkZGl0aW9uYWwgKG9wdGlvbmFsKSBkYXRhc3RvcmVzLg0KDQoNCktFTlQgPiBSaWdodCwg YnV0IG1hcHBpbmcgdGhlIHNvbHV0aW9uIHRvIGRyYWZ0cyBpcyBrZXkuICBGb3IgaW5zdGFuY2Us IHdvdWxkIHRoZXJlIGJlIG9uZSBkcmFmdCB0byBkZWZpbmUgdGhlIGNvbmNlcHR1YWwgbW9kZWwg YW5kIHRoZW4gdHdvIG90aGVyIGRyYWZ0cyBmb3IgbWFwcGluZyB0aGF0IG1vZGVsIHRvIE5FVENP TkYgYW5kIFJFU1RDT05GPyAgIEFuZCBpZiBzbywgdG8gVG9t4oCZcyBwb2ludCwgc2hvdWxkIHRo b3NlIGRyYWZ0cyBnbyB0aHJvdWdoIHRoZSBORVRDT05GIFdHPw0KDQoNCg0KVG9tIFBldGNoDQoN CkFuZHkNCg0KDQo= --_000_7357209C5F454ACEAE18F5BD9D2D1E2Djunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <5AC4020D1E42AE45BFDD9AAA5EB80510@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlthcyBhIGNvbnRyaWJ1dG9yXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCBJ IHNlZSBhIHN0cm9uZyBwcmVmZXJlbmNlIGZvciBPcHRpb24gQiB3aGljaCBpcyBhbGwgdmVyeSBs b2dpY2FsLCBhczxicj4NCkFjZWUgcG9pbnRzIG91dC4mbmJzcDsgQnV0IE9wdGlvbiBCIEkgc2Vl IGFzIGJlaW5nIGEgZnVuZGFtZW50YWwgY2hhbmdlIHRvPGJyPg0KUkZDNjI0MSwgc28gaWYgdGhl IG5ldG1vZCBXRyB0YWtlcyB0aGF0IGRlY2lzaW9uLCB0aGVuIGl0IGlzIHN0YW1waW5nIG9uPGJy Pg0KdGhlIG5ldGNvbmYgV0cuJm5ic3A7IFBlcmhhcHMgdGhlIFdHIHNob3VsZCBiZSBtZXJnZWQs IG5vdyB0aGF0IDYwMjBiaXMgaXMgb248YnI+DQppdHMgd2F5LCBidXQgZm9yIHRoZSBtb21lbnQs IEkgYmVsaWV2ZSB0aGF0IGNoYW5nZXMgdG8gTkVUQ09ORiBuZWVkIHRoZTxicj4NCmNvbnNlbnN1 cyBvZiZuYnNwOyB0aGUgTkVUQ09ORiBXRy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlzYWdyZWUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUgaW1wbGVtZW50ZWQg TkVUQ09ORiBhbmQgUkVTVENPTkYgYW5kIEkgZG8gbm90IHNlZSBhbnkgcHJvYmxlbXMgd2l0aDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWRkaW5n IGFkZGl0aW9uYWwgKG9wdGlvbmFsKSBkYXRhc3RvcmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPktFTlQgJmd0OyBSaWdodCwgYnV0IG1hcHBpbmcgdGhlIHNvbHV0 aW9uIHRvIGRyYWZ0cyBpcyBrZXkuJm5ic3A7IEZvciBpbnN0YW5jZSwgd291bGQgdGhlcmUgYmUg b25lIGRyYWZ0IHRvIGRlZmluZSB0aGUgY29uY2VwdHVhbCBtb2RlbCBhbmQgdGhlbiB0d28gb3Ro ZXIgZHJhZnRzIGZvciBtYXBwaW5nIHRoYXQgbW9kZWwgdG8gTkVUQ09ORiBhbmQgUkVTVENPTkY/ Jm5ic3A7Jm5ic3A7IEFuZCBpZiBzbywgdG8gVG9t4oCZcyBwb2ludCwgc2hvdWxkDQogdGhvc2Ug ZHJhZnRzIGdvIHRocm91Z2ggdGhlIE5FVENPTkYgV0c/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVG9tIFBldGNoPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_7357209C5F454ACEAE18F5BD9D2D1E2Djunipernet_-- From nobody Mon Jun 27 08:12:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8994E12D74A; Mon, 27 Jun 2016 08:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBTG2_rzC7Ge; Mon, 27 Jun 2016 08:12:02 -0700 (PDT) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45D512D7A0; Mon, 27 Jun 2016 08:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:References:In-Reply-To:Date: Subject:From:Cc:To:MIME-Version:Sender:Reply-To:Message-ID: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=o3QHBtsxsTm8lmyFgKRq2G7RUW3cTJUXbG+/DGGAiqc=; b=g+lk3P7A7CEj7e8VwvGYOQdLt COx6vO4xts18ItxpX0r00N8DRwd0fZADRygpoNMNmEfzb9XjR2HaiTpnF0K6Y4x/bobdeZ5Zb3lz9 IJoK4vMffbE9KUlPe0onYrgBKh7jvn+ts6d1zVhMR1JeVVllroV026YwNXYNeaVMGNJTWgZPtfMzX E9dQNiHCkeQtOp9tjdBFEsnj1OmUD8laAWAr2onRR4xE3V/JrJcMlaA0PaASrNEzb1eQgSp8YcG2j gfo1XcYJ5U/80V7K90G7haf45n+ABCRXTcdQIy6STRdoxzrxA/FQvUB4v0HTbAi4ofequORtOj5fU B2bn8Q8QA==; Received: from host-92-19-235-90.static.as13285.net ([92.19.235.90]:55429 helo=[IPv6:::ffff:192.168.1.119]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bHY3M-001jK3-PJ; Mon, 27 Jun 2016 16:02:27 +0100 MIME-Version: 1.0 To: Benoit Claise , NETMOD Working Group From: Jonathan Hansford Date: Mon, 27 Jun 2016 16:10:11 +0100 Importance: normal X-Priority: 3 In-Reply-To: <6771d54b-96f4-4d17-4a2e-6574f54aaa8c@cisco.com> References: <6771d54b-96f4-4d17-4a2e-6574f54aaa8c@cisco.com> Content-Type: multipart/alternative; boundary="_875040E6-4122-4D55-B46E-9CC85980FEB1_" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Message-Id: <20160627150230.B45D512D7A0@ietfa.amsl.com> Archived-At: Cc: "netmod-chairs@ietf.org" , "draft-ietf-netmod-yang-model-classification@ietf.org" Subject: Re: [netmod] draft-ietf-netmod-yang-model-classification-02.txt posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 15:12:04 -0000 --_875040E6-4122-4D55-B46E-9CC85980FEB1_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" General =E2=80=A2 Inconsistent capitalisation of =E2=80=9Cmodule=E2=80=9D? Abstract =E2=80=A2 s/analysis the/analysis of the 1. Introduction =E2=80=A2 The first paragraph is a little confusing. Should the first refer= ence to YANG replace =E2=80=9Cand YANG standards=E2=80=9D further on? =E2=80=A2 s/community gain/community gains =E2=80=A2 s/a type of module that have/a type of module that has =E2=80=A2 But, would it be better to have =E2=80=9CA number of module types= have created substantial discussion during the development of this documen= t including those concerned with topologies.=E2=80=9D Instead of =E2=80=9CA= n example of a type of module that have created substantial discussion duri= ng the development of this document is topologies.=E2=80=9D? =E2=80=A2 s/as well as in/as well as on =E2=80=A2 Figure 1 seems to take a long time appearing 2. First Dimension: YANG Data Model Abstraction Layers =E2=80=A2 s/YANG modules For/YANG modules. For =E2=80=A2 Given the third paragraph, should this be =E2=80=9CFirst Dimensio= n: YANG Data Model Abstraction Layers=E2=80=9D or =E2=80=9CFirst Dimension:= YANG Module Abstraction Layers=E2=80=9D? 2.1. Network Service YANG Modules =E2=80=A2 s/define services models/define service models 3. Second Dimension: Module Types =E2=80=A2 The first paragraph uses either/and (should be either/or) for mor= e than two alternatives. It would be better to have a bulleted list. 3.1. Standard YANG Modules =E2=80=A2 If the IEEE acronym is expanded, shouldn=E2=80=99t MEF also be ex= panded? 3.2. Vendor-specific YANG Modules and Extensions =E2=80=A2 s/contributed back to, or adopted by an SDO/contributed back to, = or adopted by, an SDO =E2=80=A2 =E2=80=9Clifecycles ... are=E2=80=9D or =E2=80=9Clifecycle ... is= =E2=80=9D. I suggest the former =E2=80=A2 s/than what is covered/than that covered 3.3. User-specific YANG Modules and Extensions =E2=80=A2 =E2=80=9Coperators service providers=E2=80=9D =E2=80=93 should th= at be =E2=80=9Coperators=E2=80=99 service providers=E2=80=9D? =E2=80=A2 s/what is provided/that provided =E2=80=A2 s/include ability/include the ability =E2=80=A2 =E2=80=9Clifecycles ... are=E2=80=9D or =E2=80=9Clifecycle ... is= =E2=80=9D. I suggest the former 4. Adding The Classification Type to YANG Module Catalogs =E2=80=A2 s/Such catalog/Such a catalog =E2=80=A2 s/to YANG module/to the YANG module =E2=80=A2 s/A extensible/An extensible =E2=80=A2 =E2=80=9Cdefinite=E2=80=9D or =E2=80=9Cdefinitive=E2=80=9D? 5. Security Considerations =E2=80=A2 Remove the closing double quote 8. Change log [RFC Editor: Please remove] =E2=80=A2 s/epxlain/explain Jonathan From: Benoit Claise Sent: 27 June 2016 11:40 To: NETMOD Working Group Cc: netmod-chairs@ietf.org; draft-ietf-netmod-yang-model-classification@iet= f.org Subject: [netmod] draft-ietf-netmod-yang-model-classification-02.txt posted Dear all, We have posted draft-ietf-netmod-yang-model-classification version 2 https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classificatio= n/ We believe that we have addressed all the open issues, and that this=20 draft is ready for WGLC. Regards, Carl, Dean, and Benoit _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_875040E6-4122-4D55-B46E-9CC85980FEB1_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

General

=C2= =B7    &nb= sp;    Inconsistent capitalis= ation of =E2=80=9Cmodule=E2=80=9D?

 

Abstract

=C2=B7       = ;  s/analysis the/analysis of the

 

1. Introductio= n

=C2=B7         The first paragraph is a little confusing. Should the first = reference to YANG replace =E2=80=9Cand YANG standards=E2=80=9D further on?<= /p>

=C2=B7         s/community gain/community gains

=C2=B7   &= nbsp;     s/a type of mo= dule that have/a type of module that has

= =C2=B7    =      But, would it be be= tter to have =E2=80=9CA number of module types have created substantial dis= cussion during the development of this document including those concerned w= ith topologies.=E2=80=9D Instead of =E2=80=9CAn example of a type of module= that have created substantial discussion during the development of this do= cument is topologies.=E2=80=9D?

=C2=B7=          s/as well as in/as well as on

=C2=B7 =         F= igure 1 seems to take a long time appearing

 

2.=C2=A0 First Dimension: YANG Data Model Abstr= action Layers

=C2=B7         s/YANG modules For/YANG modules. For

=C2=B7&nb= sp;        Given the third paragraph, should this be =E2=80=9CFirst Dimension: YANG = Data Model Abstraction Layers=E2=80=9D or =E2=80=9CFirst Dimension: YANG Mo= dule Abstraction Layers=E2=80=9D?

 =

2.1.=C2=A0 Network Service YANG Modules

= =C2=B7  = ;       s/defi= ne services models/define service models

 = ;

3.=C2=A0 Second Dimension: Module Types

=

=C2=B7&nb= sp;        The first paragraph uses either/and (should be either/or) for more than t= wo alternatives. It would be better to have a bulleted list.

 

3.1.=C2=A0 Standard YAN= G Modules

=C2=B7         If the IEEE acronym is expanded, shouldn=E2=80=99t MEF also b= e expanded?

 

3.2.=C2=A0 Vendor-specific YANG Modules and Extensions

=C2=B7 &nb= sp;       s/co= ntributed back to, or adopted by an SDO/contributed back to, or adopted by,= an SDO

=C2=B7         =E2=80=9Clifecycles ... are=E2=80=9D or =E2=80=9Clife= cycle ... is=E2=80=9D. I suggest the former

= =C2=B7    =      s/than what is cove= red/than that covered

 

3.3.=C2=A0 User-specific YANG Modules and Extensions

=C2=B7&= nbsp;        =E2=80=9Coperators service providers=E2=80=9D =E2=80=93 should that be = =E2=80=9Coperators=E2=80=99 service providers=E2=80=9D?

=C2=B7 &nbs= p;       s/wha= t is provided/that provided

=C2=B7      &= nbsp;  s/include ability/include the ab= ility

=C2=B7         =E2=80=9Clifecycles ... are=E2=80=9D or =E2=80=9Clifecycl= e ... is=E2=80=9D. I suggest the former

 =

4.=C2=A0 Adding The Classification Type to Y= ANG Module Catalogs

=C2=B7        = ; s/Such catalog/Such a catalog

=C2=B7&n= bsp;        s/to YANG module/to the YANG module

=C2= =B7    &nb= sp;    s/A extensible/An exte= nsible

=C2=B7         =E2=80=9Cdefinite=E2=80=9D or =E2=80=9Cdefinitive=E2=80= =9D?

 

5.= =C2=A0 Security Considerations

=C2=B7       = ;  Remove the closing double quote

<= p class=3DMsoNormal> 

8.=C2=A0 Chan= ge log [RFC Editor: Please remove]

=C2=B7       = ;  s/epxlain/explain


Jonathan

 

From: Benoit Claise<= br>Sent: 27 June 2016 11:40
To: NETMOD Working Group
Cc: netmod-chairs@ietf.org; draft-ietf-netmod-yang-model-classi= fication@ietf.org
Subject: [netmod] draft-ietf-netmod-yang-mo= del-classification-02.txt posted

 =

Dear all,

&nbs= p;

We have posted draft-ietf-netmod-yang-mode= l-classification version 2

 

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-m= odel-classification/

 

We believe that we have addressed all the open issues, and tha= t this

draft is ready for WGLC.

 

Regards, Carl, Dean, and Be= noit

 

____= ___________________________________________

netmod = mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod

 

= --_875040E6-4122-4D55-B46E-9CC85980FEB1_-- From nobody Mon Jun 27 09:47:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1111912D808 for ; Mon, 27 Jun 2016 09:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_esazB-kHqg for ; Mon, 27 Jun 2016 09:47:26 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::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 CA70512D825 for ; Mon, 27 Jun 2016 09:47:25 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id j3so26977413vkb.0 for ; Mon, 27 Jun 2016 09:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=afMku1plFqFxPPYEKcTXhQq+btYqaX5e/bW517XnBo0=; b=KdLfpxoC0PVrzgy/rApMi5C2xPIYQiqJd8139nPRHkWUkvgdeVKrifYwLEm/4ahxcp HSN7z4zmQgQiLN+4USuvnUwXPcViydY3CglVvA+jKsBFhUFd4LTduauRZXfsgz5TAG60 iv2bKgMVNUFru4jYqRVZkhNYTSH0OyDtjwMlLW2kDNu8xP5ewNKPuBg8dkirAjSsZ8cJ 4L20qAs5q/HGDS1/naUp+gOuxzuRmmgvAR46WC8OgLTa16HPqlORizMkf5k/4kNRaA/o IXvusvwRVAZRKWTbF3siNQnqsxQLW7izNdFuVthJMAg9Xm2n5MG3Mhe3S0NE0DA49P07 sksA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=afMku1plFqFxPPYEKcTXhQq+btYqaX5e/bW517XnBo0=; b=dZqwgKu+r0zWSiGch31tzWbZAG9mQ5+D+jfSXBuw3bivqMi1YnZQ4E2LlfWlHGUpcx pv/DjjfBt0vfdg7jE33zWHFVwT1Vfhyn5XEzFeu3PMYHiUbIC34Zp9rXt1Nr/dAXGy5J BZmPtDrpsXvB8tZAmjBCPMa65ksDYCj6mWEpzmMt3NRJv8fMVn88t/JiZTyGk0OlkOeD cY0wC+2DIDyN7FE4hfBbK3sVoJTJV6nm2I2S9RbsKTAXJA3p5mzDWpzXXUNdj8Ly4NZa Wp64tIx2x0rnQzKAseRJHglG7p1Ed4qVT878GFD+2T0TMv+xxf7i0Oa7jMvxnWHKXGJv hqgQ== X-Gm-Message-State: ALyK8tJvxHcu45eLVLom9QrR5iDNyuLgrvUSaO2U9JcOdIiW17kr5zhnq7z2kuyEKworjN2n7J4uRSrDfjD0DA== X-Received: by 10.31.108.216 with SMTP id j85mr8898245vki.68.1467046044891; Mon, 27 Jun 2016 09:47:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Mon, 27 Jun 2016 09:47:24 -0700 (PDT) In-Reply-To: <7357209C-5F45-4ACE-AE18-F5BD9D2D1E2D@juniper.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> <7357209C-5F45-4ACE-AE18-F5BD9D2D1E2D@juniper.net> From: Andy Bierman Date: Mon, 27 Jun 2016 09:47:24 -0700 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11478f34601193053645462c Archived-At: Cc: "netmod-chairs@ietf.org" , netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 16:47:28 -0000 --001a11478f34601193053645462c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 27, 2016 at 7:53 AM, Kent Watsen wrote: > [as a contributor] > > > > So, I see a strong preference for Option B which is all very logical, as > Acee points out. But Option B I see as being a fundamental change to > RFC6241, so if the netmod WG takes that decision, then it is stamping on > the netconf WG. Perhaps the WG should be merged, now that 6020bis is on > its way, but for the moment, I believe that changes to NETCONF need the > consensus of the NETCONF WG. > > > > I disagree. > > I have implemented NETCONF and RESTCONF and I do not see any problems wit= h > > adding additional (optional) datastores. > > > > > > KENT > Right, but mapping the solution to drafts is key. For instance, > would there be one draft to define the conceptual model and then two othe= r > drafts for mapping that model to NETCONF and RESTCONF? And if so, to > Tom=E2=80=99s point, should those drafts go through the NETCONF WG? > > > I don't have any plans to implement this new work. I expect it to be similar to the "candidate" datastore. If I do not support the candidate datastore, the added cost to my implementation is ZERO. RFC 6241 uses an extensible design for datastores. (Parameter is a container with a choice of N empty leafs). Adding a new leaf that represents a datastore is almost free in NETCONF. (a few augment statements). The and operations do not specify an exact validation procedure for datastores. YANG defines the validation rules for datastores. IMO YANG needs to be revised, not NETCONF. > > > > Tom Petch > > > > Andy > > > > > Andy --001a11478f34601193053645462c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 27, 2016 at 7:53 AM, Kent Watsen <kwatsen@juniper.net> wrote:

[as a contributor]

=C2=A0

So, I see a strong preference for Option B which is = all very logical, as
Acee points out.=C2=A0 But Option B I see as being a fundamental change to<= br> RFC6241, so if the netmod WG takes that decision, then it is stamping on the netconf WG.=C2=A0 Perhaps the WG should be merged, now that 6020bis is = on
its way, but for the moment, I believe that changes to NETCONF need the
consensus of=C2=A0 the NETCONF WG.

=C2=A0

I disagree.

I have implemented NETCONF and RESTCONF and I do not= see any problems with

adding additional (optional) datastores.

=C2=A0

=C2=A0

KENT > Right, but mapping the solution to drafts = is key.=C2=A0 For instance, would there be one draft to define the conceptu= al model and then two other drafts for mapping that model to NETCONF and RE= STCONF?=C2=A0=C2=A0 And if so, to Tom=E2=80=99s point, should those drafts go through the NETCONF WG?

=C2=A0



I don't ha= ve any plans to implement this new work.
I expect it to be simila= r to the "candidate" datastore.
If I do not support the= candidate datastore, the added cost to
my implementation is ZERO= .

RFC 6241 uses an extensible design for datastore= s.
(Parameter is a container with a choice of N empty leafs).
Adding a new leaf that represents a datastore is almost free in NETC= ONF.
(a few augment statements).

The <= ;edit-config> and <commit> operations do not specify an exact vali= dation procedure
for datastores. YANG defines the validation rule= s for datastores.
IMO YANG needs to be revised, not NETCONF.


=C2=A0

=C2=A0


Tom Petch

=C2=A0

Andy

=C2=A0

=C2=A0


Andy

--001a11478f34601193053645462c-- From nobody Mon Jun 27 11:14:17 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6DA12D1B7 for ; Mon, 27 Jun 2016 11:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 nScnxBptLNbc for ; Mon, 27 Jun 2016 11:14:12 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA7412D67B for ; Mon, 27 Jun 2016 11:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LCqIgEwBfvMrxTWRoVHrtKcTN2aFCkem6uQCQV+DcYI=; b=YTqCs6z9blArQLNNOFBIdO98UVqj0ZkcT02ga49+G1i1ruVJWyjl/30Go7HRQmIHkh/2NZMlNLWfsO/3P5tCTuPXBOtaqqiADr2TFuzWpOYOMziy5wUYsAxOaDoI87FjME9tMSc5Ijl8lAnpmcP0MqhDl9NDCNCEDNTu3Q9pE4k= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.528.16; Mon, 27 Jun 2016 18:14:08 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Mon, 27 Jun 2016 18:14:07 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [netmod] Opstate solutions discussions: update and request for WGinput Thread-Index: AQHRyKtriAUTbkyKIUqPd3s4x2EFBZ/t+QmAgAKWo1OAAFwVAIAMRwuAgABjBgD//9UsgA== Date: Mon, 27 Jun 2016 18:14:07 +0000 Message-ID: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> <7357209C-5F45-4ACE-AE18-F5BD9D2D1E2D@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.17.0.160611 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: 2919192e-3f5b-4372-51c7-08d39eb6d4af x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:lyieOxvDIOcPIvSPoCr0NCvmM/oSDoV0PvYOzgz7/7Wb3rb6Nc4tHG1uDdyNSsCDJWz1cRZqM6VdWSDD0i4L0FksWWcnVra+2Rcr3d3BKrMtYvhsg6ShMBU/trV3EIIZPpBGigIxeX+lkdd104ahcFZj+EdWkpT1iy100MsoOirGEF7JDBVFbGSqhVs5aSwtwSR/kBassG4r7LufCe+F4UIWJ5z0EG4e6Vi5WyktGlZ9dsBgvaVvutQ3Q0j0zEdr+G/J7w29oK4MHMxuRDfkEi1uZBE2LLHuOX1OFHm0n7GwUDkeDk26McC4qGEKtgsEhAvdyUsvr92RGPD9U1KgPg==; 5:KrnmeHcgMikNFrOBn8OPzhhbR7VyTwWEIfWdimuMu03/p189HfClQ5gZDFwl9+ukvVX7trgk9VZ2DUAWTNuuXS9SNtIi0t3O53M1f0zj7Cr9krtqeicH2JlHbE3iEHmC3yJ1RrJxuijcfz0vUTOYBg==; 24:3kvdY6+FP7TTkrIYYZ0FGQQ2NS+QZ8PCrF3WQLaf9fyXaKs1Efxzmb/chrziLmTPB2wP8oi9kkPY0Rkqyixssl3OPSysLO1mZrDh1rPyjQY=; 7:2kGunpCQVMUEEGrCJMP4p4fZRAVazaSP4XKMwiVVYU8Jbn0BJuGTtJ8cgyfVF7vCwe01gaxKrCm79EDRy9H8hFWYuTHJ6gEHUkQB9+gvg1Ojn23ESVymvSfDdN4riqY3IzfeEtz5tobWjsQJnGIdT8ikBz66ECO7/mFHlFhrXXnIAXuPESh7p5eMEIhQeI0uhjwssiznliSZj4LvMZTkR19IDxzeFiLk2X/2Gh3Qfhca2snDFi2ykOh/v0ANp3/3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(5002640100001)(36756003)(3660700001)(92566002)(15975445007)(77096005)(8676002)(122556002)(3846002)(6116002)(99286002)(102836003)(93886004)(2900100001)(2950100001)(19625215002)(2906002)(10710500007)(10400500002)(76176999)(101416001)(54356999)(19580395003)(86362001)(4001350100001)(8666005)(2420400007)(97736004)(83506001)(66066001)(83716003)(81156014)(82746002)(8936002)(7846002)(106116001)(586003)(7110500001)(68736007)(87936001)(189998001)(105586002)(4326007)(16236675004)(558084003)(110136002)(3280700002)(7736002)(106356001)(15650500001)(19300405004)(81166006)(50986999)(33656002)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.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_D04B0CA3487C4E8EA4E5ED67AA0B719Bjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2016 18:14:07.8167 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451 Archived-At: Cc: netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 18:14:16 -0000 --_000_D04B0CA3487C4E8EA4E5ED67AA0B719Bjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJTU8gWUFORyBuZWVkcyB0byBiZSByZXZpc2VkLCBub3QgTkVUQ09ORi4NCg0KTm8sIFJGQzYy NDEgZGVmaW5lcyBpZXRmLW5ldGNvbmYueWFuZyB0aGF0IGhhcmRjb2RlcyBkYXRhc3RvcmUgbmFt ZXMsIHNvIGl0IG5lZWRzIHRvIGJlIHVwZGF0ZWQgb3IgbWF5YmUgZXZlbiByZXBsYWNlZC4NCg0K S2VudA0KDQo= --_000_D04B0CA3487C4E8EA4E5ED67AA0B719Bjunipernet_ 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 bGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyBJTU8gWUFORyBuZWVkcyB0byBiZSByZXZpc2VkLCBub3QgTkVUQ09ORi48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLCBSRkM2MjQxIGRlZmluZXMgaWV0Zi1uZXRjb25m LnlhbmcgdGhhdCBoYXJkY29kZXMgZGF0YXN0b3JlIG5hbWVzLCBzbyBpdCBuZWVkcyB0byBiZSB1 cGRhdGVkIG9yIG1heWJlIGV2ZW4gcmVwbGFjZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPktlbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D04B0CA3487C4E8EA4E5ED67AA0B719Bjunipernet_-- From nobody Mon Jun 27 11:22:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA0012D7A4 for ; Mon, 27 Jun 2016 11:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzTM9Z0X1HjY for ; Mon, 27 Jun 2016 11:22:00 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 6CB4C12D13F for ; Mon, 27 Jun 2016 11:22:00 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id j2so243099081vkg.2 for ; Mon, 27 Jun 2016 11:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BlbpDBrWuSqni0o2ozCitkjrhhutz8ybThynL2OgG+M=; b=vZbbYakwik6br5IHufXm1VbhEbZCr4oukevDS8s+ed/ksykoYZAxxzd0EgY4N5yDHk DxVvvQXnsTQLfn3oU8GtFm1XDgnb1df1nVd2NPvjq8hcMedIeuNuw5Do+3XDqHa/ZF1Q cDs1xkclO/0Bi8lPXOXmUu2ABAgVYJcsjJuS2TB8eGEBXwISKfdrlGm+OEbt8ovFx9uW OHyA5bw6uKpuPNOvTE+hDG3Cah1KsLIYosRuQoflXQ3AKw+5uVYRshojbldygNYb1urj bNrDiV1QzCJQOBuCHL+JMDBcmeZquLzBr6nbOcbpg/poD492mvRGxzev6BWXEtCqjO3A nZrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BlbpDBrWuSqni0o2ozCitkjrhhutz8ybThynL2OgG+M=; b=C/piLI//pGQo2ZKKw+zGPH+PO7yXu0G7rDQxDEM75tKNOuk3l0dLvKHj2vI1UB4IEk hsqi6BNIr07mX9CVxkpEY3Wv6CCV38mHn3DjLXOYEV3+foJeE/4dFApXGX/AwV19Jem0 azQbw0l6AMYHUj5r1M15XGCr35p9wTI1ZtOF4SfH6j3ieLjGVw9eRZadqaf3x0gdBgZV +EJgwrTb8TX7idnZLcNbEXPEyrymwSF/A6f8yoQFiuluv2C3VsNH/Hy8TAk1N3kerxTZ T++jSQjjEsk61IgDLfcev+n4c2UMqi925aHyX8Pn/2HD2s0+sfrOV9c0JRH+a7GxJS9l h04A== X-Gm-Message-State: ALyK8tJl2s7+ZCv6PmQSOquFRphMHG+byBc2oIZ7jbqXCVu3JMK34RLiFKTq35UL52lD9Jl0PrsOk0TSWeyK/A== X-Received: by 10.176.64.166 with SMTP id i35mr8885001uad.105.1467051719551; Mon, 27 Jun 2016 11:21:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Mon, 27 Jun 2016 11:21:58 -0700 (PDT) In-Reply-To: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> <7357209C-5F45-4ACE-AE18-F5BD9D2D1E2D@juniper.net> From: Andy Bierman Date: Mon, 27 Jun 2016 11:21:58 -0700 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=94eb2c1243b29c822205364698c1 Archived-At: Cc: netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 18:22:02 -0000 --94eb2c1243b29c822205364698c1 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 27, 2016 at 11:14 AM, Kent Watsen wrote: > > IMO YANG needs to be revised, not NETCONF. > > > > No, RFC6241 defines ietf-netconf.yang that hardcodes datastore names, so > it needs to be updated or maybe even replaced. > > > Hard-wired to allow augments from a different module: augment /nc:get-config/nc:input/nc:source/nc:config-choice { case operational { leaf operational { type empty; if-feature operational; } } } Kent > > > Andy --94eb2c1243b29c822205364698c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


--94eb2c1243b29c822205364698c1-- From nobody Mon Jun 27 11:41:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D74812D67B for ; Mon, 27 Jun 2016 11:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 5rbwpUMjUmGZ for ; Mon, 27 Jun 2016 11:41:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DDE12D627 for ; Mon, 27 Jun 2016 11:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1nZg/hdIuZjIOHtaARADC3ST+XzGzccZXzzTrjwWJmI=; b=jOtNIZ7QWIBg8IQ4CAatHREQSDMAN4WuN2fjLej6OxWWEEcDI7++gSN5icFHYlJ4UBADin6U+FMNv9ZQ0uhwFaCM6OedXE1CGyJn2lYnG/DOfQD4lMKEMzyiIQ8llc+wfUaZKzGOGckZRc9GtqbLH/9F0P7/S7PLT5LsqYk90bY= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (TLS) id 15.1.528.16; Mon, 27 Jun 2016 18:41:44 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Mon, 27 Jun 2016 18:41:44 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [netmod] Opstate solutions discussions: update and request for WGinput Thread-Index: AQHRyKtriAUTbkyKIUqPd3s4x2EFBZ/t+QmAgAKWo1OAAFwVAIAMRwuAgABjBgD//9UsgIAARUAA///CdQA= Date: Mon, 27 Jun 2016 18:41:43 +0000 Message-ID: <1184DECF-7A25-4074-B840-77367F475DF1@juniper.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> <7357209C-5F45-4ACE-AE18-F5BD9D2D1E2D@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.17.0.160611 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: f8ea116e-bbe4-491e-f1b7-08d39ebaaff6 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:PVCOTgrGqAhjmwwYdFpwMXDGTIyEYyJnuSVCMhicCMMBSx5pKkTojzBH4bGKDzsMypzSbSD7oV4qJTp2SoJg1SvRJyFAMwhSnOAA+dqQosqw+A8YnxzuRy39OLu0fQ1tOQHuaRqSklcUPJ7PkkusPJ5ZURNmnkxFjWrkXXX1bX3WC788EgRO2levnfY/bYno1hvoaVtarWvpPLgI0kgw5Zb94gPIl3ECYzBtmEP9tQUDwQWY9nCYk/RTwcxg0Ln5hgvzsAbp9+WRaiLwZZzXEo1GCqsZNM2heh7EmBeBSaDekGsj5vUph9IK0Jc7VCgmB4VvvicliCz2srmNbu6O1g==; 5:6W4LXYnBmBWVFPltOCt3cfV9urrnSi79WCdIATY8lHvgtGAClsoN7cAuqWQU+z/YQA1xjr2F9YnarufTJCXx+N50R2Qrlv4Pz8hlGYe12HsrQP4lw4yCTEpBr0oO8TdUNBP748/I/dEkvRG8rTLntw==; 24:I4PS5qfJfee9GTyujgBH07vP+QjDpikhjN+VqCjXiLDHjam2y2jtWMlwWRa5e4uXaUfq0LZcZTN5MnxE3eiev7hE5ugVlaRXJF3x9COzazQ=; 7:N1zC1HZa4CZn7u8fzeVgPxFOyNfhmrXwAimNDGEzeBq2i8rXOscreTU33qN0UdoP5Yf26C0SU1lr0qHQ56t7Xwo054qqeFGhgmqzb3yioz4RTxUcoX4zhHAXjsuPcBLqPMqgsUmdDhI9HivWkphjMQ1xwbhYBKCV6W2wc61q8HpbJjVBuPEPkaQ5dTHmE0BAeVBt6IuQRsFw7q9pcVDEexVUf6H6KEQheUt8MD+ZPZhr9vDTlWVyjwRA7aMOu49v x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(178726229863574)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(189002)(199003)(3660700001)(33656002)(3280700002)(8666005)(102836003)(3846002)(6116002)(2420400007)(66066001)(15650500001)(106356001)(105586002)(11100500001)(87936001)(106116001)(97736004)(4001350100001)(15975445007)(189998001)(82746002)(36756003)(2950100001)(83506001)(101416001)(81166006)(81156014)(2900100001)(92566002)(77096005)(586003)(4326007)(8676002)(76176999)(7736002)(93886004)(8936002)(10400500002)(16236675004)(83716003)(19300405004)(122556002)(5002640100001)(50986999)(54356999)(86362001)(7110500001)(110136002)(19625215002)(19580405001)(10710500007)(7846002)(68736007)(2906002)(99286002)(19580395003)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.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_1184DECF7A254074B84077367F475DF1junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2016 18:41:43.6769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449 Archived-At: Cc: netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 18:41:51 -0000 --_000_1184DECF7A254074B84077367F475DF1junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpSaWdodCwgdGhhdCB3b3VsZCBiZSDigJx1cGRhdGluZ+KAnSBpdCwgYW5kIFJFU1RDT05GIHdv dWxkIG5lZWQgYSBzaW1pbGFyIHRoaW5nLiAgTXkgcG9pbnQsIGFuZCBJIHRoaW5rIFRvbeKAmXMg dG9vLCBpcyB0aGF0IGl0IG1ha2VzIHNlbnNlIHRoYXQgdGhlIE5FVENPTkYgKG5vdCBORVRNT0Qp IFdHIGRvIHRoZSBwcm90b2NvbCBtYXBwaW5nIHdvcmsuICBEbyB5b3UgZGlzYWdyZWU/DQoNCksu DQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0KRGF0ZTogTW9uZGF5 LCBKdW5lIDI3LCAyMDE2IGF0IDI6MjEgUE0NClRvOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5p cGVyLm5ldD4NCkNjOiAidC5wZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb20+LCAibmV0bW9kQGll dGYub3JnIiA8bmV0bW9kQGlldGYub3JnPiwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4N ClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBPcHN0YXRlIHNvbHV0aW9ucyBkaXNjdXNzaW9uczogdXBk YXRlIGFuZCByZXF1ZXN0IGZvciBXR2lucHV0DQoNCg0KDQpPbiBNb24sIEp1biAyNywgMjAxNiBh dCAxMToxNCBBTSwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRz ZW5AanVuaXBlci5uZXQ+PiB3cm90ZToNCj4gSU1PIFlBTkcgbmVlZHMgdG8gYmUgcmV2aXNlZCwg bm90IE5FVENPTkYuDQoNCk5vLCBSRkM2MjQxIGRlZmluZXMgaWV0Zi1uZXRjb25mLnlhbmcgdGhh dCBoYXJkY29kZXMgZGF0YXN0b3JlIG5hbWVzLCBzbyBpdCBuZWVkcyB0byBiZSB1cGRhdGVkIG9y IG1heWJlIGV2ZW4gcmVwbGFjZWQuDQoNCg0KDQpIYXJkLXdpcmVkIHRvIGFsbG93IGF1Z21lbnRz IGZyb20gYSBkaWZmZXJlbnQgbW9kdWxlOg0KDQoNCmF1Z21lbnQgL25jOmdldC1jb25maWcvbmM6 aW5wdXQvbmM6c291cmNlL25jOmNvbmZpZy1jaG9pY2Ugew0KICAgIGNhc2Ugb3BlcmF0aW9uYWwg ew0KICAgICAgbGVhZiBvcGVyYXRpb25hbCB7DQogICAgICAgICB0eXBlIGVtcHR5Ow0KICAgICAg ICAgaWYtZmVhdHVyZSBvcGVyYXRpb25hbDsNCiAgICAgIH0NCiAgIH0NCn0NCg0KDQpLZW50DQoN Cg0KDQpBbmR5DQoNCg== --_000_1184DECF7A254074B84077367F475DF1junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <0655740FCB74234F9C8BD15ABD2BDA6D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5SaWdodCwgdGhhdCB3b3VsZCBi ZSDigJx1cGRhdGluZ+KAnSBpdCwgYW5kIFJFU1RDT05GIHdvdWxkIG5lZWQgYSBzaW1pbGFyIHRo aW5nLiZuYnNwOyBNeSBwb2ludCwgYW5kIEkgdGhpbmsgVG9t4oCZcyB0b28sIGlzIHRoYXQgaXQg bWFrZXMgc2Vuc2UgdGhhdCB0aGUgTkVUQ09ORiAobm90IE5FVE1PRCkgV0cgZG8gdGhlIHByb3Rv Y29sIG1hcHBpbmcNCiB3b3JrLiZuYnNwOyBEbyB5b3UgZGlzYWdyZWU/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+Sy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpO2NvbG9yOmJsYWNrIj5BbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBKdW5lIDI3LCAyMDE2IGF0IDI6MjEgUE08YnI+DQo8 Yj5UbzogPC9iPktlbnQgV2F0c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0Ozxicj4NCjxi PkNjOiA8L2I+JnF1b3Q7dC5wZXRjaCZxdW90OyAmbHQ7aWV0ZmNAYnRjb25uZWN0LmNvbSZndDss ICZxdW90O25ldG1vZEBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0bW9kQGlldGYub3JnJmd0OywgTG91 IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6 IFtuZXRtb2RdIE9wc3RhdGUgc29sdXRpb25zIGRpc2N1c3Npb25zOiB1cGRhdGUgYW5kIHJlcXVl c3QgZm9yIFdHaW5wdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdW4gMjcsIDIwMTYgYXQgMTE6MTQgQU0sIEtl bnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0 OyBJTU8gWUFORyBuZWVkcyB0byBiZSByZXZpc2VkLCBub3QgTkVUQ09ORi48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5ObywgUkZDNjI0MSBkZWZpbmVzIGlldGYtbmV0Y29uZi55 YW5nIHRoYXQgaGFyZGNvZGVzIGRhdGFzdG9yZSBuYW1lcywgc28gaXQgbmVlZHMgdG8gYmUgdXBk YXRlZCBvciBtYXliZSBldmVuIHJlcGxhY2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXJkLXdpcmVkIHRvIGFsbG93IGF1Z21lbnRzIGZy b20gYSBkaWZmZXJlbnQgbW9kdWxlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmF1Z21lbnQgL25jOmdldC1jb25maWcvbmM6aW5wdXQvbmM6 c291cmNlL25jOmNvbmZpZy1jaG9pY2UgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBjYXNlIG9wZXJhdGlvbmFsIHs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgJm5ic3A7IGxlYWYgb3BlcmF0aW9uYWwgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3R5cGUgZW1wdHk7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aWYtZmVhdHVyZSBv cGVyYXRpb25hbDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt9PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj59PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+S2VudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_1184DECF7A254074B84077367F475DF1junipernet_-- From nobody Mon Jun 27 12:03:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CC612D09C for ; Mon, 27 Jun 2016 12:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eofr1bnApMpf for ; Mon, 27 Jun 2016 12:03:45 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 3B5B812D1B7 for ; Mon, 27 Jun 2016 12:03:45 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id c2so214241633vkg.1 for ; Mon, 27 Jun 2016 12:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IHI2xViOK1PcbegWKqXg5iDL0ZG9WYYj2OsTAnHHCwk=; b=tqUTZR2XvqSFimOtZdiGMPUyXTcuZRS5qkicQ1J288u1N5luFAa9YfRTUHwm05PTk9 Wny4sYp9pYROHUM7Jk+k5/RdRBRznqV8yxoIlzTv0G4yq9jZ23ZJF6WCK4ajl+XQ/bVY 47veASLJH9Fz3XsglLiKicwnVPliXxkSJHAbnFJgl2XIEHLNlalp3ym9/ehv5jvHsVuJ 9tG+yfxOsOcG0Iz3E0rCfpkFamyMy/rTSMvqLyQMZw0xoOeGXXQi0EzZaDLO9DktrVU6 RPsi9755dCBBX1GseIZHrXOERqJbWg39i4d/a+oj1CV69kncx6UksNblreqaP/qzBOd8 bKYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IHI2xViOK1PcbegWKqXg5iDL0ZG9WYYj2OsTAnHHCwk=; b=AlZCGN8a/reTx0UVl253S3+sQJC2q6HAth+TePROddepfIHJOVKQhdnidFW8i8TWzy CFYE3Dkn7fDNXb6yGy1Els7nmwUbpqM1Ircv08BlpYkAC5oT1m8v6po9Oo5dDrb9z1YM gLLqp4xfc/jQYYsibLqYd+m+tGpxc4KYkQ78me1/z8/uL0OTVpgHqfKZYOhyPJREvW16 GX5z8x6dZzORKuwemezWV+fg3vdl9yRRUIDEmNFQzcWxnQu7sEarTnCytAjwi9TXkYlG R3VYu36zMbriMmB8BMrYnlfjiiTn503ZO7337H03h+ZkAlYbKvy+tzLM36YPfExC7K8y YbZQ== X-Gm-Message-State: ALyK8tIOW4TK+JaUf9WJgy0nqX7I0eXDEiStMwJrKnF4J3k7C1nYeAPZ4dT7iVVeMKUopST0kFzZBvYKk6TwXg== X-Received: by 10.31.108.216 with SMTP id j85mr9278424vki.68.1467054224364; Mon, 27 Jun 2016 12:03:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.20.2 with HTTP; Mon, 27 Jun 2016 12:03:43 -0700 (PDT) In-Reply-To: <1184DECF-7A25-4074-B840-77367F475DF1@juniper.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> <014201d1ca10$403eccc0$4001a8c0@gateway.2wire.net> <7357209C-5F45-4ACE-AE18-F5BD9D2D1E2D@juniper.net> <1184DECF-7A25-4074-B840-77367F475DF1@juniper.net> From: Andy Bierman Date: Mon, 27 Jun 2016 12:03:43 -0700 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11478f34e8ed4e0536472d0e Archived-At: Cc: netmod WG Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 19:03:47 -0000 --001a11478f34e8ed4e0536472d0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 27, 2016 at 11:41 AM, Kent Watsen wrote: > > > Right, that would be =E2=80=9Cupdating=E2=80=9D it, and RESTCONF would ne= ed a similar > thing. My point, and I think Tom=E2=80=99s too, is that it makes sense t= hat the > NETCONF (not NETMOD) WG do the protocol mapping work. Do you disagree? > > > Actually, YANG is designed such that the original document does not need to be aware of any augmentations. I agree that protocol operations are not in scope for NETMOD WG. This is not clear to anybody who reads RFC6020bis, where NETCONF definitions are clearly intermixed with the data modeling language. > K. > Andy > > > *From: *Andy Bierman > *Date: *Monday, June 27, 2016 at 2:21 PM > *To: *Kent Watsen > *Cc: *"t.petch" , "netmod@ietf.org" , > Lou Berger > *Subject: *Re: [netmod] Opstate solutions discussions: update and request > for WGinput > > > > > > > > On Mon, Jun 27, 2016 at 11:14 AM, Kent Watsen wrote= : > > > IMO YANG needs to be revised, not NETCONF. > > > > No, RFC6241 defines ietf-netconf.yang that hardcodes datastore names, so > it needs to be updated or maybe even replaced. > > > > > > > > Hard-wired to allow augments from a different module: > > > > > > augment /nc:get-config/nc:input/nc:source/nc:config-choice { > > case operational { > > leaf operational { > > type empty; > > if-feature operational; > > } > > } > > } > > > > > > Kent > > > > > > > > Andy > > > --001a11478f34e8ed4e0536472d0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11478f34e8ed4e0536472d0e-- From nobody Mon Jun 27 14:21:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440CC12D96C for ; Mon, 27 Jun 2016 14:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, 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 F43PTiGcw6tD for ; Mon, 27 Jun 2016 14:20:58 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 4724012D96B for ; Mon, 27 Jun 2016 14:20:58 -0700 (PDT) Received: (qmail 27357 invoked by uid 0); 27 Jun 2016 21:20:56 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 27 Jun 2016 21:20:56 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id BxLr1t0012SSUrH01xLuUU; Mon, 27 Jun 2016 15:20:54 -0600 X-Authority-Analysis: v=2.1 cv=ff4+lSgF c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=ggxpJ88YRBZlzlc331gA:9 a=3KU-Jwd7LA1EV15J:21 a=MeCThP_JYi_y38cb:21 a=QEXdDO2ut3YA:10 a=eBXx4LU_fScA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:Subject:To:From; bh=72HHwg4/A8236m9ewxPON6qFZDT8jEoTjGkb6AkccHM=; b=zS3u8X3WHrVTojn3n2INPRgzWN oFfxwCyksOcPRXbF6wlm/M0vl8otK9wpPR74PN2ev2XL4LzjF0ghlghw+Oixr78DfeWLCrmV98dsZ bNb6djhLCE3kF8FNEIajQRp1M; Received: from box313.bluehost.com ([69.89.31.113]:59853 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bHdxc-0002vR-Pl; Mon, 27 Jun 2016 15:20:52 -0600 From: Lou Berger To: netmod WG Message-ID: Date: Mon, 27 Jun 2016 17:20:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} 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-Source-IP: 69.89.31.113 X-Exim-ID: 1bHdxc-0002vR-Pl X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: box313.bluehost.com ([127.0.0.1]) [69.89.31.113]:59853 X-Source-Auth: lberger@labn.net X-Email-Count: 0 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: netmod chairs Subject: [netmod] Berlin Slot Requests X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 21:21:01 -0000 All, The agenda for Berlin has been published, see https://datatracker.ietf.org/meeting/96/agenda.html. We are scheduled for Monday, July 18, 2016 (CEST) 15:40-17:40 Monday Afternoon session II Schoeneberg NETCONF Data Modeling Language Tuesday, July 19, 2016 (CEST) 16:20-18:20 Tuesday Afternoon session II Tiergarten NETCONF Data Modeling Language If you'd like to have a presentation slot in Berlin, please send a request to by Friday July 1st. The request should include: Title: Draft(s): Desired Duration: Presenter: Preference will be given to topics/drafts discussed on the list. New topics generally require a draft (see below for submission cut off.) Authors/editors of any WG draft not being discussed/presented needs to send a status update to the list by Wednesday, July 13th. Also, summary slide(s) should be provided to netmod-chais@ietf.org (we'll copy text from e-mail if not sent) for review during the meeting. Presenters will need to send slides no later than Friday, July 15th. Although Wednesday, July 13th is preferred. Finally, our Secretary won't be Berlin so if you are interested in being acting-Secretary please let us know. Thank you! Kent & Lou PS. Important dates: 2016-07-08 (Friday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59, upload using IETF ID Submission Tool. 2016-07-08 (Friday): Draft Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool. 2016-07-08 (Friday): Early Bird registration and payment cut-off at UTC 23:59. 2016-07-11 (Monday): Revised Working Group agendas due by UTC 23:59, upload using IETF Meeting Materials Management Tool. 2016-07-11 (Monday): Registration cancellation cut-off at UTC 23:59. 2016-07-15 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 local meeting time. 2016-07-17 - 2016-07-22: IETF 96 in Berlin, Germany From nobody Mon Jun 27 15:24:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBFA12DA1F for ; Mon, 27 Jun 2016 15:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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=-1.426, 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 MgBfYuuwxMRf for ; Mon, 27 Jun 2016 15:24:05 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33DEE12DA23 for ; Mon, 27 Jun 2016 15:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13764; q=dns/txt; s=iport; t=1467066229; x=1468275829; h=from:to:cc:subject:date:message-id:mime-version; bh=01JXaETQhiFL7x2MuJD2u4o8LYPnsvdMMVdh/GZsiBg=; b=Elpz7/wf/lQ4UKPtm+g9MPFaKMjlQSzOklzxkLKh5TrkMEuN+k7gtlgM 8MILli0vMXn/kG3zw91fFYtCX8V0teGn7fUwFBwa2Q1kwyY3wvJoJfHXd ld0DKmwse6LVkCJA3iDViP9TyqpJFDFoMYosXrSLPbSsqPRAr3WOAlG/x Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BjBgCmpnFX/51dJa1bgnBOVn0GAbUlg?= =?us-ascii?q?nKCD4F7hhgCHIEWOhIBAQEBAQEBZSeETAEBAQQjCkwOBAEIEQMBAisCBBQcHQo?= =?us-ascii?q?EAQ0FiDCwNZAqAQEBAQEBAQEBAQEBAQEBAQEBAQEBHAWGI4F3glaEVwmCYYJaB?= =?us-ascii?q?ZNNhTQBjjaBaYRUgy6FOY9+ASUKJYIIHIFMboh4AX4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,538,1459814400"; d="scan'208,217";a="117498314" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2016 22:23:48 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u5RMNmi6025909 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jun 2016 22:23:48 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Jun 2016 17:23:47 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Mon, 27 Jun 2016 17:23:47 -0500 From: "Clyde Wildes (cwildes)" To: Dmytro Gassanov , "netmod@ietf.org" Thread-Topic: [netmod] NETMOD SYSLOG YANG Model / additional attributes Thread-Index: AQHR0MKSLlQIjzj660CZoMRiG1psgA== Date: Mon, 27 Jun 2016 22:23:47 +0000 Message-ID: <33F3F8A4-E68E-4A21-8AA4-334649497954@cisco.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: [128.107.151.44] Content-Type: multipart/alternative; boundary="_000_33F3F8A4E68E4A218AA4334649497954ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Andrew Veitch Subject: Re: [netmod] NETMOD SYSLOG YANG Model / additional attributes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 22:24:08 -0000 --_000_33F3F8A4E68E4A218AA4334649497954ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG15dHJvLA0KDQpSRkMgNTQyNCBUaGUgU3lzbG9nIFByb3RvY29sLCBkZWZpbmVzIHRoZSBtZXNz YWdlIGZvcm1hdCBmb3Igc3lzbG9nIG1lc3NhZ2VzIGFuZCB0aGUgcHJvcG9zZWQgaWV0Zi1zeXNs b2cueWFuZyBtb2RlbCBzdXBwb3J0cyBib3RoIGZyZWUgZm9ybSBhbmQgc3RydWN0dXJlZCBkYXRh IGZvcm1hdCBTeXNsb2cgbWVzc2FnZXMgYXMgc3BlY2lmaWVkIGJ5IFJGQyA1NDI0Lg0KDQpUSU1F U1RBTVAgaXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNi4yLjMgb2YgdGhlIFJGQy4gU2VxdWVuY2Ug bnVtYmVyIGNvdWxkIGJlIGltcGxlbWVudGVkIGFzIGZyZWUgZm9ybSB0ZXh0IGluIHRoZSBNU0cg ZmllbGQgKHNlY3Rpb24gNi40KSwgb3IgaXQgY291bGQgYmUgYW4gU0QtRUxFTUVOVCAoc2VjdGlv biA2LjMuMSkgaWYgc3RydWN0dXJlZCBkYXRhIGZvcm1hdCBpcyB1c2VkLiBTZWN0aW9uIDcuMy4x IOKAkyBzZXF1ZW5jZUlkIHNob3dzIGFuIGV4YW1wbGUgb2YgYSBzdHJ1Y3R1cmVkIGRhdGEgc2Vx dWVuY2UgbnVtYmVyIGltcGxlbWVudGF0aW9uLg0KDQpUaGFua3MsDQoNCkNseWRlDQoNCkZyb206 IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBEbXl0cm8gR2Fz c2Fub3YgPGRteXRyby5nYXNzYW5vdkBOZXRDcmFja2VyLmNvbT4NCkRhdGU6IEZyaWRheSwgSnVu ZSAyNCwgMjAxNiBhdCA4OjM4IEFNDQpUbzogIm5ldG1vZEBpZXRmLm9yZyIgPG5ldG1vZEBpZXRm Lm9yZz4NCkNjOiBBbmRyZXcgVmVpdGNoIDxhbmRyZXcudmVpdGNoQE5ldENyYWNrZXIuY29tPg0K U3ViamVjdDogW25ldG1vZF0gTkVUTU9EIFNZU0xPRyBZQU5HIE1vZGVsIC8gYWRkaXRpb25hbCBh dHRyaWJ1dGVzDQoNCkhlbGxvIEV2ZXJ5Ym9keSwNCg0KSSBhbHNvIHJlYWQgdGhlIGxhdGVzdCBy ZXZpc2lvbiBvZiDigJxTWVNMT0cgWUFORyBNb2RlbOKAnSBhbmQgZGlkIG5vdCBmb3VuZCBhdHRy aWJ1dGVzIHJlZ2FyZGluZyDigJxUaW1lc3RhbXAgZm9ybWF04oCdIGFuZCDigJxTZXF1ZW5jZSBu dW1iZXLigJ0uDQoNCkZyb20gbXkgdW5kZXJzdGFuZGluZyB0aGVzZSBhdHRyaWJ1dGVzIGFyZSBp bXBvcnRhbnQuDQoNCldoYXQgZG8geW91IHRoaW5rIGFib3V0IGFkZGluZyB0aGVzZSBhdHRyaWJ1 dGVzPw0KDQpUaGFuayB5b3UuDQoNCkJlc3QgcmVnYXJkcywNCg0KRG15dHJvIEdhc3Nhbm92LA0K TmV0Y3JhY2tlciBUZWNobm9sb2d5DQoNCiszODAgNDQgMjM4LTg3MjcgfCBleHQuIDY4MjUgfCBv ZmZpY2UNCiszODAgNjcgNDQxLTU4MzQgfCBtb2JpbGUNCg0KV2UgYXJlIE5ldGNyYWNrZXIsIGFu ZCB3ZSBhcmUgZm9jdXNlZCBmb3J3YXJkDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpUaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgaGVyZWluIGlzIGludGVuZGVk IG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZCBh bmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsLCBwcm9wcmlldGFyeSBhbmQvb3IgcHJpdmlsZWdl ZCBtYXRlcmlhbC4gQW55IHJldmlldywgcmV0cmFuc21pc3Npb24sIGRpc3NlbWluYXRpb24gb3Ig b3RoZXIgdXNlIG9mLCBvciB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9uLCB0 aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3IgZW50aXRpZXMgb3RoZXIgdGhhbiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIGluIGVy cm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1hdGVyaWFsIGZy b20gYW55IGNvbXB1dGVyLg0K --_000_33F3F8A4E68E4A218AA4334649497954ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7EE59B8C43D1CE41AE09CF9C7CB389A1@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBhbm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0 IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgs IGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4t dG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdp bi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpu b3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RG15dHJvLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5SRkMgNTQyNCBUaGUgU3lzbG9nIFByb3RvY29sLCBkZWZpbmVzIHRoZSBtZXNzYWdl IGZvcm1hdCBmb3Igc3lzbG9nIG1lc3NhZ2VzIGFuZCB0aGUgcHJvcG9zZWQgaWV0Zi1zeXNsb2cu eWFuZyBtb2RlbCBzdXBwb3J0cyBib3RoIGZyZWUgZm9ybSBhbmQgc3RydWN0dXJlZCBkYXRhIGZv cm1hdCBTeXNsb2cgbWVzc2FnZXMgYXMgc3BlY2lmaWVkDQogYnkgUkZDIDU0MjQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPlRJTUVTVEFNUCBpcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA2LjIuMyBv ZiB0aGUgUkZDLiBTZXF1ZW5jZSBudW1iZXIgY291bGQgYmUgaW1wbGVtZW50ZWQgYXMgZnJlZSBm b3JtIHRleHQgaW4gdGhlIE1TRyBmaWVsZCAoc2VjdGlvbiA2LjQpLCBvciBpdCBjb3VsZCBiZSBh biBTRC1FTEVNRU5UIChzZWN0aW9uIDYuMy4xKSBpZiBzdHJ1Y3R1cmVkDQogZGF0YSBmb3JtYXQg aXMgdXNlZC4gU2VjdGlvbiA3LjMuMSDigJMgc2VxdWVuY2VJZCBzaG93cyBhbiBleGFtcGxlIG9m IGEgc3RydWN0dXJlZCBkYXRhIHNlcXVlbmNlIG51bWJlciBpbXBsZW1lbnRhdGlvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5DbHlkZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+bmV0bW9kICZsdDtuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyZndDsgb24g YmVoYWxmIG9mIERteXRybyBHYXNzYW5vdiAmbHQ7ZG15dHJvLmdhc3Nhbm92QE5ldENyYWNrZXIu Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEp1bmUgMjQsIDIwMTYgYXQgODozOCBB TTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7bmV0bW9kQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRtb2RA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5BbmRyZXcgVmVpdGNoICZsdDthbmRyZXcudmVp dGNoQE5ldENyYWNrZXIuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bbmV0bW9kXSBORVRN T0QgU1lTTE9HIFlBTkcgTW9kZWwgLyBhZGRpdGlvbmFsIGF0dHJpYnV0ZXM8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxs byBFdmVyeWJvZHksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyByZWFkIHRoZSBsYXRl c3QgcmV2aXNpb24gb2Yg4oCcU1lTTE9HIFlBTkcgTW9kZWzigJ0gYW5kIGRpZCBub3QgZm91bmQg YXR0cmlidXRlcyByZWdhcmRpbmcg4oCcVGltZXN0YW1wIGZvcm1hdOKAnSBhbmQg4oCcU2VxdWVu Y2UgbnVtYmVy4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9tIG15IHVuZGVyc3RhbmRp bmcgdGhlc2UgYXR0cmlidXRlcyBhcmUgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XaGF0IGRvIHlvdSB0aGluayBhYm91dCBhZGRpbmcgdGhlc2UgYXR0cmlidXRlcz88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu ayB5b3UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzE4MzE0Nztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0 IDEuMHB0O3BhZGRpbmc6MGluO2JhY2tncm91bmQ6d2hpdGUiPkJlc3QgcmVnYXJkcyw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMxODMxNDc7Ym9yZGVyOm5vbmUgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbjtiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOiMxODMxNDc7Ym9yZGVyOm5vbmUgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbjtiYWNrZ3JvdW5kOndoaXRlIj5EbXl0cm8gR2Fzc2Fu b3YsDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpBcmlh bDtjb2xvcjojMTgzMTQ3Ij48YnI+DQo8Yj48c3BhbiBzdHlsZT0iYm9yZGVyOm5vbmUgd2luZG93 dGV4dCAxLjBwdDtwYWRkaW5nOjBpbjtiYWNrZ3JvdW5kOndoaXRlIj5OZXRjcmFja2VyIFRlY2hu b2xvZ3k8L3NwYW4+DQo8L2I+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzE4MzE0Nztib3JkZXI6bm9uZSB3aW5k b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluO2JhY2tncm91bmQ6d2hpdGUiPiYjNDM7MzgwIDQ0IDIz OC04NzI3IHwgZXh0LiA2ODI1IHwgb2ZmaWNlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzE4MzE0NyI+PGJyPg0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzE4MzE0Nzti b3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluO2JhY2tncm91bmQ6d2hpdGUi PiYjNDM7MzgwIDY3IDQ0MS01ODM0IHwgbW9iaWxlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzE4MzE0NyI+PGJyPg0KPGJyPg0KPC9z cGFuPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29s b3I6IzE4MzE0Nztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluO2JhY2tn cm91bmQ6d2hpdGUiPldlIGFyZSBOZXRjcmFja2VyLCBhbmQgd2UgYXJlIGZvY3VzZWQgZm9yd2Fy ZDwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYTtjb2xvcjpibHVlIj4NCjxo ciBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpUYWhvbWE7Y29sb3I6Ymx1ZSI+VGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGhlcmVp biBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB0byB3aGljaCBpdCBp cyBhZGRyZXNzZWQgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCwgcHJvcHJpZXRhcnkgYW5k L29yIHByaXZpbGVnZWQgbWF0ZXJpYWwuIEFueQ0KIHJldmlldywgcmV0cmFuc21pc3Npb24sIGRp c3NlbWluYXRpb24gb3Igb3RoZXIgdXNlIG9mLCBvciB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiBy ZWxpYW5jZSB1cG9uLCB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3IgZW50aXRpZXMgb3Ro ZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNl aXZlZCB0aGlzIGluIGVycm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhlDQogbWF0ZXJpYWwgZnJvbSBhbnkgY29tcHV0ZXIuIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_33F3F8A4E68E4A218AA4334649497954ciscocom_-- From nobody Mon Jun 27 15:50:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4A112DA50 for ; Mon, 27 Jun 2016 15:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 OwiM11yqtdxl for ; Mon, 27 Jun 2016 15:50:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0119.outbound.protection.outlook.com [207.46.100.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 1E5C212DA4D for ; Mon, 27 Jun 2016 15:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cNZ/BtXDevYouHD0D0fbwKHoqGvu4+NI1FKcBC+v4TQ=; b=U1mz5aQmftEkrCuIGEMgSaaLCu7FUadigDaiJMT6VYMnPQjyA4OCAptErN47nPIrMSFLd3g2VQE4oz9S9l33pX4IErvCeF35NwFbiaUIJz5ioabHwlFt+dqxxFRRa/EtET/VcjoK6eszpBYL/dq10JKSFv6dqJlab/MTl4kHvf4= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.528.16; Mon, 27 Jun 2016 22:50:15 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0528.017; Mon, 27 Jun 2016 22:50:15 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: contact statement content Thread-Index: AQHR0MZF15jTOqi1cEeHiUTgMR2qig== Date: Mon, 27 Jun 2016 22:50:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 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: f9b58967-2b23-47de-44c5-08d39edd67cb x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:Qxq2gs/TveqnWnatM0uwOh0CWoCFwKBdA54awcvRUUOiXW1KcEZ2/yn3hcCOA5AZ9pP46vNhJWFjT00vVUOFh1UxoRwxZC8rQHk1MMcAC/lEzN1ooVQyS5C/ekMzeNd2/J/kBySzY887czU8NN1xAHmw9U/IIGeBIRqK7LVa352K6G3nm6VdUiGcw+pckGOb+4iSEb2zHb7ir/h9hh5Ej3LoQnz5nAHB2tRbMrxh9Wu0wdR1sN+uuqAJVnlscl//VX7l7Ysh6R0TtKuk7nF70gZ2FdQdKr5vpNS8O4satSYFNe5pQnreuZVv5rYvCKAc4xaapYH4mwb25ntVIYkqKg==; 5:Y9ZWRpj2gPFAjJyNzFkUHDun9Am8L0rbC08S55UigIZm6iTVukQ+cOMHqibZOj3QOOO8P76pU/MXq0z3EKyHjPb+csapCjyumKHKmTsf7Ps0A1T2h/0zL9SrqV2LmlQ+XnWHGC+z7fcK7YOxme1Xyw==; 24:rH/G6SY29CEOMHpPnAWTe8ZUZPZ7sxsrxH1ogy9I7fJ+5Gy7C5ecYhEyEkq1oPB4ORwfRwwlylLLehilci7iOoJaup101Xo40BksKlxhG4M=; 7:78IFrrIg+CMv6wXPUqhwOnElr3ABCvKTPIzdSTA9HYVtxkYhgMsC/nKyFyR5xrvhVFwRL1+cFUFby06siByeKsFNrMJYlCCRpc3X2nspORjvLTRAwHOkn2jfpTFrdpJOp9ef2vQs5RgjDuq3GWocfIc7HxWgRw+f3CrXfUvrg5gWhpKUUNyQKgT/EAUacn9NJqI5mCwQZSqOKig8iecuqQYoLThjgvsL190ZLuUPcNU5lhwyyGH3Ct91Hkg8nAas x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(36756003)(5002640100001)(92566002)(15975445007)(3660700001)(8676002)(77096005)(122556002)(99286002)(6116002)(102836003)(450100001)(5640700001)(2900100001)(3846002)(19625215002)(2906002)(1730700003)(19580405001)(86362001)(101416001)(10400500002)(54356999)(19580395003)(4001350100001)(3480700004)(97736004)(83716003)(223583001)(66066001)(81156014)(83506001)(82746002)(8936002)(7846002)(586003)(106116001)(2351001)(7736002)(11100500001)(68736007)(107886002)(110136002)(16236675004)(81166006)(189998001)(3280700002)(106356001)(105586002)(87936001)(229853001)(19300405004)(50986999)(2501003)(33656002)(146263003)(133083001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.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_E5D93EA70E464288B8930C152EC4F034junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2016 22:50:15.4316 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451 Archived-At: Subject: [netmod] contact statement content X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 22:50:20 -0000 --_000_E5D93EA70E464288B8930C152EC4F034junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG91IGFuZCBJIHdlcmUgbG9va2luZyBhIGRyYWZ0IHRvZGF5IGFuZCB3ZXJlIHdvbmRlcmluZyBp ZiB0aGUgWUFORyBNb2R1bGUgVGVtcGxhdGUgaW4gNjA4N2JpcyBtYWtlcyBzZW5zZS4gIEhlcmXi gJlzIHRoZSB0ZW1wbGF0ZToNCg0KICAgICAgIGNvbnRhY3QNCiAgICAgICAgICAgIldHIFdlYjog ICA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3lvdXItd2ctbmFtZS8+DQogICAgICAgICAgICBX RyBMaXN0OiAgPG1haWx0bzp5b3VyLXdnLW5hbWVAaWV0Zi5vcmc+DQoNCiAgICAgICAgICAgIFdH IENoYWlyOiB5b3VyLVdHLWNoYWlyDQogICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzp5b3Vy LVdHLWNoYWlyQGV4YW1wbGUuY29tPg0KDQogICAgICAgICAgICBFZGl0b3I6ICAgeW91ci1uYW1l DQogICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzp5b3VyLWVtYWlsQGV4YW1wbGUuY29tPiI7 DQoNCg0KNjAyMCBzYXlzOg0KDQogICBUaGUgImNvbnRhY3QiIHN0YXRlbWVudCBwcm92aWRlcyBj b250YWN0IGluZm9ybWF0aW9uIGZvciB0aGUgbW9kdWxlLg0KICAgVGhlIGFyZ3VtZW50IGlzIGEg c3RyaW5nIHRoYXQgaXMgdXNlZCB0byBzcGVjaWZ5IGNvbnRhY3QgaW5mb3JtYXRpb24NCiAgIGZv ciB0aGUgcGVyc29uIG9yIHBlcnNvbnMgdG8gd2hvbSB0ZWNobmljYWwgcXVlcmllcyBjb25jZXJu aW5nIHRoaXMNCiAgIG1vZHVsZSBzaG91bGQgYmUgc2VudCwgc3VjaCBhcyB0aGVpciBuYW1lLCBw b3N0YWwgYWRkcmVzcywgdGVsZXBob25lDQogICBudW1iZXIsIGFuZCBlbGVjdHJvbmljIG1haWwg YWRkcmVzcy4NCg0KNjA4N2JpeiBzYXlzOg0KDQogIFRoZSBjb250YWN0IHN0YXRlbWVudCBNVVNU IGJlIHByZXNlbnQuICBJZiB0aGUgbW9kdWxlIGlzIGNvbnRhaW5lZCBpbg0KICAgYSBkb2N1bWVu dCBpbnRlbmRlZCBmb3IgU3RhbmRhcmRzIFRyYWNrIHN0YXR1cywgdGhlbiB0aGUgd29ya2luZw0K ICAgZ3JvdXAgd2ViIGFuZCBtYWlsaW5nIGluZm9ybWF0aW9uIE1VU1QgYmUgcHJlc2VudCwgYW5k IHRoZSBtYWluDQogICBkb2N1bWVudCBhdXRob3Igb3IgZWRpdG9yIGNvbnRhY3QgaW5mb3JtYXRp b24gU0hPVUxEIGJlIHByZXNlbnQuICBJZg0KICAgYWRkaXRpb25hbCBhdXRob3JzIG9yIGVkaXRv cnMgZXhpc3QsIHRoZWlyIGNvbnRhY3QgaW5mb3JtYXRpb24gTUFZIGJlDQogICBwcmVzZW50LiAg SW4gYWRkaXRpb24sIHRoZSBBcmVhIERpcmVjdG9yIGFuZCBvdGhlciBjb250YWN0DQogICBpbmZv cm1hdGlvbiBNQVkgYmUgcHJlc2VudC4NCg0KDQpJdCBzZWVtcyB0aGF0IG91ciBwcmltYXJ5IGdv YWwgaXMgdG8gaGF2ZSBxdWVzdGlvbnMgZGlyZWN0ZWQgdG8gdGhlIHdvcmtpbmcgZ3JvdXAuICBE b2VzIGl0IHJlYWxseSBtYWtlIHNlbnNlIHRvIGhhdmUgY2hhaXJzIG9yIEFEcyBsaXN0ZWQ/ICAg VGhhdCBzYWlkLCB3ZSB1bmRlcnN0YW5kIGxpc3RpbmcgYXV0aG9ycywgYXMgdGhleeKAmXJlIGxp c3RlZCBpbiBSRkNzIHRvby4NCg0KT25lIHJlbGF0ZWQgbml0LCBpcyB0aGUg4oCcV0figJ0gYWNy b255bSB3aWRlbHkga25vd24gZW5vdWdoIHRvIHVzZSBpdCBpbiB0aGUgdGVtcGxhdGU/ICAgSG93 IHRoZSBmb2xsb3dpbmcgaW5zdGVhZD8NCg0KT0xEDQogICAgICAgY29udGFjdA0KICAgICAgICAg ICAiV0cgV2ViOiAgIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cveW91ci13Zy1uYW1lLz4NCiAg ICAgICAgICAgIFdHIExpc3Q6ICA8bWFpbHRvOnlvdXItd2ctbmFtZUBpZXRmLm9yZz4NCg0KTkVX DQogICAgICAgIGNvbnRhY3QNCiAgICAgICAgICAgIldlYiBQYWdlOiAgICA8aHR0cDovL3Rvb2xz LmlldGYub3JnL3dnL3lvdXItd2ctbmFtZS8+DQogICAgICAgICAgICAgTWFpbGluZyBMaXN0OiAg PG1haWx0bzp5b3VyLXdnLW5hbWVAaWV0Zi5vcmc+DQoNCg0KS2VudCAoYW5kIExvdSkNCg0KDQo= --_000_E5D93EA70E464288B8930C152EC4F034junipernet_ 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 eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Mb3UgYW5k IEkgd2VyZSBsb29raW5nIGEgZHJhZnQgdG9kYXkgYW5kIHdlcmUgd29uZGVyaW5nIGlmIHRoZSBZ QU5HIE1vZHVsZSBUZW1wbGF0ZSBpbiA2MDg3YmlzIG1ha2VzIHNlbnNlLiZuYnNwOyBIZXJl4oCZ cyB0aGUgdGVtcGxhdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFjdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJnF1b3Q7V0cgV2ViOiZuYnNwOyZuYnNwOyAmbHQ7aHR0cDovL3Rvb2xzLmll dGYub3JnL3dnL3lvdXItd2ctbmFtZS8mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBX RyBMaXN0OiZuYnNwOyAmbHQ7bWFpbHRvOnlvdXItd2ctbmFtZUBpZXRmLm9yZyZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXRyBDaGFpcjog eW91ci1XRy1jaGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzp5 b3VyLVdHLWNoYWlyQGV4YW1wbGUuY29tJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVkaXRvcjombmJzcDsmbmJzcDsgeW91ci1uYW1lPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOnlvdXItZW1haWxAZXhhbXBs ZS5jb20mZ3Q7JnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjYwMjAgc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyBUaGUgJnF1b3Q7Y29udGFjdCZx dW90OyBzdGF0ZW1lbnQgcHJvdmlkZXMgY29udGFjdCBpbmZvcm1hdGlvbiBmb3IgdGhlIG1vZHVs ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IFRoZSBhcmd1bWVudCBpcyBhIHN0cmlu ZyB0aGF0IGlzIHVzZWQgdG8gc3BlY2lmeSBjb250YWN0IGluZm9ybWF0aW9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyBmb3IgdGhlIHBlcnNvbiBvciBwZXJzb25zIHRvIHdob20gdGVj aG5pY2FsIHF1ZXJpZXMgY29uY2VybmluZyB0aGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu YnNwOyBtb2R1bGUgc2hvdWxkIGJlIHNlbnQsIHN1Y2ggYXMgdGhlaXIgbmFtZSwgcG9zdGFsIGFk ZHJlc3MsIHRlbGVwaG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgbnVtYmVyLCBh bmQgZWxlY3Ryb25pYyBtYWlsIGFkZHJlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij42MDg3Yml6IHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDsgVGhlIGNvbnRhY3Qgc3RhdGVtZW50IE1VU1QgYmUgcHJlc2Vu dC4mbmJzcDsgSWYgdGhlIG1vZHVsZSBpcyBjb250YWluZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7IGEgZG9jdW1lbnQgaW50ZW5kZWQgZm9yIFN0YW5kYXJkcyBUcmFjayBzdGF0 dXMsIHRoZW4gdGhlIHdvcmtpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IGdyb3Vw IHdlYiBhbmQgbWFpbGluZyBpbmZvcm1hdGlvbiBNVVNUIGJlIHByZXNlbnQsIGFuZCB0aGUgbWFp bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgZG9jdW1lbnQgYXV0aG9yIG9yIGVkaXRv ciBjb250YWN0IGluZm9ybWF0aW9uIFNIT1VMRCBiZSBwcmVzZW50LiZuYnNwOyBJZjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgYWRkaXRpb25hbCBhdXRob3JzIG9yIGVkaXRvcnMgZXhp c3QsIHRoZWlyIGNvbnRhY3QgaW5mb3JtYXRpb24gTUFZIGJlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOyZuYnNwOyBwcmVzZW50LiZuYnNwOyBJbiBhZGRpdGlvbiwgdGhlIEFyZWEgRGlyZWN0b3Ig YW5kIG90aGVyIGNvbnRhY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0 aW9uIE1BWSBiZSBwcmVzZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkl0IHNlZW1zIHRoYXQgb3VyIHByaW1hcnkg Z29hbCBpcyB0byBoYXZlIHF1ZXN0aW9ucyBkaXJlY3RlZCB0byB0aGUgd29ya2luZyBncm91cC4m bmJzcDsgRG9lcyBpdCByZWFsbHkgbWFrZSBzZW5zZSB0byBoYXZlIGNoYWlycyBvciBBRHMgbGlz dGVkPyAmbmJzcDsmbmJzcDtUaGF0IHNhaWQsIHdlIHVuZGVyc3RhbmQgbGlzdGluZyBhdXRob3Jz LCBhcyB0aGV54oCZcmUgbGlzdGVkIGluDQogUkZDcyB0b28uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5PbmUgcmVsYXRlZCBuaXQsIGlzIHRoZSDigJxXR+KAnSBh Y3JvbnltIHdpZGVseSBrbm93biBlbm91Z2ggdG8gdXNlIGl0IGluIHRoZSB0ZW1wbGF0ZT8mbmJz cDsmbmJzcDsgSG93IHRoZSBmb2xsb3dpbmcgaW5zdGVhZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk9MRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1 b3Q7V0cgV2ViOiZuYnNwOyZuYnNwOyAmbHQ7aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3lvdXIt d2ctbmFtZS8mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXRyBMaXN0OiZuYnNwOyAm bHQ7bWFpbHRvOnlvdXItd2ctbmFtZUBpZXRmLm9yZyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk5FVzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGFjdDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJnF1b3Q7V2ViIFBhZ2U6Jm5ic3A7Jm5ic3A7ICZuYnNwOyZsdDtodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvd2cveW91ci13Zy1uYW1lLyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IE1haWxpbmcgTGlzdDombmJzcDsgJmx0O21haWx0bzp5b3VyLXdnLW5hbWVAaWV0Zi5vcmcm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+S2VudCAoYW5kIExvdSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_E5D93EA70E464288B8930C152EC4F034junipernet_-- From nobody Mon Jun 27 20:18:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D40912DB07 for ; Mon, 27 Jun 2016 20:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 T_MiogUVFjlz for ; Mon, 27 Jun 2016 20:18:28 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 C461F12DB06 for ; Mon, 27 Jun 2016 20:18:28 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-09v.sys.comcast.net with SMTP id HjWpbaLroAlI7HjXgbmGst; Tue, 28 Jun 2016 03:18:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467083908; bh=u2I6XnMAEsXXgvZIenjGxvFZOapxDeNVaVJrv3G8pHQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=aybeyre1/qr508g05XbdWvoynIVYOg5Ydi6QCp5/TOsg3At4B2E9NINbNpqUMxU9Q 1+O9afEAxu0jVVJesBwAOIVJnp2QZA9BuNH7pPhO7O2z6HIr0YHVq9MskLQNBu3CeY jDkt/JI8MHVEspIf9WnuzDU759XvURn7pmEM3/5h9RTOa+0SLPIk2f12OkxTFWA5+l lfr6veTL+vh7p21T75LEvISxc4kpZNe1PaaY433vCABTawKbLWangETPgb87+SGujU ur1/LJQR6XOLLpacJU0i6ZwaNtB2tOkWPYPf2J/mdaPISwgLzpxIWuBpSz0x9o/S9k llDuEFmAltgZw== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-15v.sys.comcast.net with comcast id C3JT1t00A1nMCLR013JTuH; Tue, 28 Jun 2016 03:18:28 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u5S3IQ3e020754 for ; Mon, 27 Jun 2016 23:18:26 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5S3IQmv020751; Mon, 27 Jun 2016 23:18:26 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: netmod@ietf.org In-Reply-To: (kwatsen@juniper.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 27 Jun 2016 23:18:26 -0400 Message-ID: <87shvyf1bx.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [netmod] contact statement content X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 03:18:30 -0000 Kent Watsen writes: > One related nit, is the "WG" acronym widely known enough to use it in > the template? How the following instead? > > OLD > contact > "WG Web: > WG List: > > NEW > contact > "Web Page: > Mailing List: If you take out the acronym "WG", in what way does that make the remaining words more descriptive? I can see arguing for "WG Web Page" and "WG Mailing List", though. Dale From nobody Tue Jun 28 01:46:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592C412DB56 for ; Tue, 28 Jun 2016 01:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-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 p7SRLZostGET for ; Tue, 28 Jun 2016 01:46:25 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB5512DB55 for ; Tue, 28 Jun 2016 01:46:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 13EAE1E5D80; Tue, 28 Jun 2016 01:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Cp5eAMz4YCdB; Tue, 28 Jun 2016 01:45:41 -0700 (PDT) Received: from [192.168.1.100] (host81-132-48-184.range81-132.btcentralplus.com [81.132.48.184]) by c8a.amsl.com (Postfix) with ESMTPSA id 5B39A1E5D7A; Tue, 28 Jun 2016 01:45:41 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: William Lupton In-Reply-To: <20160627110358.GB52882@elstar.local> Date: Tue, 28 Jun 2016 09:46:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <339D00A3-FB6A-4D24-B449-60D96CAA2A9B@broadband-forum.org> <9A4AC80F-A917-45BE-B0DE-88384552709B@broadband-forum.org> <20160627110358.GB52882@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2104) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Canonical order: linkage and meta X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 08:46:27 -0000 Thanks. That=E2=80=99s fine. I was just checking for opinions :). W. > On 27 Jun 2016, at 12:03, Juergen Schoenwaelder = wrote: >=20 > I think changing the canonical format because some people may miss the > copyright since they have to scroll down a bit is not really worth the > pain of having different canonical formats out there. And something > like >=20 > // please scroll down to see the license >=20 > does seem to sovle the problem. >=20 > /js >=20 > On Mon, Jun 27, 2016 at 11:20:02AM +0100, William Lupton wrote: >> All, >>=20 >> No-one replied to this. Fair enough, because it probably seems a = rather trivial question! But I wanted to point out that a practical = consequence of the description being a long way down a module is that = the license text could easily be missed (assuming it=E2=80=99s in the = top-level description, which is the usual IETF - and BBF - practice). In = one BBF module (lots of includes, each of which has a revision-date and = uses 3 lines), the top-level description begins at line 149 out of 204. >>=20 >> OK, we could put a comment nearer the top of the file that points the = reader further down the file, or we could move the license text into a = comment near the top of the file. But usual YANG practice (and I like = this) seems to be to prefer to put information into YANG statements = rather than into comments. >>=20 >> Thoughts? >>=20 >> Thanks, >> William >>=20 >>> On 9 Jun 2016, at 12:30, William Lupton = wrote: >>>=20 >>> All, >>>=20 >>> RFC 6020bis says =E2=80=9CThe ABNF grammar [RFC5234] [RFC7405] = defines the canonical order. To improve module readability, it is = RECOMMENDED that clauses be entered in this order.=E2=80=9D >>>=20 >>> The ABNF places linkage-stmts (import, include) before meta-stmts = (organization, contact, description, reference) but if there are a lot = of linkage statements (which will be the case in the main module if = there are a large number of submodules=E2=80=A6 as there are for some of = the modules that BBF is defining) this means that the description can be = a fair way down the module. >>>=20 >>> Would there be any support for regarding placement of the meta = statements before the linkage statements as not being a violation of = canonical order? Note (this might be inadvertent) that the ABNF actually = defines =E2=80=9Cmeta-stmts=E2=80=9D before =E2=80=9Clinkage-stmts=E2=80=9D= . >>>=20 >>> Thanks, >>> William >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 From nobody Tue Jun 28 06:46:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FFA12D198; Tue, 28 Jun 2016 06:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 bSoPmX_YqnGg; Tue, 28 Jun 2016 06:46:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EDCFA12B069; Tue, 28 Jun 2016 06:46:07 -0700 (PDT) Received: from [10.86.252.110] (198-135-0-233.cisco.com [198.135.0.233]) by mail.tail-f.com (Postfix) with ESMTPSA id DB7001AE0449; Tue, 28 Jun 2016 15:46:03 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: Carl Moberg X-Priority: 3 In-Reply-To: <20160627150230.B45D512D7A0@ietfa.amsl.com> Date: Tue, 28 Jun 2016 15:45:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6771d54b-96f4-4d17-4a2e-6574f54aaa8c@cisco.com> <20160627150230.B45D512D7A0@ietfa.amsl.com> To: Jonathan Hansford X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "netmod-chairs@ietf.org" , "draft-ietf-netmod-yang-model-classification@ietf.org" , NETMOD Working Group Subject: Re: [netmod] draft-ietf-netmod-yang-model-classification-02.txt posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 13:46:15 -0000 First of all, thanks a lot. Secondly, I=E2=80=99ve added a draft -03 including changes based on the = below in github here: = https://github.com/YangModels/yang/blob/master/experimental/ietf/YANG-MODE= L-CLASSIFICATION/draft-ietf-netmod-yang-model-classification-03.xml =E2=80=A6and since I made the changes in a renamed file, I can=E2=80=99t = send a link to the commit in github, but made the diff available here: http://www.mergely.com/zFp8lfAb/ Comments inline below: > On Jun 27, 2016, at 5:10 PM, Jonathan Hansford = wrote: >=20 > General > =C2=B7 Inconsistent capitalisation of =E2=80=9Cmodule=E2=80=9D? The intent was to only capitalize instances referring the terms = suggested (e.g. "Network Service YANG Modules=E2=80=9D), so I have fixed = the irregularities I found in the current version. > Abstract > =C2=B7 s/analysis the/analysis of the Fixed, thanks. > 1. Introduction > =C2=B7 The first paragraph is a little confusing. Should the = first reference to YANG replace =E2=80=9Cand YANG standards=E2=80=9D = further on? OLD The Internet Engineering Steering Group (IESG) has been actively encouraging IETF working groups to use the YANG [RFC6020] [I-D.ietf-netmod-rfc6020bis] and NETCONF [RFC6241] and YANG standards for configuration management purposes, especially in new working group charters [Writable-MIB-Module-IESG-Statement]. NEW The Internet Engineering Steering Group (IESG) has been actively encouraging IETF working groups to use YANG modeling language [RFC6020] [I-D.ietf-netmod-rfc6020bis] and NETCONF protocol [RFC6241] for configuration management purposes, especially in new working group charters [Writable-MIB-Module-IESG-Statement]. > =C2=B7 s/community gain/community gains > =C2=B7 s/a type of module that have/a type of module that has > =C2=B7 But, would it be better to have =E2=80=9CA number of = module types have created substantial discussion during the development = of this document including those concerned with topologies.=E2=80=9D = Instead of =E2=80=9CAn example of a type of module that have created = substantial discussion during the development of this document is = topologies.=E2=80=9D? > =C2=B7 s/as well as in/as well as on Fixed, thanks > =C2=B7 Figure 1 seems to take a long time appearing Good catch, moved up a couple of paragraphs, thanks. > =20 > 2. First Dimension: YANG Data Model Abstraction Layers > =C2=B7 s/YANG modules For/YANG modules. For > =C2=B7 Given the third paragraph, should this be =E2=80=9CFirst = Dimension: YANG Data Model Abstraction Layers=E2=80=9D or =E2=80=9CFirst = Dimension: YANG Module Abstraction Layers=E2=80=9D? Yes, fixed, thanks. > 2.1. Network Service YANG Modules > =C2=B7 s/define services models/define service models Fixed, thanks. > =20 > 3. Second Dimension: Module Types > =C2=B7 The first paragraph uses either/and (should be = either/or) for more than two alternatives. It would be better to have a = bulleted list. OLD This document suggests classifying YANG module types as either standard YANG modules, vendor-specific YANG modules and extensions, and user-specific YANG modules and extensions NEW This document suggests classifying YANG module types as standard YANG modules, vendor-specific YANG modules and extensions, or user-specific YANG modules and extensions > 3.1. Standard YANG Modules > =C2=B7 If the IEEE acronym is expanded, shouldn=E2=80=99t MEF = also be expanded? Removed expansion, it should be well knowN. > 3.2. Vendor-specific YANG Modules and Extensions > =C2=B7 s/contributed back to, or adopted by an SDO/contributed = back to, or adopted by, an SDO > =C2=B7 =E2=80=9Clifecycles ... are=E2=80=9D or =E2=80=9Clifecycl= e ... is=E2=80=9D. I suggest the former > =C2=B7 s/than what is covered/than that covered Fixed, thanks. > =20 > 3.3. User-specific YANG Modules and Extensions > =C2=B7 =E2=80=9Coperators service providers=E2=80=9D =E2=80=93 = should that be =E2=80=9Coperators=E2=80=99 service providers=E2=80=9D? > =C2=B7 s/what is provided/that provided > =C2=B7 s/include ability/include the ability Fixed, thanks. > =C2=B7 =E2=80=9Clifecycles ... are=E2=80=9D or =E2=80=9Clifecycl= e ... is=E2=80=9D. I suggest the former OLD User-specific YANG modules are developed by organizations that operate YANG-based infrastructure including devices and orchestrators. For = example, network administrators in enterprises, or operators service providers. = [=E2=80=A6] NEW User-specific YANG modules are developed by organizations that operate YANG-based infrastructure including devices and orchestrators. For = example, network administrators in enterprises or at service providers. [=E2=80=A6= ] > 4. Adding The Classification Type to YANG Module Catalogs > =C2=B7 s/Such catalog/Such a catalog > =C2=B7 s/to YANG module/to the YANG module > =C2=B7 s/A extensible/An extensible > =C2=B7 =E2=80=9Cdefinite=E2=80=9D or =E2=80=9Cdefinitive=E2=80=9D= ? Fixed, thanks. > 5. Security Considerations > =C2=B7 Remove the closing double quote Fixed, thanks. > =20 > 8. Change log [RFC Editor: Please remove] > =C2=B7 s/epxlain/explain Fixed, thanks. > Jonathan > =20 > From: Benoit Claise > Sent: 27 June 2016 11:40 > To: NETMOD Working Group > Cc: netmod-chairs@ietf.org; = draft-ietf-netmod-yang-model-classification@ietf.org > Subject: [netmod] draft-ietf-netmod-yang-model-classification-02.txt = posted > =20 > Dear all, > =20 > We have posted draft-ietf-netmod-yang-model-classification version 2 > =20 > = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classificati= on/ > =20 > We believe that we have addressed all the open issues, and that this=20= > draft is ready for WGLC. > =20 > Regards, Carl, Dean, and Benoit > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jun 30 02:59:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AEF12D863 for ; Thu, 30 Jun 2016 02:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.936 X-Spam-Level: X-Spam-Status: No, score=-15.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QNI74F9IZcZ for ; Thu, 30 Jun 2016 02:58:59 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643EB12D5C2 for ; Thu, 30 Jun 2016 02:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12650; q=dns/txt; s=iport; t=1467280738; x=1468490338; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=0M8kJXFJ0UxJZzbd9Ce++KMjZkLLr8jv5vXY7SzWwCk=; b=hJfQCP7u5gUaG47MgUtVQb0tRmJluJH71QXe6rQ8JHgxb3y9ies+Ea84 dAUhyE5PLdm/MEK7h+uDj+DKd70EcFf2StUhBK+vQ6PUfRBQVCxsKmmIB ClzFjUydAP0XkUgOpgkoD0CaAQh4lswgDPYxVOoE9iOPQqDxyujYUGeQM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+BgDF7HRX/xbLJq1agnCBJCtStEKFA?= =?us-ascii?q?YF8FwEKhStKAoFtFAEBAQEBAQFlJ4RNAQEEAQEBaxsLDgonBycfEQYBDAYCAQG?= =?us-ascii?q?ILA7CbAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKIF3glaEEhACAYV2BY4AhVWFN?= =?us-ascii?q?oYIiDmBak6HE4VfhlWJMB42gggcgU07MolIAQEB?= X-IronPort-AV: E=Sophos;i="5.26,551,1459814400"; d="scan'208,217";a="635449648" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jun 2016 09:58:56 +0000 Received: from [10.63.23.64] (dhcp-ensft1-uk-vla370-10-63-23-64.cisco.com [10.63.23.64]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5U9wtm0029168; Thu, 30 Jun 2016 09:58:56 GMT To: Kent Watsen , "netmod@ietf.org" References: From: Robert Wilton Message-ID: <13ee6bb8-d404-b63b-b060-ecb6c16e2ade@cisco.com> Date: Thu, 30 Jun 2016 10:58:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------318AA5FD1429A14B24E5F196" Archived-At: Subject: Re: [netmod] contact statement content X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 09:59:04 -0000 This is a multi-part message in MIME format. --------------318AA5FD1429A14B24E5F196 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, Below, you seemed to suggest also removing the WG Chair from the contact information, but it wasn't in your example update. I would support removing it since I'm not sure that listing the WG chair(s) is that useful. Presumably it is more desirable that any comments/questions go to the WG list or authors. Thanks, Rob On 27/06/2016 23:50, Kent Watsen wrote: > > Lou and I were looking a draft today and were wondering if the YANG > Module Template in 6087bis makes sense. Here’s the template: > > contact > > "WG Web: > > WG List: > > WG Chair: your-WG-chair > > > > Editor: your-name > > "; > > 6020 says: > > The "contact" statement provides contact information for the module. > > The argument is a string that is used to specify contact information > > for the person or persons to whom technical queries concerning this > > module should be sent, such as their name, postal address, telephone > > number, and electronic mail address. > > 6087biz says: > > The contact statement MUST be present. If the module is contained in > > a document intended for Standards Track status, then the working > > group web and mailing information MUST be present, and the main > > document author or editor contact information SHOULD be present. If > > additional authors or editors exist, their contact information MAY be > > present. In addition, the Area Director and other contact > > information MAY be present. > > It seems that our primary goal is to have questions directed to the > working group. Does it really make sense to have chairs or ADs > listed? That said, we understand listing authors, as they’re listed > in RFCs too. > > One related nit, is the “WG” acronym widely known enough to use it in > the template? How the following instead? > > OLD > > contact > > "WG Web: > > WG List: > > NEW > > contact > > "Web Page: > > Mailing List: > > Kent (and Lou) > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------318AA5FD1429A14B24E5F196 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Kent,

Below, you seemed to suggest also removing the WG Chair from the contact information, but it wasn't in your example update.  I would support removing it since I'm not sure that listing the WG chair(s) is that useful.  Presumably it is more desirable that any comments/questions go to the WG list or authors.

Thanks,
Rob
On 27/06/2016 23:50, Kent Watsen wrote:
--------------318AA5FD1429A14B24E5F196-- From nobody Thu Jun 30 08:18:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA8412DA70 for ; Thu, 30 Jun 2016 08:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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=-1.426] 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 SlbliBx9wkaA for ; Thu, 30 Jun 2016 08:18:40 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFA112DA02 for ; Thu, 30 Jun 2016 08:18:39 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 9655060500; Thu, 30 Jun 2016 17:18:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1467299917; bh=c9eotok24GoWkfW/okHtYSnaY733qFEPbBxwwh9iVxg=; h=to:date:subject:from; b=h+Pjj3lFNli0ktP97ZRRq6DSL2a+vxPQbwMzUhkBzMo9D3bpwIHJk5SiT0CwbitI+ S03zJoeskEfFI5eOedXHMsU6IUDLkSXxAKFyJ+1j7huDbD4GIT8uFGBpsHidYgwFsi ihi6qe2UaOQnj0x3zRtcp8kVjveGPGv+TqzkONPM= content-type: text/plain; charset="utf-8" to: netmod@ietf.org User-Agent: SOGoMail 2.3.12 MIME-Version: 1.0 date: Thu, 30 Jun 2016 17:18:37 +0200 message-id: <50ed-57753880-7-33c28400@44031311> X-Forward: 2001:67c:1220:80c:6cd8:db17:9795:8a9b from: =?utf-8?q?Michal_Va=C5=A1ko?= content-transfer-encoding: quoted-printable Archived-At: Subject: [netmod] grouping if-feature X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:18:43 -0000 Hi, in NETCONF server draft [1] there is ietf-ssh-server model. It defines = feature "ssh-x509-certs" and then uses it twice in a grouping. Referrin= g to RFC 6020 [2] (I haven't noticed any difference in the YANG 1.1 dra= ft), in a grouping prefixes, type names, grouping names, and extensions= should be resolved in the context of the uses that referenced this gro= uping. What about if-feature, where should that be resolved? Either way= , to my understanding, there is one "ssh-x509-certs" feature definition= redundant, either in ietf-netconf-server or in ietf-ssh-server. Thanks= for clarification. Regards, Michal Vasko [1] https://tools.ietf.org/html/draft-ietf-netconf-server-model-09 [2] https://tools.ietf.org/html/rfc6020#section-7.11 From vinods.kumar@huawei.com Thu Jun 30 23:24:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147FE12B014 for ; Thu, 30 Jun 2016 23:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.646 X-Spam-Level: X-Spam-Status: No, score=-4.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 vV5XF2BRjdFU for ; Thu, 30 Jun 2016 23:24:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1147612B031 for ; Thu, 30 Jun 2016 23:24:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMZ10811; Fri, 01 Jul 2016 06:24:33 +0000 (GMT) Received: from LGGEML424-HUB.china.huawei.com (10.72.61.34) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 1 Jul 2016 07:24:32 +0100 Received: from BLRY3V707869 (10.18.214.58) by lggeml424-hub.china.huawei.com (10.72.61.34) with Microsoft SMTP Server id 14.3.235.1; Fri, 1 Jul 2016 14:24:20 +0800 From: "vinods.kumar" To: Date: Fri, 1 Jul 2016 11:54:16 +0530 Message-ID: <049901d1d361$32003d60$9600b820$@kumar@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_049A_01D1D38F.4BB87960" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdHTYTFbsGKsQZdiT4Kd4RCIh349tA== Content-Language: en-in X-Originating-IP: [10.18.214.58] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57760CA2.0042, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 434e06672946774930487560118ed6aa Archived-At: Cc: "'Anil Kumar S N \(VRP Network BL\)'" Subject: [netmod] Request to review the YANG compiler annotations draft. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 06:53:39 -0000 ------=_NextPart_000_049A_01D1D38F.4BB87960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, We have written a draft, to add annotation in YANG definition which can be used by the YANG compilers. We are implementing these drafts as a reference implementation in the IETF 96 hackathon on ONOS YANG utilities. Request you to review the below drafts and provide your comments/feedback. Draft(s): https://datatracker.ietf.org/doc/draft-agv-netmod-yang-compiler-metadata/ https://datatracker.ietf.org/doc/draft-agv-netmod-yang-annotation-ds-and-der ived/ Thanks and Regards, Vinod Kumar S. ------=_NextPart_000_049A_01D1D38F.4BB87960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = All,

    We have = written a draft, to add annotation in YANG definition which can be used = by the YANG compilers.

We are implementing these drafts as a = reference implementation in the IETF 96 hackathon on ONOS YANG = utilities.

Request you to review the below drafts and = provide your comments/feedback.

Draft(s):  https://datatracker.ietf.org/doc/draft-agv-netmod-yang-compiler= -metadata/

  =             &= nbsp; https://datatracker.ietf.org/doc/draft-agv-netmod-yang-= annotation-ds-and-derived/

 

Thanks and = Regards,

Vinod Kumar = S.

------=_NextPart_000_049A_01D1D38F.4BB87960--

Lou and I were looking a draft today and were wondering if the YANG Module Template in 6087bis makes sense.  Here’s the template:

 

       contact

           "WG Web:   <http://tools.ietf.org/wg/your-wg-name/>

            WG List:  <mailto:your-wg-name@ietf.org>

 

            WG Chair: your-WG-chair

                      <mailto:your-WG-chair@example.com>

 

            Editor:   your-name

                      <mailto:your-email@example.com>";

 

 

6020 says:

 

   The "contact" statement provides contact information for the module.

   The argument is a string that is used to specify contact information

   for the person or persons to whom technical queries concerning this

   module should be sent, such as their name, postal address, telephone

   number, and electronic mail address.

 

6087biz says:

 

  The contact statement MUST be present.  If the module is contained in

   a document intended for Standards Track status, then the working

   group web and mailing information MUST be present, and the main

   document author or editor contact information SHOULD be present.  If

   additional authors or editors exist, their contact information MAY be

   present.  In addition, the Area Director and other contact

   information MAY be present.

 

 

It seems that our primary goal is to have questions directed to the working group.  Does it really make sense to have chairs or ADs listed?   That said, we understand listing authors, as they’re listed in RFCs too.

 

One related nit, is the “WG” acronym widely known enough to use it in the template?   How the following instead?

 

OLD

       contact

           "WG Web:   <http://tools.ietf.org/wg/your-wg-name/>

            WG List:  <mailto:your-wg-name@ietf.org>

 

NEW

        contact

           "Web Page:    <http://tools.ietf.org/wg/your-wg-name/>

             Mailing List:  <mailto:your-wg-name@ietf.org>

 

 

Kent (and Lou)

 

 



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


On Mon, Jun 27, 2016 at 11:41 AM, Kent Watsen <kwatsen@juniper.net> wrote:

=C2=A0

Right, that would be =E2=80=9Cupdating=E2=80=9D it, and RESTCONF would nee= d a similar thing.=C2=A0 My point, and I think Tom=E2=80=99s too, is that i= t makes sense that the NETCONF (not NETMOD) WG do the protocol mapping work.=C2=A0 Do you disagree?

=C2=A0


Actua= lly, YANG is designed such that the original document does not
ne= ed to be aware of any augmentations.

I agree that = protocol operations are not in scope for NETMOD WG.
This is not c= lear to anybody who reads RFC6020bis, where NETCONF
definitions a= re clearly intermixed with the data modeling language.

=

=C2=A0

K.


Andy
= =C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Jun 27, 2016 at 11:14 AM, Kent Watsen <kwatsen@juniper.net<= /a>> wrote:

> IMO YANG needs to be revised, not NETCONF.

=C2=A0

No, RFC6241 defines ietf-netconf.yang that hardcodes= datastore names, so it needs to be updated or maybe even replaced.<= u>

=C2=A0

=C2=A0

=C2=A0

Hard-wired to allow augments from a different module= :

=C2=A0

=C2=A0

augment /nc:get-config/nc:input/nc:source/nc:config-= choice {

=C2=A0 =C2=A0 case operational {

=C2=A0 =C2=A0 =C2=A0 leaf operational {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type empty;=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature operati= onal;

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0}

}

=C2=A0

=C2=A0

Kent

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0