From nobody Mon Feb 2 10:42:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15F41A885B for ; Mon, 2 Feb 2015 10:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfKAMUsr3Ami for ; Mon, 2 Feb 2015 10:42:09 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BE91A033A for ; Mon, 2 Feb 2015 10:42:09 -0800 (PST) Received: from BY2PR05CA062.namprd05.prod.outlook.com (10.141.250.52) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 2 Feb 2015 18:42:07 +0000 Received: from BY2FFO11FD014.protection.gbl (2a01:111:f400:7c0c::174) by BY2PR05CA062.outlook.office365.com (2a01:111:e400:2c5f::52) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Mon, 2 Feb 2015 18:42:06 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Mon, 2 Feb 2015 18:42:06 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 2 Feb 2015 10:41:24 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t12IfKW45106; Mon, 2 Feb 2015 10:41:21 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t12If4RQ027232; Mon, 2 Feb 2015 13:41:05 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502021841.t12If4RQ027232@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Mon, 2 Feb 2015 13:41:04 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(48376002)(77096005)(50466002)(105596002)(86362001)(6806004)(47776003)(110136001)(106466001)(92566002)(46102003)(2950100001)(76506005)(53416004)(50986999)(54356999)(87936001)(62966003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB440; X-Forefront-PRVS: 0475418F50 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2015 18:42:06.5518 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:42:10 -0000 Ladislav Lhotka writes: >It's not about saving a few bytes on the wire but rather about keeping the interface betw >een JSON encoding/decoding and an application simple and straightforward. It should be about putting the data into a format where the client can use it. If 42 is a string, code like: if (code > 40) { .... } will fail. >I guess this simplicity is the main reason why programmers prefer JSON to XML - no DOMs >or things like that are needed in the middle. My take is that people like JSON because it translates trivially into local data structures. You can think of the lack of quotes around select values and the presense of "[ ... ]" as a cheap means of shipping meta-data in with JSON's data, just enough to allow the receiver to decode it. Using JSON from typeless languages like javascript or python yields simpler coding. Thanks, Phil From nobody Mon Feb 2 11:57:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5781A86DE for ; Mon, 2 Feb 2015 11:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXPelZhIJjza for ; Mon, 2 Feb 2015 11:57:01 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626DD1A1A0C for ; Mon, 2 Feb 2015 11:56:50 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id gf13so44490556lab.8 for ; Mon, 02 Feb 2015 11:56:48 -0800 (PST) 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:content-type; bh=4h9vP7RzKfsyqZJHWL6PeafjOugmLt9eV53qtbU74PI=; b=R0PDyNABvkBFsb+Yd95OHIYXWZiaT/c+pusGRMMkZEE3jKgu58b3KyJmH4HcvE6Rtl tGLQ2MkfiSXBIaL5g4EUsSs+SUeThULzpGJxlNAHWI8CRYvKsK7pLofYUE/UXx4QPZNG C6uQOCGy88rGlrIxWsoD50Jwj0NiMJVYgUlk/IYbbrkrRtz1y+iyPQJ6QarLMeDCZ+xX QotwFA64JzDlkfzLoVmt/x5SnOKs/QB/Up7JHvgtbaNdXwI8GRq0i2uLXYGo8OQVdull LW8bBhFJUGS7KacQjLmJJTh/mkN6NETYnqFve3zkEreEIzPoRFhPPToyH6816FsdC+gE azdA== X-Gm-Message-State: ALoCoQllcDf/+WFGX5bU5odA7PIMVYZBhy12rl7m+puNMZSW/P+bO5LaRRFpzsgJbQ2Ezy9ZQqb/ MIME-Version: 1.0 X-Received: by 10.112.148.34 with SMTP id tp2mr21067609lbb.94.1422907008805; Mon, 02 Feb 2015 11:56:48 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 2 Feb 2015 11:56:48 -0800 (PST) In-Reply-To: <201502021841.t12If4RQ027232@idle.juniper.net> References: <201502021841.t12If4RQ027232@idle.juniper.net> Date: Mon, 2 Feb 2015 11:56:48 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:57:03 -0000 On Mon, Feb 2, 2015 at 10:41 AM, Phil Shafer wrote: > Ladislav Lhotka writes: >>It's not about saving a few bytes on the wire but rather about keeping the interface betw >>een JSON encoding/decoding and an application simple and straightforward. > > It should be about putting the data into a format where the client > can use it. If 42 is a string, code like: > > if (code > 40) { .... } > > will fail. > The client needs to be careful when using anyxml. By definition it contains no YANG type information, and the server is not required to know numbers from strings within the anyxml subtree. The client cannot rely on a JSON encoded message following some out-of-band schema. It should not assume anything about anyxml-encoded data from a server. Andy >>I guess this simplicity is the main reason why programmers prefer JSON to XML - no DOMs >>or things like that are needed in the middle. > > My take is that people like JSON because it translates trivially > into local data structures. You can think of the lack of quotes > around select values and the presense of "[ ... ]" as a cheap means > of shipping meta-data in with JSON's data, just enough to allow the > receiver to decode it. Using JSON from typeless languages like > javascript or python yields simpler coding. > > Thanks, > Phil From nobody Mon Feb 2 12:01:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F901A89FC for ; Mon, 2 Feb 2015 12:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIYj40aCMR7h for ; Mon, 2 Feb 2015 12:01:38 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:756]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57D81A8A3F for ; Mon, 2 Feb 2015 12:01:31 -0800 (PST) Received: from BN1PR05MB438.namprd05.prod.outlook.com (10.141.58.12) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 2 Feb 2015 20:01:09 +0000 Received: from BL2PR05CA0020.namprd05.prod.outlook.com (10.255.226.20) by BN1PR05MB438.namprd05.prod.outlook.com (10.141.58.12) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 2 Feb 2015 20:01:08 +0000 Received: from BN1BFFO11FD029.protection.gbl (2a01:111:f400:7c10::1:114) by BL2PR05CA0020.outlook.office365.com (2a01:111:e400:c04::20) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Mon, 2 Feb 2015 20:01:08 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD029.mail.protection.outlook.com (10.58.144.92) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Mon, 2 Feb 2015 20:01:07 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 2 Feb 2015 12:00:13 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t12K04W84540; Mon, 2 Feb 2015 12:00:10 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t12JxmNa027721; Mon, 2 Feb 2015 14:59:48 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502021959.t12JxmNa027721@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Mon, 2 Feb 2015 14:59:48 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(561944003)(54356999)(46102003)(47776003)(6806004)(50986999)(2950100001)(62966003)(87936001)(76506005)(105596002)(92566002)(110136001)(50466002)(106466001)(86362001)(53416004)(77156002)(77096005)(48376002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB438; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB438; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB438; X-Forefront-PRVS: 0475418F50 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB438; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2015 20:01:07.8823 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB438 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 20:01:42 -0000 Ladislav Lhotka writes: >I didn't say that. My proposal is to have the same rule for all >encodings, including XML: anyxml value is any content that's well-formed >for the given encoding. That will surely lead to trouble, since it ties the data to the encoding. If the code says something like: get_some_info (client) { xml = get_some_xml_content(); response = new response(client); response->encode("answer", xml); return response; } The sender knows the model requires the "answer" to be anyxml, but doesn't want/need to know that some particular client is using a particular encoding. Thanks, Phil From nobody Tue Feb 3 08:29:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E25E1A1AA6 for ; Tue, 3 Feb 2015 08:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl7Phg4tTixz for ; Tue, 3 Feb 2015 08:29:49 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6D1A1AA4 for ; Tue, 3 Feb 2015 08:29:49 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id EDC221CC002E; Tue, 3 Feb 2015 17:29:57 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201502021841.t12If4RQ027232@idle.juniper.net> References: <201502021841.t12If4RQ027232@idle.juniper.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 03 Feb 2015 17:29:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:29:52 -0000 Phil Shafer writes: > Ladislav Lhotka writes: >>It's not about saving a few bytes on the wire but rather about keeping the interface betw >>een JSON encoding/decoding and an application simple and straightforward. > > It should be about putting the data into a format where the client > can use it. If 42 is a string, code like: > > if (code > 40) { .... } > > will fail. Agreed. > >>I guess this simplicity is the main reason why programmers prefer JSON to XML - no DOMs >>or things like that are needed in the middle. > > My take is that people like JSON because it translates trivially > into local data structures. You can think of the lack of quotes > around select values and the presense of "[ ... ]" as a cheap means > of shipping meta-data in with JSON's data, just enough to allow the > receiver to decode it. Using JSON from typeless languages like > javascript or python yields simpler coding. And in strongly typed languages, using a standard JSON parser usually means that the receiver has to know the type of each value in order to be able to extract it from the parsed structure. Lada > > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 3 08:43:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CBC1A1AA0 for ; Tue, 3 Feb 2015 08:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5baQWk7d7qVf for ; Tue, 3 Feb 2015 08:43:23 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C72361A1A8D for ; Tue, 3 Feb 2015 08:43:22 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8A8771CC002E; Tue, 3 Feb 2015 17:43:31 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201502021959.t12JxmNa027721@idle.juniper.net> References: <201502021959.t12JxmNa027721@idle.juniper.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 03 Feb 2015 17:43:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:43:24 -0000 Phil Shafer writes: > Ladislav Lhotka writes: >>I didn't say that. My proposal is to have the same rule for all >>encodings, including XML: anyxml value is any content that's well-formed >>for the given encoding. > > That will surely lead to trouble, since it ties the data to > the encoding. If the code says something like: > > get_some_info (client) { > xml = get_some_xml_content(); > response = new response(client); > response->encode("answer", xml); > return response; > } > > The sender knows the model requires the "answer" to be anyxml, but > doesn't want/need to know that some particular client is using a > particular encoding. The server should know which encodings the client is prepared to handle. Imagine the communication is performed in natural languages instead: if the client indicates support for Czech and English, the server can successfully send the same information in either language, although syntactically the messages will be completely different. Lada > > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 3 08:52:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2811A1B27 for ; Tue, 3 Feb 2015 08:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxAc9EJ7cWBd for ; Tue, 3 Feb 2015 08:52:41 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6A51A1A64 for ; Tue, 3 Feb 2015 08:52:41 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id pn19so7367051lab.2 for ; Tue, 03 Feb 2015 08:52:40 -0800 (PST) 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:content-type; bh=vjiVW/u8IRe1HcMmPqOojyjNds9fdVal4oo+x9Aesnc=; b=dvx1BJbFguyiBFTCItefpG1S6MSbCfrKz1+88loKfgYrsFW1hRLHi3qWK5w8nDd4Wy Uf04GJCSOJNSescp8PI/w2Pvv0JGdG/UVr9Yg07UaFNG9or2+t/UZqoNbTHji8G+JVz6 2QzpxsOyLhv6UBHqz9d3xG+AKAXfb9FRd7XPAULkYxD8krT0Dl5yXEE/YDRmq0Im0PYd IFel/+DkNdeH3htqowB52+GdzQ3VY7Pff2MBaRHolXomL77kT9p2lEfrbIKB/R48+TmK BmGaib7WnoFJNWRlpFKELpUekwYO8rodBLekk7xFPb9L3SYABC38hHzYyJHhpHQl6cWG Bhww== X-Gm-Message-State: ALoCoQkJCl3gDVOpnHAUNCF7DnMssCtAyDwMPlqZQNv7xeTSGXPAl/brT6avRt0lpjZAfCimsq06 MIME-Version: 1.0 X-Received: by 10.112.137.38 with SMTP id qf6mr8200546lbb.59.1422982359952; Tue, 03 Feb 2015 08:52:39 -0800 (PST) Received: by 10.112.78.3 with HTTP; Tue, 3 Feb 2015 08:52:39 -0800 (PST) In-Reply-To: References: <201502021841.t12If4RQ027232@idle.juniper.net> Date: Tue, 3 Feb 2015 08:52:39 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:52:43 -0000 On Tue, Feb 3, 2015 at 8:29 AM, Ladislav Lhotka wrote: > Phil Shafer writes: > >> Ladislav Lhotka writes: >>>It's not about saving a few bytes on the wire but rather about keeping the interface betw >>>een JSON encoding/decoding and an application simple and straightforward. >> >> It should be about putting the data into a format where the client >> can use it. If 42 is a string, code like: >> >> if (code > 40) { .... } >> >> will fail. > > Agreed. > >> >>>I guess this simplicity is the main reason why programmers prefer JSON to XML - no DOMs >>>or things like that are needed in the middle. >> >> My take is that people like JSON because it translates trivially >> into local data structures. You can think of the lack of quotes >> around select values and the presense of "[ ... ]" as a cheap means >> of shipping meta-data in with JSON's data, just enough to allow the >> receiver to decode it. Using JSON from typeless languages like >> javascript or python yields simpler coding. > > And in strongly typed languages, using a standard JSON parser usually > means that the receiver has to know the type of each value in order to > be able to extract it from the parsed structure. > It would be unwise to design code this way with "anyxml" data. IMO, inline data structures are horrible for APIs. The "schema" is made up by the sender on the fly. I often see JSON from customers that uses an object instead of a 1-element array, or quoted numbers. IMO the receiver has to deal with this sloppy encoding, especially for anyxml. > Lada > Andy >> >> Thanks, >> Phil > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Tue Feb 3 09:25:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291681A1B70 for ; Tue, 3 Feb 2015 09:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wAsqYOnMy1w for ; Tue, 3 Feb 2015 09:25:24 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACF71A1AAB for ; Tue, 3 Feb 2015 09:25:23 -0800 (PST) Received: from BY2PR05CA051.namprd05.prod.outlook.com (10.141.250.41) by DM2PR05MB447.namprd05.prod.outlook.com (10.141.104.150) with Microsoft SMTP Server (TLS) id 15.1.75.20; Tue, 3 Feb 2015 17:25:23 +0000 Received: from BL2FFO11FD042.protection.gbl (2a01:111:f400:7c09::134) by BY2PR05CA051.outlook.office365.com (2a01:111:e400:2c5f::41) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Tue, 3 Feb 2015 17:25:22 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD042.mail.protection.outlook.com (10.173.161.138) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Tue, 3 Feb 2015 17:25:21 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Feb 2015 09:25:20 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t13HPJW53207; Tue, 3 Feb 2015 09:25:19 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t13HP4LX035505; Tue, 3 Feb 2015 12:25:05 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502031725.t13HP4LX035505@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Tue, 3 Feb 2015 12:25:04 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(6806004)(53416004)(76506005)(47776003)(2950100001)(110136001)(106466001)(50466002)(105596002)(86362001)(92566002)(50986999)(48376002)(77156002)(54356999)(46102003)(87936001)(62966003)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB447; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB447; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR05MB447; X-Forefront-PRVS: 0476D4AB88 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB447; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2015 17:25:21.8084 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB447 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 17:25:32 -0000 Andy Bierman writes: >It would be unwise to design code this way with "anyxml" data. >IMO, inline data structures are horrible for APIs. The "schema" is >made up by the sender on the fly. I won't debate the wisdom of using anyxml, but would argue that having features like this in our language makes it much more flexible. Consider the issue last IETF of wanting a server to proxy for unknown chunks of YANG from slave boxes. Having anyxml gives us an easy solution. Without it, we'd be forced to make special cases (like proxy) into core feature of YANG. >I often see JSON from customers that uses an object instead of >a 1-element array, or quoted numbers. IMO the receiver >has to deal with this sloppy encoding, especially for anyxml. Yes, the down side of an encoding that lets people do anything is that people will do everything. Thanks, Phil From nobody Tue Feb 3 09:49:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5558C1A1BFF for ; Tue, 3 Feb 2015 09:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpvofZqFYtzA for ; Tue, 3 Feb 2015 09:49:15 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893BF1A6F33 for ; Tue, 3 Feb 2015 09:49:14 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so40030353lbj.0 for ; Tue, 03 Feb 2015 09:49:13 -0800 (PST) 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:content-type; bh=PqqSxei4B1S8GY0raziJOMQQTzZWxZ5pO6oewyObqf4=; b=jsPS5KdaWX3+67ThxwE0sZedzCJjx6toGpU48RGhgzsfqxFKCupTDNGGhv4016QCfZ KxBoS4v1j3yQmp84PPylExBQqYQtqzfaO+LjGMMvgVcHeOLC/roWDFGewCJmM5hYiqJw gd9cIKUbGVAVbCha0zuYa3lkkHdgLCoPhPCB+AIsjGVWdCW7n1HO3m1OLcxrd/Gizu43 fiumeWgP9GbVoSWdAl10xF6TrkooyPjeZriv1ugQ84H+VTg5+VUZdQV4t/2CXcaRF3g5 GkkG7FZRLUuITwpa0ac5V/DNbTXQ1JZsXt2qVkeQPMoUnQ7OgSrzG5YhSe4nXFElcmlv nZWw== X-Gm-Message-State: ALoCoQlP1UhnytCCXEBHom6GDr3qrWYvDUDDgAUZUxkDLBfEryhUN6+TdLxSV6Mx4uIyje9neEiL MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr26061709lab.1.1422985752944; Tue, 03 Feb 2015 09:49:12 -0800 (PST) Received: by 10.112.78.3 with HTTP; Tue, 3 Feb 2015 09:49:12 -0800 (PST) In-Reply-To: <201502031725.t13HP4LX035505@idle.juniper.net> References: <201502031725.t13HP4LX035505@idle.juniper.net> Date: Tue, 3 Feb 2015 09:49:12 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 17:49:16 -0000 On Tue, Feb 3, 2015 at 9:25 AM, Phil Shafer wrote: > Andy Bierman writes: >>It would be unwise to design code this way with "anyxml" data. >>IMO, inline data structures are horrible for APIs. The "schema" is >>made up by the sender on the fly. > > I won't debate the wisdom of using anyxml, but would argue that > having features like this in our language makes it much more flexible. > > Consider the issue last IETF of wanting a server to proxy for unknown > chunks of YANG from slave boxes. Having anyxml gives us an easy > solution. Without it, we'd be forced to make special cases (like > proxy) into core feature of YANG. > We have an XML attribute solution for this called 'datapath'. There is also a YANG extension to cause the sender to generate the attribute: http://www.netconfcentral.org/modules/yumaworks-extensions/2014-08-10#datapath.138 JSON attributes are horrible to parse, but we decided all the unordered data and buffering are just implementation details. So much easier to implement with XML. It's a fairly obvious solution -- send the schema-identifier as meta-data if you want the receiver to use a dynamically assigned schema-node instead of anyxml. >>I often see JSON from customers that uses an object instead of >>a 1-element array, or quoted numbers. IMO the receiver >>has to deal with this sloppy encoding, especially for anyxml. > > Yes, the down side of an encoding that lets people do anything is > that people will do everything. > :-) > Thanks, > Phil Andy From nobody Tue Feb 3 11:29:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901181A1A87 for ; Tue, 3 Feb 2015 11:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USG8CccBdBDz for ; Tue, 3 Feb 2015 11:29:57 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id D59231A03A8 for ; Tue, 3 Feb 2015 11:29:56 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id AC1891280A44; Tue, 3 Feb 2015 20:29:55 +0100 (CET) Date: Tue, 03 Feb 2015 20:29:55 +0100 (CET) Message-Id: <20150203.202955.7349511111816036.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201502031725.t13HP4LX035505@idle.juniper.net> References: <201502031725.t13HP4LX035505@idle.juniper.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] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 19:29:58 -0000 Phil Shafer wrote: > Andy Bierman writes: > >It would be unwise to design code this way with "anyxml" data. > >IMO, inline data structures are horrible for APIs. The "schema" is > >made up by the sender on the fly. > > I won't debate the wisdom of using anyxml, but would argue that > having features like this in our language makes it much more flexible. > > Consider the issue last IETF of wanting a server to proxy for unknown > chunks of YANG from slave boxes. Having anyxml gives us an easy > solution. Without it, we'd be forced to make special cases (like > proxy) into core feature of YANG. This use case shows why the proposed 'anydata' is useful. anyxml to a lesser extent, and only for the XML encoding. /martin From nobody Tue Feb 3 11:39:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D851A1ADF for ; Tue, 3 Feb 2015 11:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOk6oB4WSoqj for ; Tue, 3 Feb 2015 11:39:16 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF3D1A0372 for ; Tue, 3 Feb 2015 11:39:16 -0800 (PST) Received: from CO2PR05CA038.namprd05.prod.outlook.com (10.141.241.166) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.1.75.20; Tue, 3 Feb 2015 19:39:14 +0000 Received: from BY2FFO11FD004.protection.gbl (2a01:111:f400:7c0c::123) by CO2PR05CA038.outlook.office365.com (2a01:111:e400:1429::38) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Tue, 3 Feb 2015 19:39:13 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Tue, 3 Feb 2015 19:39:07 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Feb 2015 11:38:15 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t13JcEW27693; Tue, 3 Feb 2015 11:38:14 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t13Jc0Yp036409; Tue, 3 Feb 2015 14:38:00 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502031938.t13Jc0Yp036409@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20150203.202955.7349511111816036.mbj@tail-f.com> Date: Tue, 3 Feb 2015 14:38:00 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(86362001)(558084003)(50986999)(92566002)(106466001)(105596002)(87936001)(50466002)(6806004)(53416004)(76506005)(47776003)(48376002)(54356999)(77156002)(46102003)(110136001)(62966003)(2950100001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB434; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB434; X-Forefront-PRVS: 0476D4AB88 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2015 19:39:07.7584 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB434 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 19:39:17 -0000 Martin Bjorklund writes: >This use case shows why the proposed 'anydata' is useful. anyxml to a >lesser extent, and only for the XML encoding. anyxml is XML content and can be validated/etc. anydata seems like "string" to me, but I may be missing something. Thanks, Phil From nobody Tue Feb 3 11:44:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1B51A1E0E for ; Tue, 3 Feb 2015 11:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdu2gcAlI-_F for ; Tue, 3 Feb 2015 11:44:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id CC7C81A885E for ; Tue, 3 Feb 2015 11:44:25 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 20CDF1280BA8; Tue, 3 Feb 2015 20:44:25 +0100 (CET) Date: Tue, 03 Feb 2015 20:44:25 +0100 (CET) Message-Id: <20150203.204425.2191223710823082433.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201502031938.t13Jc0Yp036409@idle.juniper.net> References: <20150203.202955.7349511111816036.mbj@tail-f.com> <201502031938.t13Jc0Yp036409@idle.juniper.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] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 19:44:36 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >This use case shows why the proposed 'anydata' is useful. anyxml to a > >lesser extent, and only for the XML encoding. > > anyxml is XML content and can be validated/etc. anydata seems like > "string" to me, but I may be missing something. In XML, anydata is encoded just like anyxml, i.e. "inline" (not a string). In JSON, anydata is also encoded "inline" as json structures. The difference is that anyxml is really any XML - mixed content, PI etc. anydata is restricted b/c it is the representation of something that is (or maybe "could be") modelled in YANG. /martin From nobody Tue Feb 3 11:58:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3FC1A87F1 for ; Tue, 3 Feb 2015 11:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gse6cUzrGWeb for ; Tue, 3 Feb 2015 11:58:33 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1171A87C4 for ; Tue, 3 Feb 2015 11:58:33 -0800 (PST) Received: from BL2PR05CA0049.namprd05.prod.outlook.com (10.255.226.49) by BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 3 Feb 2015 19:58:32 +0000 Received: from BL2FFO11FD050.protection.gbl (2a01:111:f400:7c09::119) by BL2PR05CA0049.outlook.office365.com (2a01:111:e400:c04::49) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Tue, 3 Feb 2015 19:58:31 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD050.mail.protection.outlook.com (10.173.161.212) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Tue, 3 Feb 2015 19:58:31 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 3 Feb 2015 11:58:30 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t13JwTW37605; Tue, 3 Feb 2015 11:58:29 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t13JwDbK036558; Tue, 3 Feb 2015 14:58:14 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502031958.t13JwDbK036558@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20150203.204425.2191223710823082433.mbj@tail-f.com> Date: Tue, 3 Feb 2015 14:58:13 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(110136001)(106466001)(105596002)(77156002)(62966003)(2950100001)(86362001)(6806004)(92566002)(50986999)(87936001)(46102003)(53416004)(54356999)(76506005)(47776003)(48376002)(77096005)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB437; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB437; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB437; X-Forefront-PRVS: 0476D4AB88 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB437; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2015 19:58:31.6921 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB437 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 19:58:35 -0000 Martin Bjorklund writes: >The difference is that anyxml is really any XML - mixed content, PI >etc. anydata is restricted b/c it is the representation of something >that is (or maybe "could be") modelled in YANG. Wouldn't such an encoding require an understanding of the schema? 1 and: a: 1 might be equivalent, if a is a leaf, and 123 and a: [ 1, 2, 3 ] are equivalent if you know it's a leaf-list. Without that knowledge, converting the first example would be problematic, since "a: [ 1 ]" would be the encoding if it were a leaf-list. Converting data not covered by schema would be difficult. Thanks, Phil From nobody Wed Feb 4 05:14:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA381A87DB for ; Wed, 4 Feb 2015 05:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7xG7PoBhfZo for ; Wed, 4 Feb 2015 05:14:04 -0800 (PST) Received: from sjmda16.webex.com (sjmda16.webex.com [64.68.124.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA0F1A00E4 for ; Wed, 4 Feb 2015 05:14:04 -0800 (PST) Received: from jva2tc101.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-1.webex.com [64.68.121.245]) by sjmda16.webex.com (Postfix) with ESMTP id 80ACBA082A for ; Wed, 4 Feb 2015 13:14:04 +0000 (GMT) Received: from jva2tc101.webex.com (localhost [127.0.0.1]) by jva2tc101.webex.com (Postfix) with ESMTP id 303B1FF84D for ; Wed, 4 Feb 2015 13:14:04 +0000 (GMT) Date: Wed, 4 Feb 2015 13:14:04 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <1114948654.17430.1423055644195.JavaMail.nobody@jva2tc101.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_17428_960801594.1423055644195" X-Priority: 3 Importance: normal Archived-At: Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:14:06 -0000 ------=_Part_17428_960801594.1423055644195 Content-Type: multipart/Alternative; boundary="----=_Part_17429_1262848565.1423055644195" ------=_Part_17429_1262848565.1423055644195 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCldlZG5lc2RheSwgRmVicnVhcnkgNCwgMjAx NQo0OjAwIHBtICB8ICBFdXJvcGUgVGltZSAoQmVybGluLCBHTVQrMDE6MDApICB8ICAyIGhycwoK CkpPSU4gV0VCRVggTUVFVElORwpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tZTg3YmFiYzJiMTI1MTVhN2U2NzJhYjcyOTEwOWM3NDQKTWVldGluZyBudW1iZXI6IDY0OSA2 OTYgOTg4Ck1lZXRpbmcgcGFzc3dvcmQ6IHVDOGNpZXNoCgoNCkpPSU4gQlkgUEhPTkUNCjEtODc3 LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSAKMS02NTAtNDc5 LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKQpBY2Nlc3MgY29kZTogNjQ5IDY5 NiA5ODgKClRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9uczogCmh0dHA6Ly93d3cud2ViZXgu Y29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmDQoNCgpBZGQgdGhpcyBtZWV0aW5nIHRv IHlvdXIgY2FsZW5kYXI6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW04 ODRlODg5MjAxNTE1NzI0ZWFlMjBlOTI4ZDcyNTg3Yg0KDQoKQ2FuJ3Qgam9pbiB0aGUgbWVldGlu Zz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6Cmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYwoK CklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFs bG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24g dG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0 ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRv IHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVk LCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUg c2Vzc2lvbi4K ------=_Part_17429_1262848565.1423055644195 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+V2Vk bmVzZGF5LCBGZWJydWFyeSA0LCAyMDE1CgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ CQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZD40OjAwIHBtJm5ic3A7Jm5ic3A7 fCZuYnNwOyZuYnNwO0V1cm9wZSBUaW1lIChCZXJsaW4sIEdNVCswMTowMCkmbmJzcDsmbmJzcDt8 Jm5ic3A7Jm5ic3A7MiBocnMKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJs ZT4KCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWln aHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lk dGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBz dHlsZT0iY29sb3I6IzAwQUZGOTtmb250LXNpemU6MTZweCI+CgkJCQkJCQkJCTxhIGhyZWY9Imh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1lODdiYWJjMmIxMjUxNWE3ZTY3 MmFiNzI5MTA5Yzc0NCIKCQkJCQkJCQkJCXN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250 LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJCQkJCTxiPkpvaW4gV2ViRXggbWVldGlu ZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3Rh YmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50 Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRk aW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGluZyBudW1iZXI6CgkJCQkJCQkJPC90ZD4K CQkJCQkJCQk8dGQ+NjQ5IDY5NiA5ODgKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJ CTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmlnaHQ6IDVweDsiPk1lZXRpbmcgcGFz c3dvcmQ6PC90ZD4KCQkJCQkJCQk8dGQ+dUM4Y2llc2g8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJ PC90YWJsZT4KCgoKCQoKCTx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBz dHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPjx0YWJsZT48dHI+PHRk IHN0eWxlPSJmb250LXNpemU6MTZweCI+PGI+Sm9pbiBieSBwaG9uZTwvYj48L3RkPjwvdHI+PHRy IHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS04NzctNjY4LTQ0OTM8L2I+Jm5ic3A7Q2FsbC1p biB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2lu OjBweCI+PHRkPjxiPjEtNjUwLTQ3OS0zMjA4PC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIg KFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+QWNjZXNzIGNv ZGU6Jm5ic3A7NjQ5IDY5NiA5ODg8L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+ PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5w ZGYiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNweDtjb2xvcjojMDBB RkY5OyI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9hPjwvdGQ+PC90cj48L3RhYmxl PgoKCQkJCQk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQgc3R5bGU9Imhl aWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0ZCBzdHlsZT0i Zm9udC1zaXplOjEzcHgiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW04ODRlODg5MjAxNTE1NzI0ZWFlMjBlOTI4ZDcyNTg3YiIgc3R5bGU9InRleHQtZGVj b3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjk7IGZvbnQtc2l6ZToxM3B4Ij5BZGQgdGhpcyBtZWV0 aW5nPC9hPiB0byB5b3VyIGNhbGVuZGFyLjwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+PHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwv dGQ+PC90cj48L3RhYmxlPgo8dGFibGU+CiAgICA8dHI+CiAgICAgICA8dGQgc3R5bGU9ImZvbnQt c2l6ZTogMTNweDtmb250LWZhbWlseTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7Ij4KICAgICAgICBD YW4ndCBqb2luIHRoZSBtZWV0aW5nPwogICAgIAk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvbWMiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTNweDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjojMDBBRkY5O2ZvbnQtY29sb3I6IzAwQUZGOTsiPgogICAg ICAgIAlDb250YWN0IHN1cHBvcnQuPC9hPgoJCTwvdGQ+CiAgICA8L3RyPgo8L3RhYmxlPgo8dGFi bGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMTBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjEwcHgi PiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGU+CgkJCQkJCQk8dHI+CgkJCQkJ CQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTJweDtjb2xvcjogI0EwQTBBMDsiPgoJCQkJCQkJCQlJ TVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxv d3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRv IGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVy LiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBz dWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwg ZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNl c3Npb24uPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgkJCQk8L3RkPgoJCQk8L3Ry PgoJCTwvdGFibGU+Cgk8L3RkPgogICA8L3RyPgo8L3RhYmxlPgoKPC9ib2R5Pg== ------=_Part_17429_1262848565.1423055644195-- ------=_Part_17428_960801594.1423055644195 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MDIwNFQxNjAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTUwMjA0VDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDIzMDU1NjQ0ClVJRDo2ZTc0YzYzZi1k Yzk4LTQ0YjgtODJiNi04OGE4YjViMGU2YjMKRFRTVEFNUDoyMDE1MDIwNFQxNTAwMDBaCkRFU0NS SVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bTZiNTVhYzNmYTU3MjIxYjkzMTQ1OGI2MzYxZWQ3N2U0XG5NZWV0aW5n IG51bWJlcjogNjQ5IDY5NiA5ODhcbk1lZXRpbmcgcGFzc3dvcmQ6IHVDOGNpZXNoXG5cblxuSk9J TiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxu QWNjZXNzIGNvZGU6IDY0OSA2OTYgOTg4XG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9u czogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRw czovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ug bm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9y bWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkg YmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lv biwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBk byBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdp dGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRU WVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW02YjU1YWMzZmE1NzIyMWI5MzE0NThiNjM2MWVkNzdlNCI+ PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1l ZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05U PgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjY0OSA2OTYgOTg4PC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3Rh YmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+dUM4Y2llc2g8L0ZPTlQ+PC90ZD48L3RyPjwv dGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJz cDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04 NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0Nh bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ5IDY5NiA5ODg8L0ZPTlQ+ Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz dHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwv Rk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAw QUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+ Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUKQ0xB U1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZCkRFU0NS SVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== ------=_Part_17428_960801594.1423055644195-- From nobody Wed Feb 4 05:21:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82C41A87EB for ; Wed, 4 Feb 2015 05:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AqG8pHBN4dB for ; Wed, 4 Feb 2015 05:20:46 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCF11A8823 for ; Wed, 4 Feb 2015 05:20:46 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id EA4041CC00A8; Wed, 4 Feb 2015 14:20:55 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <201502021841.t12If4RQ027232@idle.juniper.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 04 Feb 2015 14:20:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y34: use cases for anydata X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:20:51 -0000 Andy Bierman writes: > On Tue, Feb 3, 2015 at 8:29 AM, Ladislav Lhotka wrote: >> Phil Shafer writes: >> >>> Ladislav Lhotka writes: >>>>It's not about saving a few bytes on the wire but rather about keeping the interface betw >>>>een JSON encoding/decoding and an application simple and straightforward. >>> >>> It should be about putting the data into a format where the client >>> can use it. If 42 is a string, code like: >>> >>> if (code > 40) { .... } >>> >>> will fail. >> >> Agreed. >> >>> >>>>I guess this simplicity is the main reason why programmers prefer JSON to XML - no DOMs >>>>or things like that are needed in the middle. >>> >>> My take is that people like JSON because it translates trivially >>> into local data structures. You can think of the lack of quotes >>> around select values and the presense of "[ ... ]" as a cheap means >>> of shipping meta-data in with JSON's data, just enough to allow the >>> receiver to decode it. Using JSON from typeless languages like >>> javascript or python yields simpler coding. >> >> And in strongly typed languages, using a standard JSON parser usually >> means that the receiver has to know the type of each value in order to >> be able to extract it from the parsed structure. >> > > It would be unwise to design code this way with "anyxml" data. > IMO, inline data structures are horrible for APIs. The "schema" is > made up by the sender on the fly. I think we are still mixing anyxml with other YANG nodes in this discussion. > > I often see JSON from customers that uses an object instead of > a 1-element array, or quoted numbers. IMO the receiver > has to deal with this sloppy encoding, especially for anyxml. Again, two cases: - anydata/anyxml: it's outside the scope for YANG but there may be other schema/protocol/rules, and these have to decide what will be accepted and what not. - other YANG nodes: for XML encoding the rules in 6020 are relatively strict, and nothing forces the receiver to deal with sloppy encoding. I don't see any reason why JSON encoding should be different. Lada > > >> Lada >> > > Andy > >>> >>> Thanks, >>> Phil >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Feb 4 05:52:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F62D1A87A3 for ; Wed, 4 Feb 2015 05:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb-icWZoVzNi for ; Wed, 4 Feb 2015 05:52:04 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154BB1A8825 for ; Wed, 4 Feb 2015 05:52:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DB40A15CA for ; Wed, 4 Feb 2015 14:52:02 +0100 (CET) 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 wLVvefB0bL8s for ; Wed, 4 Feb 2015 14:51:48 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 4 Feb 2015 14:52:02 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41A9D20037 for ; Wed, 4 Feb 2015 14:52:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id azUBOzakYnS4; Wed, 4 Feb 2015 14:52:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3540A20035; Wed, 4 Feb 2015 14:52:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5F03D3182ACC; Wed, 4 Feb 2015 14:52:01 +0100 (CET) Date: Wed, 4 Feb 2015 14:52:01 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150204135201.GA7145@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.4.2.3i Archived-At: Subject: [netmod] yang 1.1 status summary X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2015 13:52:07 -0000 Hi, here is where we are with the YANG 1.1 effort. | Status | Description | Count | |--------+----------------------------------------+-------| | NEW | new issue | 0 | | DEAD | issue has been rejected | 26 | | OPEN | open to discuss | 7 | | VRFY | proposal to verify on the list | 2 | | EDIT | waiting for Martin to do the edits | 3 | | REVIEW | waiting for the WG to review the edits | 21 | | DONE | review has completed | 0 | |--------+----------------------------------------+-------| Here is a more list detailing where I think we are with the issues that are OPEN or that were moved to VRFY recently: * VRFY :Y09: introduce optional keys <> -> pending action JS (verify moving to dead on mailing list>) * VRFY :Y16: module advertisement optimization <> -> pending action JS (verify issue resolution on mailing list) * VRFY :Y34: remove/deprecate/replace the 'anyxml' statement -> tons of emails due to its interaction with JSON encodings * OPEN :Y18: fix "when" expression context problem -> pending action MB done, ready to discuss again * OPEN :Y25: make enum numbering purely informative and optional -> pending verify action JS, new position Andy Bierman * OPEN :Y26: allow mandatory nodes in augment -> we need concrete proposals how to relax the current rules * OPEN :Y45: better conformance mechanism <> -> we need to schedule a meeting with just this topic, could be 2015-02-18; MB has written up an I-D, there is AB's I-D * OPEN :Y57: non-unique leaf-list -> ready to be discussed? * OPEN :Y58: associate actions with a data node -> JS to verify with NETCONF chairs that NETCONF is doing a NACM revision, then verify again on mailing list /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Feb 4 06:42:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86451A8784 for ; Wed, 4 Feb 2015 06:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.259 X-Spam-Level: X-Spam-Status: No, score=-4.259 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFrkzDP2PCWT for ; Wed, 4 Feb 2015 06:42:24 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37061A8981 for ; Wed, 4 Feb 2015 06:42:24 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 777BC1834; Wed, 4 Feb 2015 15:42:23 +0100 (CET) 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 gX1ufF6pEi9p; Wed, 4 Feb 2015 15:42:08 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 4 Feb 2015 15:42:22 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF44A20035; Wed, 4 Feb 2015 15:42:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N9JmRh9UOUem; Wed, 4 Feb 2015 15:42:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 299B120036; Wed, 4 Feb 2015 15:42:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 54ABD31832ED; Wed, 4 Feb 2015 15:42:21 +0100 (CET) Date: Wed, 4 Feb 2015 15:42:21 +0100 From: Juergen Schoenwaelder To: netmod-chairs@tools.ietf.org Message-ID: <20150204144221.GA8469@elstar.local> Mail-Followup-To: netmod-chairs@tools.ietf.org, netmod@ietf.org References: <1114948654.17430.1423055644195.JavaMail.nobody@jva2tc101.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1114948654.17430.1423055644195.JavaMail.nobody@jva2tc101.webex.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2015 14:42:28 -0000 Hi, the etherpad we are going to use is this one: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2015-02-04?useMonospaceFont=true /js On Wed, Feb 04, 2015 at 01:14:04PM +0000, NETMOD Working Group wrote: > > Hello, > > NETMOD Working Group invites you to join this WebEx meeting. > > > NETMOD YANG 1.1 > Wednesday, February 4, 2015 > 4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hrs > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=me87babc2b12515a7e672ab729109c744 > Meeting number: 649 696 988 > Meeting password: uC8ciesh > > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 649 696 988 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=m884e889201515724eae20e928d72587b > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Feb 4 08:54:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADEE1A1A02 for ; Wed, 4 Feb 2015 08:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLApr-XOl-yb for ; Wed, 4 Feb 2015 08:54:40 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C231A19F2 for ; Wed, 4 Feb 2015 08:54:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6D6131CA9 for ; Wed, 4 Feb 2015 17:54:38 +0100 (CET) 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 0BWkBIUSg_uT for ; Wed, 4 Feb 2015 17:54:22 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 4 Feb 2015 17:54:37 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B6ED20036 for ; Wed, 4 Feb 2015 17:54:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2DOgH88DMB7N; Wed, 4 Feb 2015 17:54:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF37220035; Wed, 4 Feb 2015 17:54:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6ABE23184F88; Wed, 4 Feb 2015 17:54:35 +0100 (CET) Date: Wed, 4 Feb 2015 17:54:35 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150204165434.GA11693@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] minutes of the NETMOD 2015-02-04 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2015 16:54:41 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the minutes of the 2015-02-04 virtual interim meeting. Please let me know if something needs fixing. You can find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2015-02-04-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 12th YANG 1.1 Virtual Interim Wednesday, February 4th, 2015, 16:00-17:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants: JS = Juergen Schoenwaelder LL = Lada Lhotka BL = Balazs Lengyel MB = Martin Bjoerklund IB = Ignas Bagdonas KW = Kent Watsen SH = Susan Hares * Status: Charter: Mar 2015 - Submit YANG 1.1 to the IESG IETF 92: March 22 - 27, 2015 IETF 92 I-D cutoff: 2015-03-09 Virtual meetings: 2015-02-04 (today) 2015-02-18 (focus on conformance) 2015-03-04 2015-03-18 - VRFY :Y09: introduce optional keys <> -> pending action JS (verify moving to dead on mailing list>) - VRFY :Y16: module advertisement optimization <> -> pending action JS (verify issue resolution on mailing list) - VRFY :Y34: remove/deprecate/replace the 'anyxml' statement -> tons of emails due to its interaction with JSON encodings - OPEN :Y18: fix "when" expression context problem -> pending action MB done, ready to discuss again - OPEN :Y25: make enum numbering purely informative and optional -> pending verify action JS, new position Andy Bierman - OPEN :Y26: allow mandatory nodes in augment -> we need concrete proposals how to relax the current rules - OPEN :Y45: better conformance mechanism <> -> we need to schedule a meeting with just this topic, could be 2015-02-18; MB has written up an I-D, there is AB's I-D - OPEN :Y57: non-unique leaf-list -> ready to be discussed? - OPEN :Y58: associate actions with a data node -> JS to verify with NETCONF chairs that NETCONF is doing a NACM revision, then verify again on mailing list MB: We proposed to add a new issue (1.0 and 1.1 coexistence) JS: Yes, but it is not yet added to the issues list. * Y34 remove/deprecate/replace the 'anyxml' statement JS: Solution Y34-05 Same as Y34-02 plus two guidelines adopted from Y34-04: - For YANG 1.0 backward compatibility, allow anyxml to be used, except implementations MAY restrict the XML; document that anyxml is not considered interoperable. - The guidelines document should say that YANG Doctors will review each use of anyxml in IETF modules when YANG 1.1 is adopted to avoid its use whenever possible Proposal: try to run Y34-05 through the verify phase We will move the JSON document based on YANG 1.0 forward, the plan is to revise the JSON document once YANG 1.1 is done. LL will check whether a new version is needed before we go to WG last call. * Y18 fix "when" expression context problem LL: I did send a question to the list: http://mailarchive.ietf.org/arch/msg/netmod/haP-w-KYM0QkxzYtUBeA2E3BNE0 MB: It may be desirable to have the same algorithm, regardless whether the node exists or not. MB: I think my solution works even in cases where you have leaf-lists. LL: But it might be possible to construct cases where it does not work. The issue is what we do in the case with multiple instances. The must statement does not have this problem. MB: Perhaps we need a warning that certain expressions may not be meaningful or interoperable. JS: Is it possible fill out "if the when expression contains (xxx), then the interpretation is implementation specific"?. Action: LL and MB to work out a proposal for this corner case * Y57 non-unique leaf-list BL: I will revise the proposal and post an updated solution to the mailing list. * Y58 associate actions with a data node JS to get final confirmation from NETCONF chairs, then try to close the VRFY phase on the mailing list. --UugvWAfsgieZRqgk-- From nobody Wed Feb 4 09:21:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6461A1A59 for ; Wed, 4 Feb 2015 09:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5SeQTuavqN6 for ; Wed, 4 Feb 2015 09:21:46 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041A41A1A6C for ; Wed, 4 Feb 2015 09:21:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C1AC51811 for ; Wed, 4 Feb 2015 18:21:44 +0100 (CET) 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 yaWMO2OR0m7X for ; Wed, 4 Feb 2015 18:21:29 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 4 Feb 2015 18:21:44 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DDDC20035 for ; Wed, 4 Feb 2015 18:21:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RIhAet802EGR; Wed, 4 Feb 2015 18:21:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAE1920036; Wed, 4 Feb 2015 18:21:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E245131854FD; Wed, 4 Feb 2015 18:21:42 +0100 (CET) Date: Wed, 4 Feb 2015 18:21:42 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150204172142.GC11761@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.4.2.3i Archived-At: Subject: [netmod] yang 1.1 timeline / upcoming meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2015 17:21:57 -0000 Hi, the charters says that we should be done with YANG 1.1 by March 2015 (submit to IESG). This is not achievable anymore. What is achievable I think is to have resolved all issues by the end of March so that we can get into WG last call mode sometime in April/May. One of the most complicated open issues remains conformance. We will focus the next virtual interim meeting (2015-02-18) on conformance. Note that there are two relevant I-Ds [1,2] and there are minutes of the conformance discussions we had before at the interim meeting we had in New York. To be effective, I like to ask people to come prepared to the virtual interim meeting. We will have another virtual interim meeting on 2015-03-04, a couple of days before the I-D cutoff on 2015-03-09 and we have another allocated on 2015-03-18 should we need it. We (the NETMOD) chairs requested two meeting slots at the March IETF meeting, one slot will be dedicated to the YANG infrastructure work. If approved, we also have sufficient face-to-face time in Dallas. But we should use this primarily as a backup and try to make as much progress as possible before the Dallas meeting using our virtual interims and the mailing list. /js [1] https://tools.ietf.org/html/draft-bjorklund-yang-conformance-problem-00 [2] https://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-04 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 4 11:33:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2174C1A1BC5 for ; Wed, 4 Feb 2015 11:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDuSm3Zqvb58 for ; Wed, 4 Feb 2015 11:33:29 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E287F1A1B4F for ; Wed, 4 Feb 2015 11:33:28 -0800 (PST) Received: from BY2PR05CA025.namprd05.prod.outlook.com (10.141.250.15) by DM2PR05MB448.namprd05.prod.outlook.com (10.141.104.152) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 4 Feb 2015 19:33:27 +0000 Received: from BL2FFO11FD030.protection.gbl (2a01:111:f400:7c09::182) by BY2PR05CA025.outlook.office365.com (2a01:111:e400:2c5f::15) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Wed, 4 Feb 2015 19:33:26 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD030.mail.protection.outlook.com (10.173.161.40) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Wed, 4 Feb 2015 19:33:25 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 4 Feb 2015 11:32:43 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t14JWgW04655; Wed, 4 Feb 2015 11:32:42 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t14JWRPu046279; Wed, 4 Feb 2015 14:32:28 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502041932.t14JWRPu046279@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20150204165434.GA11693@elstar.local> Date: Wed, 4 Feb 2015 14:32:27 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(5423002)(50466002)(86362001)(230783001)(87936001)(19580395003)(6806004)(46102003)(48376002)(50986999)(54356999)(47776003)(62966003)(2950100001)(77156002)(106466001)(105596002)(110136001)(77096005)(15975445007)(76506005)(92566002)(561944003)(53416004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB448; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB448; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR05MB448; X-Forefront-PRVS: 04772EA191 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB448; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Feb 2015 19:33:25.9613 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB448 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] minutes of the NETMOD 2015-02-04 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 19:33:31 -0000 Juergen Schoenwaelder writes: > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >* Y34 remove/deprecate/replace the 'anyxml' statement > > JS: Solution Y34-05 > > Same as Y34-02 plus two guidelines adopted from Y34-04: > > - For YANG 1.0 backward compatibility, allow anyxml to be used, > except implementations MAY restrict the XML; document that > anyxml is not considered interoperable. > - The guidelines document should say that YANG Doctors will review > each use of anyxml in IETF modules when YANG 1.1 is adopted to > avoid its use whenever possible Do we have a list of what makes anyxml not interoperable? Can JSON just encode this as a string? Is the concern just namespace issues? Can the JSON encoder be responsible for including any required xmlns attributes with the contents? >* Y57 non-unique leaf-list > BL: I will revise the proposal and post an updated solution to the > mailing list. Okay, I'm completely biased in that I think non-unique leaf-list is a mostly evil idea, but..... A simpler fix might be added "position" as a value for "ordered-by". leaf-list bytes { ordered-by position; } would also allow: list note { ordered-by position; choice note { leaf a { type empty; } ... leaf g { type empty; } } choice flat-or-sharp { leaf flat { type empty; } leaf sharp { type empty; } } } Allowing: (Yeah, long way to go for that, eh?) But long term, this is still a horrible idea, since positions aren't constant and require a "fetch before change" that isn't otherwise vital. It's setting clients up to trample on each other, which affects stability and interoperability. >* Y58 associate actions with a data node > > JS to get final confirmation from NETCONF chairs, then try to close > the VRFY phase on the mailing list. I'm still opposed to this, given that it's not needed. Nothing can be done with this feature that can't be done without it. It's really the first step in attempting to turn YANG into an object-oriented data modeling language, which it's not set up to be. And shouldn't be. There's an ocean of OO facilities that we don't have/need/want, including inheritance, polymorphism, interfaces, etc. There's a strong desire to keep extending a technology to allow it to address all sorts of it wasn't designed for. "Yeah we could do that too if we just added this little bit". The results are fairly predictable; the simple little system turns into a complex, fragile system. Consider YAML, where 1.2 added more complex but useless features that after five years, only one implementation (in Haskell) supports it. Or XSLT, where the 2.0 spec exploded with lots of features that aren't used because only saxon implements them. Addon features decrease interoperability, and impact the stability and "done"-ness of our technologies. I'm fine with fixing bugs, clarifying the spec, and removing opportunities for errors, but adding new features is imho a non-starter. Sorry, that turned into a rant somewhere along the way, but, well.... Thanks, Phil From nobody Wed Feb 4 12:17:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6621A1B72 for ; Wed, 4 Feb 2015 12:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE-BlUHNOvIL for ; Wed, 4 Feb 2015 12:17:08 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 DE0B21A1A22 for ; Wed, 4 Feb 2015 12:17:07 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so3564650lbv.3 for ; Wed, 04 Feb 2015 12:17:06 -0800 (PST) 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:content-type; bh=0f9PT/SFuxf01uTv5pq/Nwyi6Q2J6A6Lg7vyYd3qijY=; b=AI2vbNYPC0HTom3T2i00q5PP35RRTNQ37aE26sV3PdCYBOyiALHqN2Yq4b4uWZ6xvZ ZD3M+Dzuv8yzEHcKtgF9wI0DWyEu7WedFErZjmCW2IAJH10F+qtEl0NawOqK4U+QvU/W ymoBKx9nzL+77zcs/aVY6Q7aNAnSnQHLB8KU6XGXDYNWL/lVdVSiN7/5P/ivpD/FKCQS cr8mEpLm2rmD/N3fQBdH9Digm3uhr6H43CoIPPDHCibFLzPvYNsSOl5YR2cXxc14a8GZ TaeAOy/VLPekd0IW3hh1fC48kYJvuWCZkx0SBM/kL1VMz3LNV5b2GquAnisHOaBKE+LA q9lw== X-Gm-Message-State: ALoCoQliolKMzj/bcVKKNPdilZ1izwXQRb8pD2+kEiO84lTx/yeyudreaVDr78os/gj6BL+t7uyj MIME-Version: 1.0 X-Received: by 10.112.137.38 with SMTP id qf6mr5211lbb.59.1423081026367; Wed, 04 Feb 2015 12:17:06 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 4 Feb 2015 12:17:06 -0800 (PST) In-Reply-To: <201502041932.t14JWRPu046279@idle.juniper.net> References: <20150204165434.GA11693@elstar.local> <201502041932.t14JWRPu046279@idle.juniper.net> Date: Wed, 4 Feb 2015 12:17:06 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] minutes of the NETMOD 2015-02-04 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 20:17:10 -0000 On Wed, Feb 4, 2015 at 11:32 AM, Phil Shafer wrote: > Juergen Schoenwaelder writes: >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ >>* Y34 remove/deprecate/replace the 'anyxml' statement >> >> JS: Solution Y34-05 >> >> Same as Y34-02 plus two guidelines adopted from Y34-04: >> >> - For YANG 1.0 backward compatibility, allow anyxml to be used, >> except implementations MAY restrict the XML; document that >> anyxml is not considered interoperable. >> - The guidelines document should say that YANG Doctors will review >> each use of anyxml in IETF modules when YANG 1.1 is adopted to >> avoid its use whenever possible > > Do we have a list of what makes anyxml not interoperable? Can JSON > just encode this as a string? Is the concern just namespace issues? > Can the JSON encoder be responsible for including any required xmlns > attributes with the contents? > >>* Y57 non-unique leaf-list >> BL: I will revise the proposal and post an updated solution to the >> mailing list. > > Okay, I'm completely biased in that I think non-unique leaf-list is > a mostly evil idea, but..... > > A simpler fix might be added "position" as a value for "ordered-by". > > leaf-list bytes { > ordered-by position; > } > > would also allow: > > list note { > ordered-by position; > choice note { > leaf a { type empty; } > ... > leaf g { type empty; } > } > choice flat-or-sharp { > leaf flat { type empty; } > leaf sharp { type empty; } > } > } > > Allowing: > > > > > > > > (Yeah, long way to go for that, eh?) > > But long term, this is still a horrible idea, since positions aren't > constant and require a "fetch before change" that isn't otherwise > vital. It's setting clients up to trample on each other, which > affects stability and interoperability. > I am not convinced that the "ordered-by" statement is a good idea. It does not map well across different APIs, such as CLI. (e.g., ACE ordering in ACL discussion last year). It is not likely that constrained devices will support an "insert" operation. The ordered-by user option seems to require a lot of added code to avoid using an explicit key leaf. >>* Y58 associate actions with a data node >> >> JS to get final confirmation from NETCONF chairs, then try to close >> the VRFY phase on the mailing list. > > I'm still opposed to this, given that it's not needed. Nothing can > be done with this feature that can't be done without it. > > It's really the first step in attempting to turn YANG into an > object-oriented data modeling language, which it's not set up to > be. And shouldn't be. There's an ocean of OO facilities that we > don't have/need/want, including inheritance, polymorphism, interfaces, > etc. > > There's a strong desire to keep extending a technology to allow it > to address all sorts of it wasn't designed for. "Yeah we could do > that too if we just added this little bit". The results are fairly > predictable; the simple little system turns into a complex, fragile > system. It was never that simple to implement, but I agree that the language should be expanded with caution. This is clearly a new feature, not a bugfix as required in the YANG 1.1 charter. But I believe Martin when he says it is a very popular tail-f extension. It does allow more granular access control, so it is not quite true that we can do the exact same thing with rpc-stmt. However, it is not clear how to constrain the "instances" of a particular action within a module. Is /foo/bar/reset required to be exactly the same syntax and behavior as /foo/baz/reset? Is it good to have this text (entire action-stmt) cut-and-paste all over the module? Each one with slightly different (or way different) description-stmts? This might be confusing to readers and unwarranted complexity for developers. > > Consider YAML, where 1.2 added more complex but useless features > that after five years, only one implementation (in Haskell) supports > it. Or XSLT, where the 2.0 spec exploded with lots of features > that aren't used because only saxon implements them. > > Addon features decrease interoperability, and impact the stability > and "done"-ness of our technologies. I'm fine with fixing bugs, > clarifying the spec, and removing opportunities for errors, but > adding new features is imho a non-starter. > > Sorry, that turned into a rant somewhere along the way, but, well.... > > Thanks, > Phil > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Feb 5 01:31:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2101A0146 for ; Thu, 5 Feb 2015 01:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 X1Bk95c0ImtN for ; Thu, 5 Feb 2015 01:31:16 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 784271A0140 for ; Thu, 5 Feb 2015 01:31:16 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 5BD801280B3D; Thu, 5 Feb 2015 10:31:15 +0100 (CET) Date: Thu, 05 Feb 2015 10:31:15 +0100 (CET) Message-Id: <20150205.103115.1336007090171612415.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150204165434.GA11693@elstar.local> <201502041932.t14JWRPu046279@idle.juniper.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / 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] minutes of the NETMOD 2015-02-04 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 09:31:18 -0000 Andy Bierman wrote: > On Wed, Feb 4, 2015 at 11:32 AM, Phil Shafer wrote: > > Juergen Schoenwaelder writes: > >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > >>* Y34 remove/deprecate/replace the 'anyxml' statement > >> > >> JS: Solution Y34-05 > >> > >> Same as Y34-02 plus two guidelines adopted from Y34-04: > >> > >> - For YANG 1.0 backward compatibility, allow anyxml to be used, > >> except implementations MAY restrict the XML; document that > >> anyxml is not considered interoperable. > >> - The guidelines document should say that YANG Doctors will review > >> each use of anyxml in IETF modules when YANG 1.1 is adopted to > >> avoid its use whenever possible > > > > Do we have a list of what makes anyxml not interoperable? Can JSON > > just encode this as a string? Is the concern just namespace issues? > > Can the JSON encoder be responsible for including any required xmlns > > attributes with the contents? > > > >>* Y57 non-unique leaf-list > >> BL: I will revise the proposal and post an updated solution to the > >> mailing list. > > > > Okay, I'm completely biased in that I think non-unique leaf-list is > > a mostly evil idea, but..... > > > > A simpler fix might be added "position" as a value for "ordered-by". > > > > leaf-list bytes { > > ordered-by position; > > } > > > > would also allow: > > > > list note { > > ordered-by position; > > choice note { > > leaf a { type empty; } > > ... > > leaf g { type empty; } > > } > > choice flat-or-sharp { > > leaf flat { type empty; } > > leaf sharp { type empty; } > > } > > } > > > > Allowing: > > > > > > > > > > > > > > > > (Yeah, long way to go for that, eh?) > > > > But long term, this is still a horrible idea, since positions aren't > > constant and require a "fetch before change" that isn't otherwise > > vital. It's setting clients up to trample on each other, which > > affects stability and interoperability. +1 > I am not convinced that the "ordered-by" statement is a good idea. > It does not map well across different APIs, such as CLI. > (e.g., ACE ordering in ACL discussion last year). > > It is not likely that constrained devices will support an "insert" > operation. The ordered-by user option seems to require a lot > of added code to avoid using an explicit key leaf. > > > >>* Y58 associate actions with a data node > >> > >> JS to get final confirmation from NETCONF chairs, then try to close > >> the VRFY phase on the mailing list. > > > > I'm still opposed to this, given that it's not needed. Nothing can > > be done with this feature that can't be done without it. > > > > It's really the first step in attempting to turn YANG into an > > object-oriented data modeling language, which it's not set up to > > be. And shouldn't be. There's an ocean of OO facilities that we > > don't have/need/want, including inheritance, polymorphism, interfaces, > > etc. > > > > There's a strong desire to keep extending a technology to allow it > > to address all sorts of it wasn't designed for. "Yeah we could do > > that too if we just added this little bit". The results are fairly > > predictable; the simple little system turns into a complex, fragile > > system. > > It was never that simple to implement, but I agree that the language > should be expanded with caution. This is clearly a new feature, > not a bugfix as required in the YANG 1.1 charter. But I believe Martin > when he says it is a very popular tail-f extension. > > It does allow more granular access control, so it is not quite true > that we can do the exact same thing with rpc-stmt. However, it > is not clear how to constrain the "instances" of a particular action > within a module. > > Is /foo/bar/reset required to be exactly the same syntax and > behavior as /foo/baz/reset? No; just like leafs /foo/bar/xxx and /foo/baz/xxx are not required to be the same syntax and/or semantics. > Is it good to have > this text (entire action-stmt) cut-and-paste all over the module? > Each one with slightly different (or way different) description-stmts? > This might be confusing to readers and unwarranted complexity > for developers. Just like with data nodes, reusable actions can be put in a grouping and resused insetad of copy&pasted. > > Consider YAML, where 1.2 added more complex but useless features > > that after five years, only one implementation (in Haskell) supports > > it. Or XSLT, where the 2.0 spec exploded with lots of features > > that aren't used because only saxon implements them. > > > > Addon features decrease interoperability, and impact the stability > > and "done"-ness of our technologies. I'm fine with fixing bugs, > > clarifying the spec, and removing opportunities for errors, but > > adding new features is imho a non-starter. There are certainly examples where the added features made a successor fail, but there are also examples where that did not happen. One such example from the IETF is SMIv2. But you are right that adding features must be done carefully. /martin From nobody Thu Feb 5 04:14:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497521A8722 for ; Thu, 5 Feb 2015 04:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBHmJFiuYqvt for ; Thu, 5 Feb 2015 04:14:50 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2781A8724 for ; Thu, 5 Feb 2015 04:14:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7FCDD1A1F; Thu, 5 Feb 2015 13:14:49 +0100 (CET) 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 onh-304wkpGl; Thu, 5 Feb 2015 13:14:29 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Feb 2015 13:14:49 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C39462003A; Thu, 5 Feb 2015 13:14:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id chO3n1xP7Q3G; Thu, 5 Feb 2015 13:14:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B398E20037; Thu, 5 Feb 2015 13:14:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D184031900CD; Thu, 5 Feb 2015 13:14:47 +0100 (CET) Date: Thu, 5 Feb 2015 13:14:47 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150205121447.GA38307@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.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2015 12:14:52 -0000 On Thu, Jan 29, 2015 at 05:09:11PM +0100, Ladislav Lhotka wrote: > > Objections, comments, other issues? > The I-JSON document has changed its structure and the section references now need updating. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 5 04:52:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48AB1A8768 for ; Thu, 5 Feb 2015 04:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaKWj3-kSoaN for ; Thu, 5 Feb 2015 04:52:12 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 061B31A0091 for ; Thu, 5 Feb 2015 04:52:12 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id C61D71280B3D; Thu, 5 Feb 2015 13:52:10 +0100 (CET) Date: Thu, 05 Feb 2015 13:52:10 +0100 (CET) Message-Id: <20150205.135210.818152609244122122.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 12:52:13 -0000 Ladislav Lhotka wrote: > Hi, > = > $SUBJ is already several months late, so I think we should proceed > towards delivering it. I checked my mail archive since the -02 revisi= on, > and it seems two issues need to be resolved: > = > 1. Andy objected to making redundant namespace prefixes illegal. I > propose the following change to 4th paragraph in sec.=A04 (SHOULD = NOT > instead of MUST NOT): > = > OLD > = > Names with namespace identifiers in the form shown in Figure 1 MUS= T > be used for all top-level YANG data nodes, and also for all nodes > whose parent node belongs to a different namespace. Otherwise, na= mes > with namespace identifiers MUST NOT be used. > = > NEW > = > Names with namespace identifiers in the form shown in Figure 1 MUS= T > be used for all top-level YANG data nodes, and also for all nodes > whose parent node belongs to a different namespace. Otherwise, na= mes > with namespace identifiers SHOULD NOT be used. I don't think this is a good idea. The reason is that it complicates both client and server code. An implementation cannot write code like this: name =3D interface['name'] mtu =3D interface['mtu'] instead we have to look for both 'name' and 'ietf-interfaces:name': if 'name' in interface: name =3D interface['name'] else name =3D interface['ietf-interfaces:name'] One single deterministic encoding is simpler everywhere and less error-prone. = > 2. anyxml encoding: although it is a misnomer, I propose to keep the > current definition (sec. 5.5), i.e. allow any valid JSON value in > JSON-encoded anyxml instances. I also think the text makes it > sufficiently clear that no standard mapping between XML- and > JSON-encoded instances is defined. Ok. /martin From nobody Thu Feb 5 05:01:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0081A8762 for ; Thu, 5 Feb 2015 05:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 E3nf2Xx2x51F for ; Thu, 5 Feb 2015 05:01:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DD61A874C for ; Thu, 5 Feb 2015 05:01:37 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:e580:7737:4dc8:f9ba] (unknown [IPv6:2001:1488:fffe:6:e580:7737:4dc8:f9ba]) by mail.nic.cz (Postfix) with ESMTPSA id 7E12B140075; Thu, 5 Feb 2015 14:01:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423141295; bh=gGqoVRmiDO2grJGKTeNR3Jnu06hnz0fGPCC9lepEv0Q=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ojTyUYWHgu1pSeYTPtlE8TPSTTuV09NlbecaQ3gQU6DVMWs+GSyqvQv+iXnyEU4DA 86ejOA1C95q11IbW0Qbc+m0bXIph4IW3JWtYo1Ue7sEK5AztImn95lZ73K1KIuDHr4 dspAgw8+wO5s+feeoELrEO+9zkcffW4Cbm9or578= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150205121447.GA38307@elstar.local> Date: Thu, 5 Feb 2015 14:01:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150205121447.GA38307@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:01:39 -0000 > On 05 Feb 2015, at 13:14, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 29, 2015 at 05:09:11PM +0100, Ladislav Lhotka wrote: >>=20 >> Objections, comments, other issues? >>=20 >=20 > The I-JSON document has changed its structure and the section > references now need updating. I=E2=80=99ll check the changes. Thanks, 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 Feb 5 05:49:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EC01A887A for ; Thu, 5 Feb 2015 05:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 oNeBmZJgSe2a for ; Thu, 5 Feb 2015 05:49:33 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5456C1A8864 for ; Thu, 5 Feb 2015 05:49:33 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:e580:7737:4dc8:f9ba] (unknown [IPv6:2001:1488:fffe:6:e580:7737:4dc8:f9ba]) by mail.nic.cz (Postfix) with ESMTPSA id 5594713F9AF; Thu, 5 Feb 2015 14:49:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423144171; bh=cQ+dvMh4vagc0yugdJKneGiXKkpfTj5yJlPdUsa/ZeU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mICkzJlRxNJY7gD03k70DpmQRzNNnhReG4yEeRLHNSJr/9VAXKOUmYKrxcTk2rbjH 4IacubxXvEVwY7jqH5FDpCF3k3COOeEPTPLk5kru9kytwP7/yx0X7mpZytZlKA7O3y qRVeeObMXFNPFH3XwrVIeVYSu/uvePTfmTM3CLvQ= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150205.135210.818152609244122122.mbj@tail-f.com> Date: Thu, 5 Feb 2015 14:49:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> References: <20150205.135210.818152609244122122.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 13:49:34 -0000 > On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> $SUBJ is already several months late, so I think we should proceed >> towards delivering it. I checked my mail archive since the -02 = revision, >> and it seems two issues need to be resolved: >>=20 >> 1. Andy objected to making redundant namespace prefixes illegal. I >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> instead of MUST NOT): >>=20 >> OLD >>=20 >> Names with namespace identifiers in the form shown in Figure 1 MUST >> be used for all top-level YANG data nodes, and also for all nodes >> whose parent node belongs to a different namespace. Otherwise, = names >> with namespace identifiers MUST NOT be used. >>=20 >> NEW >>=20 >> Names with namespace identifiers in the form shown in Figure 1 MUST >> be used for all top-level YANG data nodes, and also for all nodes >> whose parent node belongs to a different namespace. Otherwise, = names >> with namespace identifiers SHOULD NOT be used. >=20 > I don't think this is a good idea. The reason is that it complicates > both client and server code. An implementation cannot write code like > this: >=20 > name =3D interface['name'] > mtu =3D interface['mtu'] >=20 > instead we have to look for both 'name' and 'ietf-interfaces:name': >=20 > if 'name' in interface: > name =3D interface['name'] > else > name =3D interface['ietf-interfaces:name'] >=20 >=20 > One single deterministic encoding is simpler everywhere and less > error-prone. I agree with you, this again makes standard JSON parsers (that give you = a pointer to the parsed structure) considerably less useful. Lada=20 >=20 >> 2. anyxml encoding: although it is a misnomer, I propose to keep the >> current definition (sec. 5.5), i.e. allow any valid JSON value in >> JSON-encoded anyxml instances. I also think the text makes it >> sufficiently clear that no standard mapping between XML- and >> JSON-encoded instances is defined. >=20 > Ok. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 5 06:00:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931DF1A8836 for ; Thu, 5 Feb 2015 06:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kaOvpVV0BAy for ; Thu, 5 Feb 2015 06:00:48 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A761A882D for ; Thu, 5 Feb 2015 06:00:47 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5AF4B1ACC; Thu, 5 Feb 2015 15:00:46 +0100 (CET) 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 81Xx5WLsLsZo; Thu, 5 Feb 2015 15:00:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Feb 2015 15:00:44 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3FEBD20036; Thu, 5 Feb 2015 15:00:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sxccCUF8Fuhd; Thu, 5 Feb 2015 15:00:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3C5520035; Thu, 5 Feb 2015 15:00:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1544C31911D2; Thu, 5 Feb 2015 15:00:42 +0100 (CET) Date: Thu, 5 Feb 2015 15:00:42 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20150205140042.GA40803@elstar.local> Mail-Followup-To: Phil Shafer , netmod@ietf.org References: <20150204165434.GA11693@elstar.local> <201502041932.t14JWRPu046279@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201502041932.t14JWRPu046279@idle.juniper.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] minutes of the NETMOD 2015-02-04 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2015 14:00:56 -0000 Hi, it would be helpful if people comment on different issues in separate emails that have the issue number in the subject line. Concerning anyxml, I have heard that implementations support different subsets of XML as content below anyxml. If your concern is the JSON handling of anyxml, then this belongs into a threat discussing the json mapping document. /js On Wed, Feb 04, 2015 at 02:32:27PM -0500, Phil Shafer wrote: > Juergen Schoenwaelder writes: > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > >* Y34 remove/deprecate/replace the 'anyxml' statement > > > > JS: Solution Y34-05 > > > > Same as Y34-02 plus two guidelines adopted from Y34-04: > > > > - For YANG 1.0 backward compatibility, allow anyxml to be used, > > except implementations MAY restrict the XML; document that > > anyxml is not considered interoperable. > > - The guidelines document should say that YANG Doctors will review > > each use of anyxml in IETF modules when YANG 1.1 is adopted to > > avoid its use whenever possible > > Do we have a list of what makes anyxml not interoperable? Can JSON > just encode this as a string? Is the concern just namespace issues? > Can the JSON encoder be responsible for including any required xmlns > attributes with the contents? > > >* Y57 non-unique leaf-list > > BL: I will revise the proposal and post an updated solution to the > > mailing list. > > Okay, I'm completely biased in that I think non-unique leaf-list is > a mostly evil idea, but..... > > A simpler fix might be added "position" as a value for "ordered-by". > > leaf-list bytes { > ordered-by position; > } > > would also allow: > > list note { > ordered-by position; > choice note { > leaf a { type empty; } > ... > leaf g { type empty; } > } > choice flat-or-sharp { > leaf flat { type empty; } > leaf sharp { type empty; } > } > } > > Allowing: > > > > > > > > (Yeah, long way to go for that, eh?) > > But long term, this is still a horrible idea, since positions aren't > constant and require a "fetch before change" that isn't otherwise > vital. It's setting clients up to trample on each other, which > affects stability and interoperability. > > >* Y58 associate actions with a data node > > > > JS to get final confirmation from NETCONF chairs, then try to close > > the VRFY phase on the mailing list. > > I'm still opposed to this, given that it's not needed. Nothing can > be done with this feature that can't be done without it. > > It's really the first step in attempting to turn YANG into an > object-oriented data modeling language, which it's not set up to > be. And shouldn't be. There's an ocean of OO facilities that we > don't have/need/want, including inheritance, polymorphism, interfaces, > etc. > > There's a strong desire to keep extending a technology to allow it > to address all sorts of it wasn't designed for. "Yeah we could do > that too if we just added this little bit". The results are fairly > predictable; the simple little system turns into a complex, fragile > system. > > Consider YAML, where 1.2 added more complex but useless features > that after five years, only one implementation (in Haskell) supports > it. Or XSLT, where the 2.0 spec exploded with lots of features > that aren't used because only saxon implements them. > > Addon features decrease interoperability, and impact the stability > and "done"-ness of our technologies. I'm fine with fixing bugs, > clarifying the spec, and removing opportunities for errors, but > adding new features is imho a non-starter. > > Sorry, that turned into a rant somewhere along the way, but, well.... > > Thanks, > Phil -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 5 08:08:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234AB1A8953 for ; Thu, 5 Feb 2015 08:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvMErxkuJj8r for ; Thu, 5 Feb 2015 08:07:56 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 DD8D11A87A9 for ; Thu, 5 Feb 2015 08:07:55 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id u14so2359387lbd.12 for ; Thu, 05 Feb 2015 08:07:54 -0800 (PST) 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:content-type; bh=YZrJq2E7edbuxgF6lZdhTd7AQk9gdstCAnXPmNCj+vc=; b=M2ihtoJWQIGqoMyzyHJzYvCoyV0ACW/BTAXKbUns2HtR3kChSpIjkd/7rUgAWRAVUD 3/9gtSGtAQJYbT0lHBNcghb9Vnet4zObc6K95keyp4iudsLZy+lvc1e6uPrJYVW3IvpU jyk43yigzSalwTlwgvDTXYE1AF3fzMInWbb7Y68PBZgD09TbIPTx5ZLuwvnYF/sK6+OK fLyjVpI/6hhAhFuZXNAEzyha1MG41qYDAxmwNgT2/sk3XOrFIje0wLWJOYNFNIuF5VTC FkrkhWL2iWHzFtaPG3gUiLE1TU/X33q6qPiOQVH35LtSUW/vbf7WoOQ7J2kjGmiXhKT1 kJgQ== X-Gm-Message-State: ALoCoQmtZD36BgVDweJe4UKO0QHqy7WgPqdqMN5odm0bLrM35TzfetQKlzoDL05TeAubRoeb1FkH MIME-Version: 1.0 X-Received: by 10.112.164.101 with SMTP id yp5mr4449104lbb.82.1423152474362; Thu, 05 Feb 2015 08:07:54 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 08:07:54 -0800 (PST) In-Reply-To: <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> Date: Thu, 5 Feb 2015 08:07:54 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:07:59 -0000 On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: > >> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>> Hi, >>> >>> $SUBJ is already several months late, so I think we should proceed >>> towards delivering it. I checked my mail archive since the -02 revision, >>> and it seems two issues need to be resolved: >>> >>> 1. Andy objected to making redundant namespace prefixes illegal. I >>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >>> instead of MUST NOT): >>> >>> OLD >>> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >>> be used for all top-level YANG data nodes, and also for all nodes >>> whose parent node belongs to a different namespace. Otherwise, names >>> with namespace identifiers MUST NOT be used. >>> >>> NEW >>> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >>> be used for all top-level YANG data nodes, and also for all nodes >>> whose parent node belongs to a different namespace. Otherwise, names >>> with namespace identifiers SHOULD NOT be used. >> >> I don't think this is a good idea. The reason is that it complicates >> both client and server code. An implementation cannot write code like >> this: >> >> name = interface['name'] >> mtu = interface['mtu'] >> >> instead we have to look for both 'name' and 'ietf-interfaces:name': >> >> if 'name' in interface: >> name = interface['name'] >> else >> name = interface['ietf-interfaces:name'] >> >> >> One single deterministic encoding is simpler everywhere and less >> error-prone. > > I agree with you, this again makes standard JSON parsers (that give you a pointer to the parsed structure) considerably less useful. > Customers are not following this rule and they never will. They avoid the problem by avoiding local-name conflicts in the first place. It is not user-friendly or CLI-friendly to allow sibling nodes to have the same local name. These are not open systems so controlling the module set is not a problem. > Lada > >> >>> 2. anyxml encoding: although it is a misnomer, I propose to keep the >>> current definition (sec. 5.5), i.e. allow any valid JSON value in >>> JSON-encoded anyxml instances. I also think the text makes it >>> sufficiently clear that no standard mapping between XML- and >>> JSON-encoded instances is defined. >> >> Ok. >> I am not so sure ignoring XML is OK. There should be a warning that the JSON encoding the sender picks is not "sticky". The receiver MAY change it to something else, such that if the original sender retrieves a new copy from the server, the JSON types might have changed. It is only safe to use the common features between XML and JSON. >> >> /martin > Andy > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Feb 5 08:27:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F7F1A884B for ; Thu, 5 Feb 2015 08:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRtRtF5gw089 for ; Thu, 5 Feb 2015 08:27:48 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 E73DA1A8761 for ; Thu, 5 Feb 2015 08:27:47 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so9031183lbv.3 for ; Thu, 05 Feb 2015 08:27:46 -0800 (PST) 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:content-type; bh=6tozfXpqaEO0BRMXBocEqI4gGh2EXPeVF7/jjFeD3LM=; b=Emfupv9jNcwzeamKFrnofyyT8UAennXUxljKuz0vMDp8BUPcPi88WltCJhmLcK0wKH Nj9cDh3YxCmQe3oF4ZKyyXQUfwnJ/BIQUO4dVc4CrWJMiz84WGLhaqcr8WjwPXb0yVrC PrW3g0pjGgmEbZYXcOBa0PhwOMYwJT1fVYCfBDsKMxAkLx56NNa6Ci0M3v0qfEdj0CHc KqL1NgHacYoUZMQ18sBWusa2ZnVOOsXyIpy80Ka4wQSE+00+6H4c6oRcdPAXnY9BWi+L wZmSRIh3lFHT9Uty2FsQEr6kmk4iKO04E6hiR5u/n0v7pYwFarn7zravuE2uY9HHsKwX 8W1w== X-Gm-Message-State: ALoCoQm8BD+Xzb2lsAJvR7DJxbvTgC6yuIQFp+nLNzfQaIwkf8Vz86rE1si7zfnhsd0XqfEKEjqe MIME-Version: 1.0 X-Received: by 10.152.37.138 with SMTP id y10mr4560654laj.88.1423153666380; Thu, 05 Feb 2015 08:27:46 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 08:27:46 -0800 (PST) In-Reply-To: <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> Date: Thu, 5 Feb 2015 08:27:46 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 16:27:49 -0000 On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: > >> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>> Hi, >>> >>> $SUBJ is already several months late, so I think we should proceed >>> towards delivering it. I checked my mail archive since the -02 revision, >>> and it seems two issues need to be resolved: >>> >>> 1. Andy objected to making redundant namespace prefixes illegal. I >>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >>> instead of MUST NOT): >>> >>> OLD >>> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >>> be used for all top-level YANG data nodes, and also for all nodes >>> whose parent node belongs to a different namespace. Otherwise, names >>> with namespace identifiers MUST NOT be used. >>> >>> NEW >>> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >>> be used for all top-level YANG data nodes, and also for all nodes >>> whose parent node belongs to a different namespace. Otherwise, names >>> with namespace identifiers SHOULD NOT be used. >> I think MUST violates the RFC 2119 rules (issue Randy already raised). If the receiver gets "interfaces" instead of "ietf-interfaces:interfaces", and there is only 1 possible match, then the receiver is forced to reject input that it understands. Even if there are multiple matches, the receiver may be able to detect which object is being sent. Of course, if there are multiple matches and the receiver cannot detect which one is sent, the input MUST be rejected. Andy >> I don't think this is a good idea. The reason is that it complicates >> both client and server code. An implementation cannot write code like >> this: >> >> name = interface['name'] >> mtu = interface['mtu'] >> >> instead we have to look for both 'name' and 'ietf-interfaces:name': >> >> if 'name' in interface: >> name = interface['name'] >> else >> name = interface['ietf-interfaces:name'] >> >> >> One single deterministic encoding is simpler everywhere and less >> error-prone. > > I agree with you, this again makes standard JSON parsers (that give you a pointer to the parsed structure) considerably less useful. > > Lada > >> >>> 2. anyxml encoding: although it is a misnomer, I propose to keep the >>> current definition (sec. 5.5), i.e. allow any valid JSON value in >>> JSON-encoded anyxml instances. I also think the text makes it >>> sufficiently clear that no standard mapping between XML- and >>> JSON-encoded instances is defined. >> >> Ok. >> >> >> /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Feb 5 12:46:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2601A8AF2 for ; Thu, 5 Feb 2015 12:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CesQaiL2jMiz for ; Thu, 5 Feb 2015 12:45:58 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DEB5C1A8791 for ; Thu, 5 Feb 2015 12:45:57 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id A676A1280052; Thu, 5 Feb 2015 21:45:56 +0100 (CET) Date: Thu, 05 Feb 2015 21:45:57 +0100 (CET) Message-Id: <20150205.214557.720578496688087827.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@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-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:46:03 -0000 Andy Bierman wrote: > On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: > > > >> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: > >> > >> Ladislav Lhotka wrote: > >>> Hi, > >>> > >>> $SUBJ is already several months late, so I think we should proceed > >>> towards delivering it. I checked my mail archive since the -02 > >>> revision, > >>> and it seems two issues need to be resolved: > >>> > >>> 1. Andy objected to making redundant namespace prefixes illegal. I > >>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT > >>> instead of MUST NOT): > >>> > >>> OLD > >>> > >>> Names with namespace identifiers in the form shown in Figure 1 MUST > >>> be used for all top-level YANG data nodes, and also for all nodes > >>> whose parent node belongs to a different namespace. Otherwise, names > >>> with namespace identifiers MUST NOT be used. > >>> > >>> NEW > >>> > >>> Names with namespace identifiers in the form shown in Figure 1 MUST > >>> be used for all top-level YANG data nodes, and also for all nodes > >>> whose parent node belongs to a different namespace. Otherwise, names > >>> with namespace identifiers SHOULD NOT be used. > >> > >> I don't think this is a good idea. The reason is that it complicates > >> both client and server code. An implementation cannot write code like > >> this: > >> > >> name = interface['name'] > >> mtu = interface['mtu'] > >> > >> instead we have to look for both 'name' and 'ietf-interfaces:name': > >> > >> if 'name' in interface: > >> name = interface['name'] > >> else > >> name = interface['ietf-interfaces:name'] > >> > >> > >> One single deterministic encoding is simpler everywhere and less > >> error-prone. > > > > I agree with you, this again makes standard JSON parsers (that give > > you a pointer to the parsed structure) considerably less useful. > > > > Customers are not following this rule and they never will. > They avoid the problem by avoiding local-name conflicts > in the first place. It is not user-friendly or CLI-friendly > to allow sibling nodes to have the same local name. > These are not open systems so controlling the module set > is not a problem. But this is *another* issue. Neither of the alternatives support this use case. > >>> 2. anyxml encoding: although it is a misnomer, I propose to keep the > >>> current definition (sec. 5.5), i.e. allow any valid JSON value in > >>> JSON-encoded anyxml instances. I also think the text makes it > >>> sufficiently clear that no standard mapping between XML- and > >>> JSON-encoded instances is defined. > >> > >> Ok. > >> > > I am not so sure ignoring XML is OK. So how would you encode an arbitrary XML snippet (which is what anyxml is) in JSON? I know you want to restrict anyxml, but that is simply not how it is defined in 6020. For now we have to live with that. > There should be a warning that the JSON encoding the > sender picks is not "sticky". The receiver MAY change it > to something else, such that if the original sender retrieves > a new copy from the server, the JSON types might have changed. > > It is only safe to use the common features between XML and JSON. Right, and you get this from anydata! /martin From nobody Thu Feb 5 12:52:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA98B1A8AFA for ; Thu, 5 Feb 2015 12:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIT_fuYpjRsV for ; Thu, 5 Feb 2015 12:51:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id EE1EF1A1B37 for ; Thu, 5 Feb 2015 12:51:49 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 40D1D1280052; Thu, 5 Feb 2015 21:51:49 +0100 (CET) Date: Thu, 05 Feb 2015 21:51:50 +0100 (CET) Message-Id: <20150205.215150.806661511908269492.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@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-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 20:51:54 -0000 Andy Bierman wrote: > On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: > > > >> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: > >> > >> Ladislav Lhotka wrote: > >>> Hi, > >>> > >>> $SUBJ is already several months late, so I think we should proceed > >>> towards delivering it. I checked my mail archive since the -02 revision, > >>> and it seems two issues need to be resolved: > >>> > >>> 1. Andy objected to making redundant namespace prefixes illegal. I > >>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT > >>> instead of MUST NOT): > >>> > >>> OLD > >>> > >>> Names with namespace identifiers in the form shown in Figure 1 MUST > >>> be used for all top-level YANG data nodes, and also for all nodes > >>> whose parent node belongs to a different namespace. Otherwise, names > >>> with namespace identifiers MUST NOT be used. > >>> > >>> NEW > >>> > >>> Names with namespace identifiers in the form shown in Figure 1 MUST > >>> be used for all top-level YANG data nodes, and also for all nodes > >>> whose parent node belongs to a different namespace. Otherwise, names > >>> with namespace identifiers SHOULD NOT be used. > >> > > I think MUST violates the RFC 2119 rules (issue Randy already raised). > If the receiver gets "interfaces" instead of "ietf-interfaces:interfaces", > and there is only 1 possible match, then the receiver is forced to > reject input that it understands. What if it gets "Interfaces"? Or "intrefaces"? It is obvious what was meant, so should we specify that these cases must be handled as well? Ths point is that if we allow multiple representations, *all* code must handle *all* representations. /martin From nobody Thu Feb 5 13:07:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2315B1A8F35 for ; Thu, 5 Feb 2015 13:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 kIjtJIOfkKCY for ; Thu, 5 Feb 2015 13:07:01 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::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 B892A1A1B7A for ; Thu, 5 Feb 2015 13:05:06 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id l6so8502336qcy.12 for ; Thu, 05 Feb 2015 13:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=uyB/RCE7LL+6t3xitP2DuAlZ5wsxNuoF/nwO1XouveU=; b=lXCYWYRdmRETiRe8ZG3R4dWepPIeKr5vYMO6S4ToYahuNyf9+pqMF6zJDNb23wOC1P jW0ap1UG4Q0E9ePFcrQQDbIYijOzpWhjw7eKnsbAeL4C7TNrR5fyawcb4F3MyW//en6x RyzI6RwDnL83JmfCVTGLr31W54e6YqOq6Fy/KVdaU3WP9xAOrxWNS0kl2UbNeaMidDmC en2DAJyXNy+ePk/NVWc4M+WkIal0vD5DPXV0aD1b7BtLHjZjc1r6T14lr6JUQfgD9dIV JERvf+TCwp56Tf+xGPTIXDZkIem0RxQ30D/BkO3F6wt6vYxMYguaG6CCGYoKE6zzKPIY fSWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=uyB/RCE7LL+6t3xitP2DuAlZ5wsxNuoF/nwO1XouveU=; b=K9q0L2PAzx1LfkNUyEsHE+ouOcWajYsbbG2W0VJVcyqjLsY54cMFoZ0H7xf3lvMaR/ 5wvHu1oj9k2J6yjU7NBgUCz8aZGGQNcpycas6dO0D4CsN40WtwE5B26fElE8VG1RLCzO liJrXVD0DUgd/R8OxVPtbdTwxk930WRatAIu0LTIMfnzvXoxONbCWGCRfq5g+NrZe2xN E37QsQcMZi1W4IF3PVrG7VKk876nt93DX+fq/jC7qsxVk9sRGm3TeEe3RNpPLb8b5C5L HITJCitbgl0Tk0Ung5+9ZzQ8i9121BJiNNo1hSf1mA75jOWK3aT4qKQ4mlvSr57Ar/KQ po/A== X-Gm-Message-State: ALoCoQkp9SVAnwDkRl84plqbp0gWAlCTflNc5M+Dia0F8LAQ7icNJgjfV4FYtKycTn3k7NhhcYXE X-Received: by 10.224.96.130 with SMTP id h2mr145998qan.85.1423170305880; Thu, 05 Feb 2015 13:05:05 -0800 (PST) MIME-Version: 1.0 From: Anees Shaikh Date: Thu, 05 Feb 2015 21:05:05 +0000 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11c34fa689a64b050e5da80e Archived-At: Subject: [netmod] Clarification re system mgmnt module (RFC 7317) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:07:04 -0000 --001a11c34fa689a64b050e5da80e Content-Type: text/plain; charset=UTF-8 The current system management YANG module depends on an associated iana-crypt-hash module (also defined in the RFC). My question is whether the iana-crypt-hash module should be considered part of the standard model (I has assumed it was). This confusion came about because in the YangModels github repo, ietf-system is in the ietf/RFC directory, while the iana-crypt-hash module is in ietf/DRAFT. This presumes that the github repo reflects the intended status of ietf modules, which may not be the case. thanks. -- Anees --001a11c34fa689a64b050e5da80e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The current system management YANG module depends on an as= sociated iana-crypt-hash module (also defined in the RFC).

My question is whether the iana-crypt-hash module should be considered p= art of the standard model (I has assumed it was).

= This confusion came about because in the YangModels github repo, ietf-syste= m is in the ietf/RFC directory, while the iana-crypt-hash module is in ietf= /DRAFT. =C2=A0 This presumes that the github repo reflects the intended sta= tus of ietf modules, which may not be the case.

th= anks.
-- Anees
--001a11c34fa689a64b050e5da80e-- From nobody Thu Feb 5 13:22:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EA31A8F43 for ; Thu, 5 Feb 2015 13:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rRfZeRyAKW6 for ; Thu, 5 Feb 2015 13:21:59 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (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 3CB5F1A8F39 for ; Thu, 5 Feb 2015 13:21:57 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id l4so11781725lbv.13 for ; Thu, 05 Feb 2015 13:21:55 -0800 (PST) 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:content-type; bh=15/F8AZmzNdC2HyjojWcVIBo2hZKZklMvwyOk07FldA=; b=DBP3O5ehIOh1hCxzYpJZVVpYR0NpdTJ3LPPakBWZcEArNDcvI5F1a9VBHIo4S5dtsu 8DGxJn3fcaX83c0VLpkls3PfCaTTsHIs/H1hnn3ZnXK04fml2mhwI5CDpXVPZvBw6y4V 9BXJqvf7ZMnc+XMqcd+BcwlehBJSQtT1T1GCzgtSVYepw1aR+qVTp+Ae5emDxBDB1znA 0zUYpBbNfnY/9M1zcv8TIy8rjpmsYJNE1QYJRDDGebMe0MdQvhicFcttVpdcVr0kV7sP e/A1KawOGIw2go2pzKc8fZH/HhypGA4UIqsC95BqIOX/vtI26rwoRZhYDp+/m2snptpd sW+A== X-Gm-Message-State: ALoCoQmwquSR8DD18wGCl5rgz0I6zaEJqbQuilqv7JN3IBGUs5/rFmqTeH9vZv3V1m1x+pSWnsQp MIME-Version: 1.0 X-Received: by 10.112.166.73 with SMTP id ze9mr142278lbb.38.1423171315596; Thu, 05 Feb 2015 13:21:55 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 13:21:55 -0800 (PST) In-Reply-To: <20150205.214557.720578496688087827.mbj@tail-f.com> References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> Date: Thu, 5 Feb 2015 13:21:55 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:22:03 -0000 On Thu, Feb 5, 2015 at 12:45 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: >> > >> >> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: >> >> >> >> Ladislav Lhotka wrote: >> >>> Hi, >> >>> >> >>> $SUBJ is already several months late, so I think we should proceed >> >>> towards delivering it. I checked my mail archive since the -02 >> >>> revision, >> >>> and it seems two issues need to be resolved: >> >>> >> >>> 1. Andy objected to making redundant namespace prefixes illegal. I >> >>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> >>> instead of MUST NOT): >> >>> >> >>> OLD >> >>> >> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >> >>> be used for all top-level YANG data nodes, and also for all nodes >> >>> whose parent node belongs to a different namespace. Otherwise, names >> >>> with namespace identifiers MUST NOT be used. >> >>> >> >>> NEW >> >>> >> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >> >>> be used for all top-level YANG data nodes, and also for all nodes >> >>> whose parent node belongs to a different namespace. Otherwise, names >> >>> with namespace identifiers SHOULD NOT be used. >> >> >> >> I don't think this is a good idea. The reason is that it complicates >> >> both client and server code. An implementation cannot write code like >> >> this: >> >> >> >> name = interface['name'] >> >> mtu = interface['mtu'] >> >> >> >> instead we have to look for both 'name' and 'ietf-interfaces:name': >> >> >> >> if 'name' in interface: >> >> name = interface['name'] >> >> else >> >> name = interface['ietf-interfaces:name'] >> >> >> >> >> >> One single deterministic encoding is simpler everywhere and less >> >> error-prone. >> > >> > I agree with you, this again makes standard JSON parsers (that give >> > you a pointer to the parsed structure) considerably less useful. >> > >> >> Customers are not following this rule and they never will. >> They avoid the problem by avoiding local-name conflicts >> in the first place. It is not user-friendly or CLI-friendly >> to allow sibling nodes to have the same local name. >> These are not open systems so controlling the module set >> is not a problem. > > But this is *another* issue. Neither of the alternatives support this > use case. > >> >>> 2. anyxml encoding: although it is a misnomer, I propose to keep the >> >>> current definition (sec. 5.5), i.e. allow any valid JSON value in >> >>> JSON-encoded anyxml instances. I also think the text makes it >> >>> sufficiently clear that no standard mapping between XML- and >> >>> JSON-encoded instances is defined. >> >> >> >> Ok. >> >> >> >> I am not so sure ignoring XML is OK. > > So how would you encode an arbitrary XML snippet (which is what anyxml > is) in JSON? I know you want to restrict anyxml, but that is simply > not how it is defined in 6020. For now we have to live with that. > No -- the description-stmts for the anyxml nodes in YANG Patch specify the limitations and an implementation of ietf-yang-patch MUST support what it says. If other individual YANG modules want to constrain anyxml in specific ways, they can do that. We can specify what an implementation of a particular module MUST accept. XML has simple nodes which are empty and those which are not empty. XML non-empty simple node <--> JSON string XML empty node <--> JSON null XML complex node <--> JSON object No requirement to send arrays, boolean, or numbers, but MAY send, and MUST accept. No requirement to preserve JSON type info. Must preserve xmlns and other attributes if QName or XPath content found. No XML PIs or mixed content allowed. IMO this will make XML <--> JSON translation work. >> There should be a warning that the JSON encoding the >> sender picks is not "sticky". The receiver MAY change it >> to something else, such that if the original sender retrieves >> a new copy from the server, the JSON types might have changed. >> >> It is only safe to use the common features between XML and JSON. > > Right, and you get this from anydata! > Not as Lada defined his YANG to JSON mapping. > > /martin Andy From nobody Thu Feb 5 13:27:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4561A1A87 for ; Thu, 5 Feb 2015 13:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO42r3kP02_U for ; Thu, 5 Feb 2015 13:27:22 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253001A1AA9 for ; Thu, 5 Feb 2015 13:27:22 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id u14so11811498lbd.2 for ; Thu, 05 Feb 2015 13:27:20 -0800 (PST) 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:content-type; bh=5pbbGpq8T8IfWvUD9iXCszxDM1pm/BGJTiRVC7PeAMo=; b=VFuuLbgkR94WPJI5nLsOtR42w8StIEGAc4kcVeR/BS7PHKTa9Vy80RlZiq6wuwBSaN C03RwKG+9AiEOOhpM6lWr+GtBj9wFHy3ucXSOtVAd100xRDoWVsavPAhbeDtzF3vCNKN bzRdR/+oEZdzyPsnHO5ZAYuaPsVkYw8S00tGv6R0q9jpiPy9IZkiOzVmaK6fU5ej6aF0 T3mUw8wxBAllrQEgEP/3kDNa0WCrwYvBhVI3SShvj8XWGt7gcI5g6sUD3W0C0TkiFxJp +vsEHA3+WQV4Tf0zJpRls3x6u5mtP2W83r4PdlLH4VjkofmUcvShjbV1MW61WaAfvAbi QQww== X-Gm-Message-State: ALoCoQlIz+Sx9Z8IoK1VBDY+KyE2vYUkJ1pRJWL8GZ/OEg0NU2VHyX6Z7IvcLY2GUuXy+l09xDjf MIME-Version: 1.0 X-Received: by 10.152.29.6 with SMTP id f6mr144639lah.82.1423171640700; Thu, 05 Feb 2015 13:27:20 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 13:27:20 -0800 (PST) In-Reply-To: <20150205.215150.806661511908269492.mbj@tail-f.com> References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.215150.806661511908269492.mbj@tail-f.com> Date: Thu, 5 Feb 2015 13:27:20 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:27:24 -0000 On Thu, Feb 5, 2015 at 12:51 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: >> > >> >> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: >> >> >> >> Ladislav Lhotka wrote: >> >>> Hi, >> >>> >> >>> $SUBJ is already several months late, so I think we should proceed >> >>> towards delivering it. I checked my mail archive since the -02 revision, >> >>> and it seems two issues need to be resolved: >> >>> >> >>> 1. Andy objected to making redundant namespace prefixes illegal. I >> >>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> >>> instead of MUST NOT): >> >>> >> >>> OLD >> >>> >> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >> >>> be used for all top-level YANG data nodes, and also for all nodes >> >>> whose parent node belongs to a different namespace. Otherwise, names >> >>> with namespace identifiers MUST NOT be used. >> >>> >> >>> NEW >> >>> >> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >> >>> be used for all top-level YANG data nodes, and also for all nodes >> >>> whose parent node belongs to a different namespace. Otherwise, names >> >>> with namespace identifiers SHOULD NOT be used. >> >> >> >> I think MUST violates the RFC 2119 rules (issue Randy already raised). >> If the receiver gets "interfaces" instead of "ietf-interfaces:interfaces", >> and there is only 1 possible match, then the receiver is forced to >> reject input that it understands. > > What if it gets "Interfaces"? Or "intrefaces"? It is obvious what > was meant, so should we specify that these cases must be handled as > well? > This is a straw-man. The identifier is case-sensitive, as defined in YANG and XML. An exact-match on the local-name is required. An unknown module-name MUST be rejected, not ignored. > Ths point is that if we allow multiple representations, *all* code > must handle *all* representations. > I think "sender SHOULD provide module-name" is better than MUST. (Coupled with receiver MUST reject ambiguous input.) > > /martin Andy From nobody Thu Feb 5 13:31:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D870B1A8035 for ; Thu, 5 Feb 2015 13:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeWxKVpoM65W for ; Thu, 5 Feb 2015 13:30:52 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 25C351A8546 for ; Thu, 5 Feb 2015 13:30:38 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id u14so5450207lbd.12 for ; Thu, 05 Feb 2015 13:30:36 -0800 (PST) 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:content-type; bh=eZB0//8AZPC7iwFJ27znVEOhk62cWXQbJmJRL4tOvnA=; b=ZmvNbSHWh++SCeunkCREMKNTqNm60jgLzbdq8XyEH6VAoefKbNVNxPg3pq6B6qUZCU Evf/hE4djNVjDznozo0VMWifJg1Lkxuf97PVrheirPEHlmGkK79icS6MTjuuO2/JJxqr tkheAaWPvQKiD7sButL1XtvpQAKQ8rNmO5X9ZhxsG7UB5mWfByLbaeTnzeJy+V8z9cDw rkf+KA/fUL/+C5a0A6h55g39SMDRFKQtI4ZFAVtYtS5RUgtMyqR1X7NMzwMEkYoIk3CM 5xY7BU8UDYjOZDubLSEwJnk+3G4HlJVaojEbcqiEhKzlkLtCmn/cc6kOgwGiF80stYSg aHjQ== X-Gm-Message-State: ALoCoQkRvMuRkguek+uuUUnQziHu3CEFNZE99d/M66/rg4JmtSRtMxyo3Ccp2inOBHW2qqtDuQiF MIME-Version: 1.0 X-Received: by 10.112.166.73 with SMTP id ze9mr167315lbb.38.1423171836673; Thu, 05 Feb 2015 13:30:36 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 13:30:36 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Feb 2015 13:30:36 -0800 Message-ID: From: Andy Bierman To: Anees Shaikh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Clarification re system mgmnt module (RFC 7317) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:30:58 -0000 X-List-Received-Date: Thu, 05 Feb 2015 21:30:58 -0000 On Thu, Feb 5, 2015 at 1:05 PM, Anees Shaikh wrote: > The current system management YANG module depends on an associated > iana-crypt-hash module (also defined in the RFC). > > My question is whether the iana-crypt-hash module should be considered part > of the standard model (I has assumed it was). > > This confusion came about because in the YangModels github repo, ietf-system > is in the ietf/RFC directory, while the iana-crypt-hash module is in > ietf/DRAFT. This presumes that the github repo reflects the intended > status of ietf modules, which may not be the case. > This is my fault for not keeping the github ietf folder up to date. I will try to fix that ASAP. The RFC version should be in github. > thanks. > -- Anees > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Feb 5 13:36:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04861A0372 for ; Thu, 5 Feb 2015 13:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vQHrExVvikp for ; Thu, 5 Feb 2015 13:36:02 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA74C1A8790 for ; Thu, 5 Feb 2015 13:35:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8EAF314B6; Thu, 5 Feb 2015 22:35:39 +0100 (CET) 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 0hDVPxe0YwzT; Thu, 5 Feb 2015 22:35:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Feb 2015 22:35:38 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7633C20036; Thu, 5 Feb 2015 22:35:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rqy_paMlbMNG; Thu, 5 Feb 2015 22:27:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 924F520035; Thu, 5 Feb 2015 22:35:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7BBA43195C36; Thu, 5 Feb 2015 22:35:37 +0100 (CET) Date: Thu, 5 Feb 2015 22:35:37 +0100 From: Juergen Schoenwaelder To: Anees Shaikh Message-ID: <20150205213537.GA51394@elstar.local> Mail-Followup-To: Anees Shaikh , 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.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Clarification re system mgmnt module (RFC 7317) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2015 21:36:07 -0000 On Thu, Feb 05, 2015 at 09:05:05PM +0000, Anees Shaikh wrote: > The current system management YANG module depends on an associated > iana-crypt-hash module (also defined in the RFC). > > My question is whether the iana-crypt-hash module should be considered part > of the standard model (I has assumed it was). > > This confusion came about because in the YangModels github repo, > ietf-system is in the ietf/RFC directory, while the iana-crypt-hash module > is in ietf/DRAFT. This presumes that the github repo reflects the > intended status of ietf modules, which may not be the case. > RFC section 8 says that the iana-crypt-hash module belongs to IANA. I tend to agree that the structure of the YangModels github repo is confusing. Less structure would have been more, e.g., for everything published: yang/ietf /iana /opendaylight /brocade /yumaworks /... Simply one directory for the first 'token' in the module name. Easy and fast for tools to search for acme-foo-bar. Unpublished modules that are in the making go into a second tree with a similar structure. Yes, if two organizations like to start their modules names with 'acme', then all these modules go into the same directory. So what. And if people are too lazy to choose proper module names, they get what they asked for. Easy. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 5 13:46:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BCD1A6F22 for ; Thu, 5 Feb 2015 13:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4a-gadykle7 for ; Thu, 5 Feb 2015 13:46:36 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341F01A8787 for ; Thu, 5 Feb 2015 13:46:34 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 06F7D1A15; Thu, 5 Feb 2015 22:46:33 +0100 (CET) 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 DrhFK5rhna1H; Thu, 5 Feb 2015 22:46:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Feb 2015 22:46:31 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD0B120036; Thu, 5 Feb 2015 22:46:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o1RfeLXq6FNQ; Thu, 5 Feb 2015 22:46:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63E4E20035; Thu, 5 Feb 2015 22:46:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6BC1A3195E81; Thu, 5 Feb 2015 22:46:30 +0100 (CET) Date: Thu, 5 Feb 2015 22:46:30 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150205214630.GA52009@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2015 21:46:38 -0000 On Thu, Feb 05, 2015 at 01:21:55PM -0800, Andy Bierman wrote: > On Thu, Feb 5, 2015 at 12:45 PM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: > >> > > >> >> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: > >> >> > >> >> Ladislav Lhotka wrote: > >> >>> Hi, > >> >>> > >> >>> $SUBJ is already several months late, so I think we should proceed > >> >>> towards delivering it. I checked my mail archive since the -02 > >> >>> revision, > >> >>> and it seems two issues need to be resolved: > >> >>> > >> >>> 1. Andy objected to making redundant namespace prefixes illegal. I > >> >>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT > >> >>> instead of MUST NOT): > >> >>> > >> >>> OLD > >> >>> > >> >>> Names with namespace identifiers in the form shown in Figure 1 MUST > >> >>> be used for all top-level YANG data nodes, and also for all nodes > >> >>> whose parent node belongs to a different namespace. Otherwise, names > >> >>> with namespace identifiers MUST NOT be used. > >> >>> > >> >>> NEW > >> >>> > >> >>> Names with namespace identifiers in the form shown in Figure 1 MUST > >> >>> be used for all top-level YANG data nodes, and also for all nodes > >> >>> whose parent node belongs to a different namespace. Otherwise, names > >> >>> with namespace identifiers SHOULD NOT be used. > >> >> > >> >> I don't think this is a good idea. The reason is that it complicates > >> >> both client and server code. An implementation cannot write code like > >> >> this: > >> >> > >> >> name = interface['name'] > >> >> mtu = interface['mtu'] > >> >> > >> >> instead we have to look for both 'name' and 'ietf-interfaces:name': > >> >> > >> >> if 'name' in interface: > >> >> name = interface['name'] > >> >> else > >> >> name = interface['ietf-interfaces:name'] > >> >> > >> >> > >> >> One single deterministic encoding is simpler everywhere and less > >> >> error-prone. > >> > > >> > I agree with you, this again makes standard JSON parsers (that give > >> > you a pointer to the parsed structure) considerably less useful. > >> > > >> > >> Customers are not following this rule and they never will. > >> They avoid the problem by avoiding local-name conflicts > >> in the first place. It is not user-friendly or CLI-friendly > >> to allow sibling nodes to have the same local name. > >> These are not open systems so controlling the module set > >> is not a problem. > > > > But this is *another* issue. Neither of the alternatives support this > > use case. > > > >> >>> 2. anyxml encoding: although it is a misnomer, I propose to keep the > >> >>> current definition (sec. 5.5), i.e. allow any valid JSON value in > >> >>> JSON-encoded anyxml instances. I also think the text makes it > >> >>> sufficiently clear that no standard mapping between XML- and > >> >>> JSON-encoded instances is defined. > >> >> > >> >> Ok. > >> >> > >> > >> I am not so sure ignoring XML is OK. > > > > So how would you encode an arbitrary XML snippet (which is what anyxml > > is) in JSON? I know you want to restrict anyxml, but that is simply > > not how it is defined in 6020. For now we have to live with that. > > > > No -- the description-stmts for the anyxml nodes in YANG Patch > specify the limitations and an implementation of ietf-yang-patch > MUST support what it says. If other individual YANG modules > want to constrain anyxml in specific ways, they can do that. > We can specify what an implementation of a particular module MUST > accept. > > XML has simple nodes which are empty and those which are not empty. > > XML non-empty simple node <--> JSON string > XML empty node <--> JSON null > XML complex node <--> JSON object > > No requirement to send arrays, boolean, or numbers, but MAY send, > and MUST accept. No requirement to preserve JSON type info. > Must preserve xmlns and other attributes if QName or XPath content found. > No XML PIs or mixed content allowed. > IMO this will make XML <--> JSON translation work. > Perhaps things work in YANG patch because it is constrained enough but that does not mean things work for every possible valid usage of anyxml according to RFC 6020. RFC 6020 says that anyxml is any xml. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 5 13:57:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEA31A1B22 for ; Thu, 5 Feb 2015 13:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsS1zgy2AivU for ; Thu, 5 Feb 2015 13:57:18 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 0CBC31A1ABB for ; Thu, 5 Feb 2015 13:57:18 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so12141156lbv.3 for ; Thu, 05 Feb 2015 13:57:16 -0800 (PST) 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:content-type; bh=noexPyiZZ7aiZJL7yrADYhFdeiJzAe9j6NFiNuYPca8=; b=RTCrTt5ttvk4rbU5RkSib+jW9OBm0ztapuKAHUGtVpHYZretZAP8sDBKGAXfAUS7Ny WpmXVImk0hz+frtrt/PufJjzaqqSTP17+PxX//y5fsBP0eU8KHbdbbGpUrpDkpZ3SYE9 ltbMpeKq+g5wh0OnQ/ZvMe30AtXZ0OSSs8GlaAOmLl/cXD/J9y0UyFvjKzQ6Uwlrv7Wb 1ThV35gJpTZDX/L6qjAsuVdchBh3bn2WvHSzuEeEfBexok3bd200vk44zksr47z5iyLC wGiSa4MyXkj9uYqifTQe9wbOQp1+wWWcPwb4jqfqvTJw9U+Tewq3fondIjvMGhCBe9oo GyxA== X-Gm-Message-State: ALoCoQnn1vuTrlfOtgljf8UEKWb4oS6poX9uxTWXBrwGItxNhGplzHrfsoequxojsZAnOM46nHTB MIME-Version: 1.0 X-Received: by 10.112.171.168 with SMTP id av8mr231514lbc.88.1423173436491; Thu, 05 Feb 2015 13:57:16 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 13:57:16 -0800 (PST) In-Reply-To: <20150205214630.GA52009@elstar.local> References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> <20150205214630.GA52009@elstar.local> Date: Thu, 5 Feb 2015 13:57:16 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 21:57:22 -0000 On Thu, Feb 5, 2015 at 1:46 PM, Juergen Schoenwaelder wrote: > On Thu, Feb 05, 2015 at 01:21:55PM -0800, Andy Bierman wrote: >> On Thu, Feb 5, 2015 at 12:45 PM, Martin Bjorklund wrote: >> > Andy Bierman wrote: >> >> On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: >> >> > >> >> >> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: >> >> >> >> >> >> Ladislav Lhotka wrote: >> >> >>> Hi, >> >> >>> >> >> >>> $SUBJ is already several months late, so I think we should proceed >> >> >>> towards delivering it. I checked my mail archive since the -02 >> >> >>> revision, >> >> >>> and it seems two issues need to be resolved: >> >> >>> >> >> >>> 1. Andy objected to making redundant namespace prefixes illegal. I >> >> >>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> >> >>> instead of MUST NOT): >> >> >>> >> >> >>> OLD >> >> >>> >> >> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >>> be used for all top-level YANG data nodes, and also for all nodes >> >> >>> whose parent node belongs to a different namespace. Otherwise, names >> >> >>> with namespace identifiers MUST NOT be used. >> >> >>> >> >> >>> NEW >> >> >>> >> >> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >>> be used for all top-level YANG data nodes, and also for all nodes >> >> >>> whose parent node belongs to a different namespace. Otherwise, names >> >> >>> with namespace identifiers SHOULD NOT be used. >> >> >> >> >> >> I don't think this is a good idea. The reason is that it complicates >> >> >> both client and server code. An implementation cannot write code like >> >> >> this: >> >> >> >> >> >> name = interface['name'] >> >> >> mtu = interface['mtu'] >> >> >> >> >> >> instead we have to look for both 'name' and 'ietf-interfaces:name': >> >> >> >> >> >> if 'name' in interface: >> >> >> name = interface['name'] >> >> >> else >> >> >> name = interface['ietf-interfaces:name'] >> >> >> >> >> >> >> >> >> One single deterministic encoding is simpler everywhere and less >> >> >> error-prone. >> >> > >> >> > I agree with you, this again makes standard JSON parsers (that give >> >> > you a pointer to the parsed structure) considerably less useful. >> >> > >> >> >> >> Customers are not following this rule and they never will. >> >> They avoid the problem by avoiding local-name conflicts >> >> in the first place. It is not user-friendly or CLI-friendly >> >> to allow sibling nodes to have the same local name. >> >> These are not open systems so controlling the module set >> >> is not a problem. >> > >> > But this is *another* issue. Neither of the alternatives support this >> > use case. >> > >> >> >>> 2. anyxml encoding: although it is a misnomer, I propose to keep the >> >> >>> current definition (sec. 5.5), i.e. allow any valid JSON value in >> >> >>> JSON-encoded anyxml instances. I also think the text makes it >> >> >>> sufficiently clear that no standard mapping between XML- and >> >> >>> JSON-encoded instances is defined. >> >> >> >> >> >> Ok. >> >> >> >> >> >> >> I am not so sure ignoring XML is OK. >> > >> > So how would you encode an arbitrary XML snippet (which is what anyxml >> > is) in JSON? I know you want to restrict anyxml, but that is simply >> > not how it is defined in 6020. For now we have to live with that. >> > >> >> No -- the description-stmts for the anyxml nodes in YANG Patch >> specify the limitations and an implementation of ietf-yang-patch >> MUST support what it says. If other individual YANG modules >> want to constrain anyxml in specific ways, they can do that. >> We can specify what an implementation of a particular module MUST >> accept. >> >> XML has simple nodes which are empty and those which are not empty. >> >> XML non-empty simple node <--> JSON string >> XML empty node <--> JSON null >> XML complex node <--> JSON object >> >> No requirement to send arrays, boolean, or numbers, but MAY send, >> and MUST accept. No requirement to preserve JSON type info. >> Must preserve xmlns and other attributes if QName or XPath content found. >> No XML PIs or mixed content allowed. >> IMO this will make XML <--> JSON translation work. >> > > Perhaps things work in YANG patch because it is constrained enough but > that does not mean things work for every possible valid usage of anyxml > according to RFC 6020. RFC 6020 says that anyxml is any xml. > That YANG text was written without any use-cases in mind. If a YANG module is written that has a use-case for unconstrained XML, then anyxml is ready to use. I have never seen anyxml actually used that way. In every case, there is a schema to apply, known to the implementation somehow. In every case there are only YANG nodes expected. No PIs. No mixed context. So I do not believe this is a real problem. I think YANG 1.1 could spend a lot of effort defining schema rules for unconstrained data, but this might not help address the real uses of anyxml. > /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 Thu Feb 5 14:09:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A746F1A8757 for ; Thu, 5 Feb 2015 14:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK8V9jPK5kv5 for ; Thu, 5 Feb 2015 14:09:07 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA191A1A33 for ; Thu, 5 Feb 2015 14:09:07 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C575B1C45; Thu, 5 Feb 2015 23:09:05 +0100 (CET) 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 Up_lb6JciEIq; Thu, 5 Feb 2015 23:08:43 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Feb 2015 23:09:05 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26C9E20035; Thu, 5 Feb 2015 23:09:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VHbidCS4cih8; Thu, 5 Feb 2015 23:01:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2A3820036; Thu, 5 Feb 2015 23:09:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 03B80319631F; Thu, 5 Feb 2015 23:09:03 +0100 (CET) Date: Thu, 5 Feb 2015 23:09:03 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150205220903.GA52795@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> <20150205214630.GA52009@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2015 22:09:10 -0000 On Thu, Feb 05, 2015 at 01:57:16PM -0800, Andy Bierman wrote: > > That YANG text was written without any use-cases in mind. > If a YANG module is written that has a use-case for unconstrained XML, > then anyxml is ready to use. > > I have never seen anyxml actually used that way. > In every case, there is a schema to apply, known to > the implementation somehow. In every case there are > only YANG nodes expected. No PIs. No mixed context. > > So I do not believe this is a real problem. > I think YANG 1.1 could spend a lot of effort defining > schema rules for unconstrained data, but this might not > help address the real uses of anyxml. > The argument "my code has a more specific interpretation and I believe everybody else does the same" only works if everybody confirms it. I have not seen that confirmation. Hence, to fix this, we have Y34-05 for YANG 1.1. This thread is about the current JSON mapping document, which is based on YANG 1.0. Again, the argument "my code has a more specific interpretation and I believe everybody else does the same" only works if everybody confirms it. As long as we do not have a confirmation that everybody happens to do what your code does, I think we have to assume that anyxml means what RFC 6020 says, any xml. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 5 14:41:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7179B1A6F0E for ; Thu, 5 Feb 2015 14:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMFT-NYQA-ks for ; Thu, 5 Feb 2015 14:41:10 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 544241A87B3 for ; Thu, 5 Feb 2015 14:41:06 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id w7so12534350lbi.1 for ; Thu, 05 Feb 2015 14:41:04 -0800 (PST) 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:content-type; bh=7dzO9X60O8QYrwl0mtolNCfI63M0mK1FUZ1+GbswxQ8=; b=J26fHSG76yPgkTnNVW9weK3+RhMlf8IGx2YNCw+QLFVL1k40N1yOEN5mERHhMbtOWU bfdNLkV2UR6AuxFKloIY4lft4C8hBVk5Q4iqxao2ww/edNXwq8vY+c8NiTX3IclLns47 G6mtv6JgQzEwwwJ0LIcsvOVWpZFP+n4kfcOax9j+qZFa9tQhXwv4TEN1FNMHFalWLSIR SJL+dx9WwR15It3m+oHPv+jXRhaE/Koj5hQKSxcJ91ylffiph8TZ5FydtHGypBwmeyvH dAIYbI3rVCS7yZ8fxVxiJ4/HkD0ZCwDmgqoU1CuxKulOvNu25AnlMUCaR0GZdD0itvCI DOog== X-Gm-Message-State: ALoCoQlJpu008k1OQeUr22X8k7/2V8+RulXTYz2MEmx5EMBJXGFNvGwCASJ9A4kx67uK9vm71T13 MIME-Version: 1.0 X-Received: by 10.152.28.129 with SMTP id b1mr317892lah.37.1423176064831; Thu, 05 Feb 2015 14:41:04 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 14:41:04 -0800 (PST) In-Reply-To: <20150205220903.GA52795@elstar.local> References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> <20150205214630.GA52009@elstar.local> <20150205220903.GA52795@elstar.local> Date: Thu, 5 Feb 2015 14:41:04 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 22:41:12 -0000 On Thu, Feb 5, 2015 at 2:09 PM, Juergen Schoenwaelder wrote: > On Thu, Feb 05, 2015 at 01:57:16PM -0800, Andy Bierman wrote: >> >> That YANG text was written without any use-cases in mind. >> If a YANG module is written that has a use-case for unconstrained XML, >> then anyxml is ready to use. >> >> I have never seen anyxml actually used that way. >> In every case, there is a schema to apply, known to >> the implementation somehow. In every case there are >> only YANG nodes expected. No PIs. No mixed context. >> >> So I do not believe this is a real problem. >> I think YANG 1.1 could spend a lot of effort defining >> schema rules for unconstrained data, but this might not >> help address the real uses of anyxml. >> > > The argument "my code has a more specific interpretation and I believe > everybody else does the same" only works if everybody confirms it. I > have not seen that confirmation. Hence, to fix this, we have Y34-05 > for YANG 1.1. > > This thread is about the current JSON mapping document, which is based > on YANG 1.0. Again, the argument "my code has a more specific > interpretation and I believe everybody else does the same" only works > if everybody confirms it. As long as we do not have a confirmation > that everybody happens to do what your code does, I think we have to > assume that anyxml means what RFC 6020 says, any xml. > Maybe you misunderstood. anyxml is being used as a placeholder for a "real schema" that YANG is unable to express. "my code knows how to pick the real schema for this anyxml blob" is part of the data model or protocol definition. I don't think Y34-05 addresses this issue. Even the "blog" use-case expects valid HTML to be specified in the anyxml, not free-form, any XML. > /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 Thu Feb 5 20:35:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85FA1A036D for ; Thu, 5 Feb 2015 20:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s5mcUvyWyLn for ; Thu, 5 Feb 2015 20:35:46 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 993441A037B for ; Thu, 5 Feb 2015 20:35:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d8n6PZs85n2bO0vSXMe2WHArYWezvsMakmmiaIL/2XKzGPA6iaXH52V8KC39YD8n; 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.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YJadr-0005Oa-Rc for netmod@ietf.org; Thu, 05 Feb 2015 23:35:43 -0500 Received: from 76.254.48.152 by webmail.earthlink.net with HTTP; Thu, 5 Feb 2015 23:35:43 -0500 Message-ID: <20874505.1423197343643.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Thu, 5 Feb 2015 20:35:43 -0800 (GMT-08: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f891153703696f18ef2022c22cdd8182bc74bd4e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Archived-At: Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 06 Feb 2015 04:35:52 -0000 Hi - >From: Andy Bierman >Sent: Feb 5, 2015 8:27 AM >To: Ladislav Lhotka >Cc: "netmod@ietf.org" >Subject: Re: [netmod] yang-json document ... >>>> NEW >>>> >>>> Names with namespace identifiers in the form shown in Figure 1 MUST >>>> be used for all top-level YANG data nodes, and also for all nodes >>>> whose parent node belongs to a different namespace. Otherwise, names >>>> with namespace identifiers SHOULD NOT be used. >>> > >I think MUST violates the RFC 2119 rules (issue Randy already raised). >If the receiver gets "interfaces" instead of "ietf-interfaces:interfaces", >and there is only 1 possible match, then the receiver is forced to >reject input that it understands. Even if there are multiple matches, >the receiver may be able to detect which object is being sent. > >Of course, if there are multiple matches and the receiver cannot >detect which one is sent, the input MUST be rejected. Before anyone reads too much into what I wrote let me be clear(er) about my concern: If the constraint is not necessary to ensure interoperability, using "MUST" is inappropriate. As I understand Andy's argument, receivers "may be able" to disambiguate. I'm not convinced that that's sufficient to ensure interoperability. Unless the behaviour is adequately specified so that all conformant implementaions will resolve in the same way the potential "multiple matches" Andy describes, it sounds like the "MUST" really *is* appropriate. Randy From nobody Thu Feb 5 20:48:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46821A037B for ; Thu, 5 Feb 2015 20:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuTbDjTl84qA for ; Thu, 5 Feb 2015 20:48:43 -0800 (PST) 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 53A5A1A01F2 for ; Thu, 5 Feb 2015 20:48:43 -0800 (PST) Received: from CO2PR05CA020.namprd05.prod.outlook.com (10.141.241.148) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 04:48:41 +0000 Received: from BY2FFO11FD034.protection.gbl (2a01:111:f400:7c0c::177) by CO2PR05CA020.outlook.office365.com (2a01:111:e400:1429::20) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Fri, 6 Feb 2015 04:48:40 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD034.mail.protection.outlook.com (10.1.14.219) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 04:48:40 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Feb 2015 20:48:39 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t164mcW62403; Thu, 5 Feb 2015 20:48:38 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t164mNSX059800; Thu, 5 Feb 2015 23:48:23 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502060448.t164mNSX059800@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Thu, 5 Feb 2015 23:48:23 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(54356999)(50986999)(77156002)(110136001)(86362001)(2950100001)(48376002)(62966003)(77096005)(50466002)(6806004)(19580395003)(47776003)(46102003)(105596002)(87936001)(53416004)(92566002)(18206015028)(106466001)(76506005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB434; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB434; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 04:48:40.4760 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB434 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 04:48:45 -0000 Andy Bierman writes: >> So how would you encode an arbitrary XML snippet (which is what anyxml >> is) in JSON? I know you want to restrict anyxml, but that is simply >> not how it is defined in 6020. For now we have to live with that. > >No -- the description-stmts for the anyxml nodes in YANG Patch >specify the limitations and an implementation of ietf-yang-patch >MUST support what it says. If other individual YANG modules >want to constrain anyxml in specific ways, they can do that. >We can specify what an implementation of a particular module MUST >accept. Doesn't this mean that yang-patch is not compatible with yang, since one can define models in yang that yang-patch will not handle? >XML has simple nodes which are empty and those which are not empty. > XML non-empty simple node <--> JSON string > XML empty node <--> JSON null > XML complex node <--> JSON object This is an extreme oversimplification. Consider the real-world case: anyxml web-banner { description "Chunk of XHTML that is placed at the top of every page for the embedded web server"; }

This is very sensitive data

I'm serious, dude

 What does the JSON for this look like? I think the only viable answer is: "web-banner": "

This is very sensitive data

\n\n

I'm serious, dude

\n" Thanks, Phil From nobody Thu Feb 5 20:54:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC801A0393 for ; Thu, 5 Feb 2015 20:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Dxb_tu33Ant for ; Thu, 5 Feb 2015 20:54:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781241A037B for ; Thu, 5 Feb 2015 20:54:14 -0800 (PST) Received: from BLUPR05CA0044.namprd05.prod.outlook.com (10.141.20.14) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 04:53:51 +0000 Received: from BY2FFO11FD054.protection.gbl (2a01:111:f400:7c0c::166) by BLUPR05CA0044.outlook.office365.com (2a01:111:e400:855::14) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Fri, 6 Feb 2015 04:53:51 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD054.mail.protection.outlook.com (10.1.15.191) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 04:53:50 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 5 Feb 2015 20:53:49 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t164rmW64294; Thu, 5 Feb 2015 20:53:48 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t164rUjZ059834; Thu, 5 Feb 2015 23:53:30 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502060453.t164rUjZ059834@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Thu, 5 Feb 2015 23:53:30 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; tail-f.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(76506005)(86362001)(50986999)(6806004)(77096005)(2950100001)(50466002)(48376002)(47776003)(87936001)(92566002)(54356999)(105596002)(110136001)(106466001)(77156002)(62966003)(46102003)(53416004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB440; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 04:53:50.6985 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 04:54:17 -0000 Andy Bierman writes: >anyxml is being used as a placeholder for a "real schema" >that YANG is unable to express. "my code knows how >to pick the real schema for this anyxml blob" is part of >the data model or protocol definition. Consider the proxy case, where the main server does not know the schema of the proxied device. If you make the assumption that anyxml is only used in certain select scenarios, you greatly diminish its value. Thanks, Phil From nobody Thu Feb 5 21:12:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800741A039F for ; Thu, 5 Feb 2015 21:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3z3PIxbtKaU for ; Thu, 5 Feb 2015 21:12:46 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 A0DCE1A01F2 for ; Thu, 5 Feb 2015 21:12:45 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id u10so1644459lbd.7 for ; Thu, 05 Feb 2015 21:12:44 -0800 (PST) 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:content-type; bh=BIPSlb4qfUrFuWki8p6SFpX6//d0M6UBmqtiL88qz4c=; b=GRusrePBmb7N9FyWtxJMKjkFz8rpX2dwU/HAeXNRXM47Xxfu6TuOltcW/8OMPHmJKx x+ItoJiBjCQLBdKAe9elNMrVsv4up7KcfEg9fU5B3qVIGf2mfMwZOURu3fbCEPVnzWY9 jeZTQRyjV4ICTwiw1aDD0dBRjPAHsQQIZVlddVQ0NJgRNYy7F1DNvhhenhKsy7+BwWu4 piQ5zpP7umORXcrqUWOG/kewwE/IeVIc3ttHVSKaXAoYwRvcay7z9z9WbyPRrhbOVD5O 9h+ZvaBrEHTzTBIDdhySS4wryJlTz+76rKeBL9S5jykwuJDF0LG6fQmghSiOqI1DVz/c EBQQ== X-Gm-Message-State: ALoCoQm05seLupunnM+sHylf2leNjlmK6WJr/X/aayhT9a+phe2w4dKVHNlUN7075+/j92eAebTU MIME-Version: 1.0 X-Received: by 10.112.171.168 with SMTP id av8mr1121334lbc.88.1423199563858; Thu, 05 Feb 2015 21:12:43 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 21:12:43 -0800 (PST) In-Reply-To: <201502060448.t164mNSX059800@idle.juniper.net> References: <201502060448.t164mNSX059800@idle.juniper.net> Date: Thu, 5 Feb 2015 21:12:43 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 05:12:48 -0000 On Thu, Feb 5, 2015 at 8:48 PM, Phil Shafer wrote: > Andy Bierman writes: >>> So how would you encode an arbitrary XML snippet (which is what anyxml >>> is) in JSON? I know you want to restrict anyxml, but that is simply >>> not how it is defined in 6020. For now we have to live with that. >> >>No -- the description-stmts for the anyxml nodes in YANG Patch >>specify the limitations and an implementation of ietf-yang-patch >>MUST support what it says. If other individual YANG modules >>want to constrain anyxml in specific ways, they can do that. >>We can specify what an implementation of a particular module MUST >>accept. > > Doesn't this mean that yang-patch is not compatible with > yang, since one can define models in yang that yang-patch > will not handle? > >>XML has simple nodes which are empty and those which are not empty. >> XML non-empty simple node <--> JSON string >> XML empty node <--> JSON null >> XML complex node <--> JSON object > > This is an extreme oversimplification. Consider the real-world > case: > > anyxml web-banner { > description "Chunk of XHTML that is placed at the > top of every page for the embedded web server"; > } > > >

This is very sensitive data

> >

I'm serious, dude

> > by real-world you mean your server actually supports this config? > What does the JSON for this look like? I think the only viable > answer is: > > "web-banner": "

This is very sensitive data

\n\n

I'm serious, dude

\n" > It's OK with me if the optional JSON encoding is dropped. If corner-cases like this are deemed to be so important, then just use XML and forget about JSON. > Thanks, > Phil Andy From nobody Thu Feb 5 21:35:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD191A01F2 for ; Thu, 5 Feb 2015 21:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSNIOa0nQD1L for ; Thu, 5 Feb 2015 21:35:27 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 8FCFF1A01AE for ; Thu, 5 Feb 2015 21:35:26 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id u14so8683091lbd.12 for ; Thu, 05 Feb 2015 21:35:25 -0800 (PST) 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:content-type; bh=Q8cvnNcYFLbnW6KK7i9HffH+h8dHJd1TT4by51FW7zM=; b=c5vI8WVaB7GrUEXOX2MW/tpADAvFpGxv55yzzuYNYqDBdJ5T7fpofjZuzUqCtnKHzi P0r5upOLN6uLqwYRAJhpd5MQl0eLZ7jd2iQD0c28KtoGfnYBs2V69h70qaywzQuChjgd fR30Eu30Rdn65WdIrZOQwFTvODkRTFNB8Z/OFIGb2cCisAH7M4ng+VVfYrRbfKsNDGCi hMNBR8SqJvWPJQLcVVSZu0wV+dPy2PODC8FDTfVhCQRTEAgqfe+l1M5m5jM7Im+4uBvb C+yCU/bFqtEeey3dc8+74lSAMa9DIDH8jaPC8hnd8hFCq3bFQhXxkALMrPFsZdb3/12M NueA== X-Gm-Message-State: ALoCoQlCTbSxOEtiHESATRzU2k+ULQc4SEJ2FyXZEN3HYD6oPkT0sXu9ZnSq2/867DGRpCceaQNx MIME-Version: 1.0 X-Received: by 10.152.28.129 with SMTP id b1mr1123290lah.37.1423200925035; Thu, 05 Feb 2015 21:35:25 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 5 Feb 2015 21:35:24 -0800 (PST) In-Reply-To: <201502060448.t164mNSX059800@idle.juniper.net> References: <201502060448.t164mNSX059800@idle.juniper.net> Date: Thu, 5 Feb 2015 21:35:24 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 05:35:28 -0000 On Thu, Feb 5, 2015 at 8:48 PM, Phil Shafer wrote: > Andy Bierman writes: >>> So how would you encode an arbitrary XML snippet (which is what anyxml >>> is) in JSON? I know you want to restrict anyxml, but that is simply >>> not how it is defined in 6020. For now we have to live with that. >> >>No -- the description-stmts for the anyxml nodes in YANG Patch >>specify the limitations and an implementation of ietf-yang-patch >>MUST support what it says. If other individual YANG modules >>want to constrain anyxml in specific ways, they can do that. >>We can specify what an implementation of a particular module MUST >>accept. > > Doesn't this mean that yang-patch is not compatible with > yang, since one can define models in yang that yang-patch > will not handle? > >>XML has simple nodes which are empty and those which are not empty. >> XML non-empty simple node <--> JSON string >> XML empty node <--> JSON null >> XML complex node <--> JSON object > > This is an extreme oversimplification. Consider the real-world > case: > > anyxml web-banner { > description "Chunk of XHTML that is placed at the > top of every page for the embedded web server"; > } > > >

This is very sensitive data

> >

I'm serious, dude

> > > What does the JSON for this look like? I think the only viable > answer is: > > "web-banner": "

This is very sensitive data

\n\n

I'm serious, dude

\n" > I don't see how this will possibly work. How does the server know the JSON string is special and should be rendered as raw XML? A normal server is going to escape all the angle brackets if rendered in XML. > Thanks, > Phil Andy From nobody Fri Feb 6 00:28:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2201A1A2F for ; Fri, 6 Feb 2015 00:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.06 X-Spam-Level: X-Spam-Status: No, score=-99.06 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1yLTU5YcMUK for ; Fri, 6 Feb 2015 00:27:49 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4F61C1A017C for ; Fri, 6 Feb 2015 00:27:49 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id EB2F452CC2EB for ; Fri, 6 Feb 2015 16:27:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t168RKtm010848 for ; Fri, 6 Feb 2015 16:27:20 +0800 (GMT-8) (envelope-from du.baowei23@zte.com.cn) MIME-Version: 1.0 To: netmod@ietf.org X-KeepSent: 871E36DA:BA7ECB20-48257DE1:0033139F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: du.baowei23@zte.com.cn Date: Fri, 6 Feb 2015 16:27:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-02-06 16:27:19, Serialize complete at 2015-02-06 16:27:19 Content-Type: multipart/alternative; boundary="=_alternative 002E731848257DE4_=" X-MAIL: mse01.zte.com.cn t168RKtm010848 Archived-At: Subject: [netmod] question about feature statements in message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 08:27:54 -0000 This is a multipart message in MIME format. --=_alternative 002E731848257DE4_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIGV2ZXJ5b25lDQoNCkknbSBuZXcgdG8gbmV0bW9kL1lBTkcsIGFuZCBJIGhhdmUgYSBxdWVz dGlvbiBhYm91dCBmZWF0dXJlIGluIDxoZWxsbz4gDQptZXNzYWdlDQoNCg0KRXhhbXBsZSA6DQoN CiBNMSAgICAgICAgICAgICAgIE0yDQogfCAgICAgICAgICAgICAgICB8DQogfC0tLXByZWZpeCBt MSAgICB8LS0tIGltcG9ydCBNMQ0KIHwgICAgICAgICAgICAgICAgfCAgICAgIHwNCiAgICAgICAg ICAgICAgICAgIHwgICAgICB8LS0tIHByZWZpeCBtMQ0KIHwgICAgICAgICAgICAgICAgfA0KIHwt LS1mZWF0dXJlIGEgICAgfC0tLSBmZWF0dXJlIGINCiAgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICAgICAgICAgICAgICAgICAgICAgICAgfC0tLSBpZi1mZWF0dXJlIG0xOmENCg0KDQpNMSBh bmQgTTIgYm90aCBhcmUgeWFuZyBtb2R1bGVzIGFuZCBtMiAnaW1wb3J0JyBtMQ0KDQppZiBBZ2Vu dCBkb2Vzbid0IHN1cHBvcnQgZmVhdHVyZSBhLCBidXQgc3VwcG9ydCBmZWF0dXJlIGINCg0KdGhl biBob3cgYWJvdXQgdGhlIGZlYXR1cmUgbWVzc2FnZXMgaW4gPGhlbGxvPiBmcm9tIEFnZW50Pw0K DQpzb2x1dGlvbiAxOg0KICAgICAgICBjb250YWluICdmZWF0dXJlIGInIGluIDxoZWxsbz4gZnJv bSBBZ2VudA0KDQpzb2x1dGlvbiAyOg0KICAgICAgICBBZ2VudCBhdXRvbWF0aWNhbGx5IGZpbHRl ciBvdXQgJ2ZlYXR1cmUgYicgYmVjYXVzZSBpdHMgJ2lmLWZlYXR1cmUgDQptMTphJyBzdGF0ZW1l bnQgZG9lc24ndCBzdXBwb3J0DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KICDI59PQzsrM4qOsx+u8sMqxwarPtaOhDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBh bnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29u ZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFk ZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRp c2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRp b24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGli aXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRl bGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 002E731848257DE4_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBldmVyeW9uZTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSdtIG5ldyB0byBuZXRtb2QvWUFO RywgYW5kIEkgaGF2ZSBhDQpxdWVzdGlvbiBhYm91dCBmZWF0dXJlIGluICZsdDtoZWxsbyZndDsg bWVzc2FnZTwvZm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+RXhhbXBsZSA6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDtNMSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7IE0yPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 fC0tLXByZWZpeCBtMSAmbmJzcDsgJm5ic3A7fC0tLQ0KaW1wb3J0IE0xPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNw O3w8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgJm5ic3A7fC0tLSBwcmVmaXggbTE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDt8LS0tZmVhdHVyZSBhICZuYnNwOyAmbmJzcDt8LS0tDQpmZWF0 dXJlIGI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fC0tLSBpZi1m ZWF0dXJlIG0xOmE8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPk0xIGFuZCBNMiBib3RoIGFyZSB5YW5nIG1vZHVsZXMgYW5kDQptMiAnaW1wb3J0 JyBtMTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aWYg QWdlbnQgZG9lc24ndCBzdXBwb3J0IGZlYXR1cmUgYSwNCmJ1dCBzdXBwb3J0IGZlYXR1cmUgYjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhlbiBob3cg YWJvdXQgdGhlIGZlYXR1cmUgbWVzc2FnZXMNCmluICZsdDtoZWxsbyZndDsgZnJvbSBBZ2VudD88 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNvbHV0aW9u IDE6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgY29udGFpbg0KJ2ZlYXR1cmUgYicgaW4gJmx0O2hlbGxvJmd0OyBm cm9tIEFnZW50PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5zb2x1dGlvbiAyOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFnZW50DQphdXRvbWF0aWNhbGx5IGZpbHRlciBv dXQgJ2ZlYXR1cmUgYicgYmVjYXVzZSBpdHMgJ2lmLWZlYXR1cmUgbTE6YScgc3RhdGVtZW50DQpk b2Vzbid0IHN1cHBvcnQ8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyDI59PQzsrM4qOs x+u8sMqxwarPtaOhPC9mb250Pg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMg cHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1 c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVk IHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9y IG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBp biBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8 L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 002E731848257DE4_=-- From nobody Fri Feb 6 00:44:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C281A19F8 for ; Fri, 6 Feb 2015 00:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fEmIuh6xuK7 for ; Fri, 6 Feb 2015 00:44:11 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B941A0108 for ; Fri, 6 Feb 2015 00:44:11 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0C5951A91; Fri, 6 Feb 2015 09:44:10 +0100 (CET) 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 2ZI0pbFtqq4O; Fri, 6 Feb 2015 09:43:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Feb 2015 09:44:09 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 392A820036; Fri, 6 Feb 2015 09:44:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dvsh6VUQkYyQ; Fri, 6 Feb 2015 09:36:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92AD620035; Fri, 6 Feb 2015 09:44:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B1B24319C14E; Fri, 6 Feb 2015 09:44:07 +0100 (CET) Date: Fri, 6 Feb 2015 09:44:07 +0100 From: Juergen Schoenwaelder To: du.baowei23@zte.com.cn Message-ID: <20150206084407.GB67483@elstar.local> Mail-Followup-To: du.baowei23@zte.com.cn, 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.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] question about feature statements in message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2015 08:44:16 -0000 On Fri, Feb 06, 2015 at 04:27:20PM +0800, du.baowei23@zte.com.cn wrote: > Hi, everyone > > I'm new to netmod/YANG, and I have a question about feature in > message > > > Example : > > M1 M2 > | | > |---prefix m1 |--- import M1 > | | | > | |--- prefix m1 > | | > |---feature a |--- feature b > | > |--- if-feature m1:a > > > M1 and M2 both are yang modules and m2 'import' m1 > > if Agent doesn't support feature a, but support feature b > > then how about the feature messages in from Agent? > > solution 1: > contain 'feature b' in from Agent > > solution 2: > Agent automatically filter out 'feature b' because its 'if-feature > m1:a' statement doesn't support > If feature b depends on feature a, then the agent must support (and hence accounce) feature a when it supports b. So either the agent is broken (if it does b without a) or the data model is broken (since it requires a for b even though it is possible to have b without a). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 6 04:05:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C771A0263 for ; Fri, 6 Feb 2015 04:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs2qdhluvLdL for ; Fri, 6 Feb 2015 04:05:08 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 207641A01BA for ; Fri, 6 Feb 2015 04:05:07 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3D1E91CC0248; Fri, 6 Feb 2015 13:05:04 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 06 Feb 2015 13:05:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 12:05:14 -0000 Andy Bierman writes: > On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: >> >>> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: >>> >>> Ladislav Lhotka wrote: >>>> Hi, >>>> >>>> $SUBJ is already several months late, so I think we should proceed >>>> towards delivering it. I checked my mail archive since the -02 revision, >>>> and it seems two issues need to be resolved: >>>> >>>> 1. Andy objected to making redundant namespace prefixes illegal. I >>>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >>>> instead of MUST NOT): >>>> >>>> OLD >>>> >>>> Names with namespace identifiers in the form shown in Figure 1 MUST >>>> be used for all top-level YANG data nodes, and also for all nodes >>>> whose parent node belongs to a different namespace. Otherwise, names >>>> with namespace identifiers MUST NOT be used. >>>> >>>> NEW >>>> >>>> Names with namespace identifiers in the form shown in Figure 1 MUST >>>> be used for all top-level YANG data nodes, and also for all nodes >>>> whose parent node belongs to a different namespace. Otherwise, names >>>> with namespace identifiers SHOULD NOT be used. >>> >>> I don't think this is a good idea. The reason is that it complicates >>> both client and server code. An implementation cannot write code like >>> this: >>> >>> name = interface['name'] >>> mtu = interface['mtu'] >>> >>> instead we have to look for both 'name' and 'ietf-interfaces:name': >>> >>> if 'name' in interface: >>> name = interface['name'] >>> else >>> name = interface['ietf-interfaces:name'] >>> >>> >>> One single deterministic encoding is simpler everywhere and less >>> error-prone. >> >> I agree with you, this again makes standard JSON parsers (that give you a pointer to the parsed structure) considerably less useful. >> > > Customers are not following this rule and they never will. Likewise, your customers may not be following the rule that the last member in an object must not be followed by a comma, and your parser may even tolerate it. Nevertheless, it still violates the JSON spec. Martin's example is a real problem for application writers who want to use standard JSON parsers - and support for as many existing parsers as possible is exactly the reason why we decided to support I-JSON. Consider that the disambiguation code above (with prefix or without?) will have to be done essentially for all keys the application needs to access. I understand your JSON parser is custom-made so it is of no concern to you. Lada > They avoid the problem by avoiding local-name conflicts > in the first place. It is not user-friendly or CLI-friendly > to allow sibling nodes to have the same local name. > These are not open systems so controlling the module set > is not a problem. > > >> Lada >> >>> >>>> 2. anyxml encoding: although it is a misnomer, I propose to keep the >>>> current definition (sec. 5.5), i.e. allow any valid JSON value in >>>> JSON-encoded anyxml instances. I also think the text makes it >>>> sufficiently clear that no standard mapping between XML- and >>>> JSON-encoded instances is defined. >>> >>> Ok. >>> > > I am not so sure ignoring XML is OK. > There should be a warning that the JSON encoding the > sender picks is not "sticky". The receiver MAY change it > to something else, such that if the original sender retrieves > a new copy from the server, the JSON types might have changed. > > It is only safe to use the common features between XML and JSON. > > >>> >>> /martin >> > > Andy > > >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> 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 Feb 6 04:18:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3FC1A0263 for ; Fri, 6 Feb 2015 04:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXjAbNEEP2VY for ; Fri, 6 Feb 2015 04:18:51 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9FF1A001B for ; Fri, 6 Feb 2015 04:18:51 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id AAF3B1CC0248; Fri, 6 Feb 2015 13:18:50 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Martin Bjorklund In-Reply-To: References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 06 Feb 2015 13:18:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 12:18:54 -0000 Andy Bierman writes: > On Thu, Feb 5, 2015 at 12:45 PM, Martin Bjorklund wrote: >> Andy Bierman wrote: >>> On Thu, Feb 5, 2015 at 5:49 AM, Ladislav Lhotka wrote: >>> > >>> >> On 05 Feb 2015, at 13:52, Martin Bjorklund wrote: >>> >> >>> >> Ladislav Lhotka wrote: >>> >>> Hi, >>> >>> >>> >>> $SUBJ is already several months late, so I think we should proceed >>> >>> towards delivering it. I checked my mail archive since the -02 >>> >>> revision, >>> >>> and it seems two issues need to be resolved: >>> >>> >>> >>> 1. Andy objected to making redundant namespace prefixes illegal. I >>> >>> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >>> >>> instead of MUST NOT): >>> >>> >>> >>> OLD >>> >>> >>> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >>> >>> be used for all top-level YANG data nodes, and also for all nodes >>> >>> whose parent node belongs to a different namespace. Otherwise, names >>> >>> with namespace identifiers MUST NOT be used. >>> >>> >>> >>> NEW >>> >>> >>> >>> Names with namespace identifiers in the form shown in Figure 1 MUST >>> >>> be used for all top-level YANG data nodes, and also for all nodes >>> >>> whose parent node belongs to a different namespace. Otherwise, names >>> >>> with namespace identifiers SHOULD NOT be used. >>> >> >>> >> I don't think this is a good idea. The reason is that it complicates >>> >> both client and server code. An implementation cannot write code like >>> >> this: >>> >> >>> >> name = interface['name'] >>> >> mtu = interface['mtu'] >>> >> >>> >> instead we have to look for both 'name' and 'ietf-interfaces:name': >>> >> >>> >> if 'name' in interface: >>> >> name = interface['name'] >>> >> else >>> >> name = interface['ietf-interfaces:name'] >>> >> >>> >> >>> >> One single deterministic encoding is simpler everywhere and less >>> >> error-prone. >>> > >>> > I agree with you, this again makes standard JSON parsers (that give >>> > you a pointer to the parsed structure) considerably less useful. >>> > >>> >>> Customers are not following this rule and they never will. >>> They avoid the problem by avoiding local-name conflicts >>> in the first place. It is not user-friendly or CLI-friendly >>> to allow sibling nodes to have the same local name. >>> These are not open systems so controlling the module set >>> is not a problem. >> >> But this is *another* issue. Neither of the alternatives support this >> use case. >> >>> >>> 2. anyxml encoding: although it is a misnomer, I propose to keep the >>> >>> current definition (sec. 5.5), i.e. allow any valid JSON value in >>> >>> JSON-encoded anyxml instances. I also think the text makes it >>> >>> sufficiently clear that no standard mapping between XML- and >>> >>> JSON-encoded instances is defined. >>> >> >>> >> Ok. >>> >> >>> >>> I am not so sure ignoring XML is OK. >> >> So how would you encode an arbitrary XML snippet (which is what anyxml >> is) in JSON? I know you want to restrict anyxml, but that is simply >> not how it is defined in 6020. For now we have to live with that. >> > > No -- the description-stmts for the anyxml nodes in YANG Patch > specify the limitations and an implementation of ietf-yang-patch > MUST support what it says. If other individual YANG modules > want to constrain anyxml in specific ways, they can do that. > We can specify what an implementation of a particular module MUST > accept. Exactly! I think most, if not all, uses of anyxml and anydata will assume some specific syntax and semantics (that needs to be explained in the description). But this may also include a sensible, perhaps non-trivial, way for mapping XML to JSON and back. And if there is no sensible mapping, it is IMO also acceptable that certain uses of anyxml will only be possible in XML encoding. The point really is that there needn't be any common rules for all uses of anyxml, except that it has to be well-formed for the given encoding. > > XML has simple nodes which are empty and those which are not empty. > > XML non-empty simple node <--> JSON string > XML empty node <--> JSON null > XML complex node <--> JSON object > > No requirement to send arrays, boolean, or numbers, but MAY send, > and MUST accept. No requirement to preserve JSON type info. > Must preserve xmlns and other attributes if QName or XPath content found. > No XML PIs or mixed content allowed. > IMO this will make XML <--> JSON translation work. > > > >>> There should be a warning that the JSON encoding the >>> sender picks is not "sticky". The receiver MAY change it >>> to something else, such that if the original sender retrieves >>> a new copy from the server, the JSON types might have changed. >>> >>> It is only safe to use the common features between XML and JSON. >> >> Right, and you get this from anydata! >> > > Not as Lada defined his YANG to JSON mapping. So far, anydata isn't covered at all. Lada > > >> >> /martin > > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 6 04:35:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9FB1A0263 for ; Fri, 6 Feb 2015 04:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOlynTZrKtD8 for ; Fri, 6 Feb 2015 04:34:58 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 227011A012D for ; Fri, 6 Feb 2015 04:34:58 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 712981CC0248; Fri, 6 Feb 2015 13:34:56 +0100 (CET) From: Ladislav Lhotka To: Randy Presuhn , netmod@ietf.org In-Reply-To: <20874505.1423197343643.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> References: <20874505.1423197343643.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 06 Feb 2015 13:34:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 12:35:00 -0000 Randy Presuhn writes: > Hi - > >>From: Andy Bierman >>Sent: Feb 5, 2015 8:27 AM >>To: Ladislav Lhotka >>Cc: "netmod@ietf.org" >>Subject: Re: [netmod] yang-json document > ... >>>>> NEW >>>>> >>>>> Names with namespace identifiers in the form shown in Figure 1 MUST >>>>> be used for all top-level YANG data nodes, and also for all nodes >>>>> whose parent node belongs to a different namespace. Otherwise, names >>>>> with namespace identifiers SHOULD NOT be used. >>>> >> >>I think MUST violates the RFC 2119 rules (issue Randy already raised). >>If the receiver gets "interfaces" instead of "ietf-interfaces:interfaces", >>and there is only 1 possible match, then the receiver is forced to >>reject input that it understands. Even if there are multiple matches, >>the receiver may be able to detect which object is being sent. >> >>Of course, if there are multiple matches and the receiver cannot >>detect which one is sent, the input MUST be rejected. > > Before anyone reads too much into what I wrote let me be clear(er) > about my concern: > > If the constraint is not necessary to ensure interoperability, using > "MUST" is inappropriate. As I understand Andy's argument, receivers > "may be able" to disambiguate. I'm not convinced that that's sufficient > to ensure interoperability. Unless the behaviour is adequately specified > so that all conformant implementaions will resolve in the same way the > potential "multiple matches" Andy describes, it sounds like the "MUST" > really *is* appropriate. Yes, thank you for the clarification. I do think unnecessary entropy in an encoding it detrimental to interoperability. In fact, if there are any concerns about the use of 2119 keywords we can also avoid using them altogether. Lada > > Randy > > _______________________________________________ > 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 Feb 6 04:49:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C921A1A55 for ; Fri, 6 Feb 2015 04:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeKvYgTZQWoG for ; Fri, 6 Feb 2015 04:49:01 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 992AC1A1A17 for ; Fri, 6 Feb 2015 04:49:01 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C367F1CC0248; Fri, 6 Feb 2015 13:49:00 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer , Andy Bierman In-Reply-To: <201502060448.t164mNSX059800@idle.juniper.net> References: <201502060448.t164mNSX059800@idle.juniper.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 06 Feb 2015 13:49:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 12:49:06 -0000 Phil Shafer writes: > Andy Bierman writes: >>> So how would you encode an arbitrary XML snippet (which is what anyxml >>> is) in JSON? I know you want to restrict anyxml, but that is simply >>> not how it is defined in 6020. For now we have to live with that. >> >>No -- the description-stmts for the anyxml nodes in YANG Patch >>specify the limitations and an implementation of ietf-yang-patch >>MUST support what it says. If other individual YANG modules >>want to constrain anyxml in specific ways, they can do that. >>We can specify what an implementation of a particular module MUST >>accept. > > Doesn't this mean that yang-patch is not compatible with > yang, since one can define models in yang that yang-patch > will not handle? > >>XML has simple nodes which are empty and those which are not empty. >> XML non-empty simple node <--> JSON string >> XML empty node <--> JSON null >> XML complex node <--> JSON object > > This is an extreme oversimplification. Consider the real-world > case: > > anyxml web-banner { > description "Chunk of XHTML that is placed at the > top of every page for the embedded web server"; > } > > >

This is very sensitive data

> >

I'm serious, dude

> > > What does the JSON for this look like? I think the only viable > answer is: > > "web-banner": "

This is very sensitive data

\n src="mister-yuk.png"/>\n

I'm serious, dude

\n" I don't think so, the following is IMO a much better option: "web-banner": "This is *very sensitive* data. ![](mister-yuk.png) I'm serious, dude" To be able to do this, it should be sufficient that the description of the "web-banner" anyxml node states that HTML has to be used in XML encoding and markdown in JSON. Note that the -00 version of the draft contained a very similar example: http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00#section-3.2.5 Lada > > Thanks, > Phil > > _______________________________________________ > 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 Feb 6 05:36:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BAC1A0367 for ; Fri, 6 Feb 2015 05:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t6_0qu9As-h for ; Fri, 6 Feb 2015 05:36:10 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F5D1A010F for ; Fri, 6 Feb 2015 05:36:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 388311210; Fri, 6 Feb 2015 14:36:09 +0100 (CET) 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 jgyoTGYQz8Lp; Fri, 6 Feb 2015 14:35:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Feb 2015 14:36:08 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9071420036; Fri, 6 Feb 2015 14:36:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uiqJXkVYc12q; Fri, 6 Feb 2015 14:28:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9C2E20035; Fri, 6 Feb 2015 14:36:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 14F9F31AA158; Fri, 6 Feb 2015 14:36:07 +0100 (CET) Date: Fri, 6 Feb 2015 14:36:07 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150206133607.GB91476@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2015 13:36:13 -0000 On Fri, Feb 06, 2015 at 01:18:52PM +0100, Ladislav Lhotka wrote: > > The point really is that there needn't be any common rules for all uses > of anyxml, except that it has to be well-formed for the given encoding. > Your interpretation that anyxml means any-encoding-specific-stuff does apparently not match everybody's reading of RFC 6020's definition of anyxml. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 6 05:38:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5E51A010F for ; Fri, 6 Feb 2015 05:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxShxZImz-01 for ; Fri, 6 Feb 2015 05:38:46 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656C61A0367 for ; Fri, 6 Feb 2015 05:38:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 367141AC8; Fri, 6 Feb 2015 14:38:45 +0100 (CET) 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 ceLOmFoPOGlU; Fri, 6 Feb 2015 14:38:18 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Feb 2015 14:38:44 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8166020036; Fri, 6 Feb 2015 14:38:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1_d1rCKGuUFQ; Fri, 6 Feb 2015 14:38:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 917BF20035; Fri, 6 Feb 2015 14:38:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B0E9B31AA1E6; Fri, 6 Feb 2015 14:38:43 +0100 (CET) Date: Fri, 6 Feb 2015 14:38:43 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150206133843.GC91476@elstar.local> Mail-Followup-To: Ladislav Lhotka , Phil Shafer , Andy Bierman , "netmod@ietf.org" References: <201502060448.t164mNSX059800@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2015 13:38:49 -0000 On Fri, Feb 06, 2015 at 01:49:02PM +0100, Ladislav Lhotka wrote: > Phil Shafer writes: > > > > > What does the JSON for this look like? I think the only viable > > answer is: > > > > "web-banner": "

This is very sensitive data

\n > src="mister-yuk.png"/>\n

I'm serious, dude

\n" > > I don't think so, the following is IMO a much better option: > > "web-banner": > "This is *very sensitive* data. > > ![](mister-yuk.png) > > I'm serious, dude" > > To be able to do this, it should be sufficient that the description of > the "web-banner" anyxml node states that HTML has to be used in XML > encoding and markdown in JSON. > > Note that the -00 version of the draft contained a very similar example: > > http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00#section-3.2.5 > As technical contributor, I do not agree that an encoder is tasked to arbitrarily render XML content in the hope that the receiver likes the result. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 6 05:47:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1A01A1AAC for ; Fri, 6 Feb 2015 05:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 t1HGLTyT2rNp for ; Fri, 6 Feb 2015 05:47:26 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18AF1A010F for ; Fri, 6 Feb 2015 05:47:26 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id BCA5D13F7AF; Fri, 6 Feb 2015 14:47:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423230444; bh=4WNDxu5lNsqT9BA1UsgcqkhiP9Rc6eqY3kjFxi6AJXs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FIdgRK0GT4H+JV7YQJTA6KABH7s5nGG3l/CZjQnSGDnq6HUQ7nbptitH+Ps09+AXu NmrkilZ3hUL/St79xG4MFKaWBpz8h0pNVGU7/eU+ZFaReXTenFlXu0fspeNoRGg3EO +EDSJd6+96LYR+QuNjMZdOPnmkHzMF2NN4AnZvF4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150206133607.GB91476@elstar.local> Date: Fri, 6 Feb 2015 14:47:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> <20150206133607.GB91476@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 13:47:28 -0000 > On 06 Feb 2015, at 14:36, Juergen Schoenwaelder = wrote: >=20 > On Fri, Feb 06, 2015 at 01:18:52PM +0100, Ladislav Lhotka wrote: >>=20 >> The point really is that there needn't be any common rules for all = uses >> of anyxml, except that it has to be well-formed for the given = encoding.=20 >>=20 >=20 > Your interpretation that anyxml means any-encoding-specific-stuff does > apparently not match everybody's reading of RFC 6020's definition of > anyxml. Well, 6020 only deals with XML encoding and the definition is exactly = what you said - any XML stuff: The "anyxml" statement is used to represent an unknown chunk of XML. No restrictions are placed on the XML. I don=E2=80=99t know why JSON (or, for that matter, any other) encoding = should be any different. 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 Fri Feb 6 05:54:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF41C1A1AB2 for ; Fri, 6 Feb 2015 05:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0NFCRUjh7KF for ; Fri, 6 Feb 2015 05:54:45 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C811A0262 for ; Fri, 6 Feb 2015 05:54:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A64CE131C; Fri, 6 Feb 2015 14:54:43 +0100 (CET) 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 7PY9d1GfhTsX; Fri, 6 Feb 2015 14:54:17 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Feb 2015 14:54:43 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC9C720036; Fri, 6 Feb 2015 14:54:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ngr4dcF3qkNW; Fri, 6 Feb 2015 14:46:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0D5520035; Fri, 6 Feb 2015 14:54:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1535E31AA63D; Fri, 6 Feb 2015 14:54:42 +0100 (CET) Date: Fri, 6 Feb 2015 14:54:42 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150206135442.GA92163@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> <20150206133607.GB91476@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2015 13:54:47 -0000 On Fri, Feb 06, 2015 at 02:47:26PM +0100, Ladislav Lhotka wrote: > > > On 06 Feb 2015, at 14:36, Juergen Schoenwaelder wrote: > > > > On Fri, Feb 06, 2015 at 01:18:52PM +0100, Ladislav Lhotka wrote: > >> > >> The point really is that there needn't be any common rules for all uses > >> of anyxml, except that it has to be well-formed for the given encoding. > >> > > > > Your interpretation that anyxml means any-encoding-specific-stuff does > > apparently not match everybody's reading of RFC 6020's definition of > > anyxml. > > Well, 6020 only deals with XML encoding and the definition is exactly what you said - any XML stuff: > > The "anyxml" statement is used to represent an unknown chunk of XML. > No restrictions are placed on the XML. > > I don’t know why JSON (or, for that matter, any other) encoding should be any different. > RFC 6020 very clearly defines what anyxml is. With YANG 1.1, we are likely 'deprecating' anyxml and adding anydata, which is any data that can be modeled with YANG. This, however, does not mean that anyxml suddenly changes its meaning. And so far, the JSON mapping is based on YANG 1.0, that is RFC 6020, where anyxml means any xml. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 6 05:57:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004631A1AC1 for ; Fri, 6 Feb 2015 05:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dN8Vu_wYNVS for ; Fri, 6 Feb 2015 05:57:39 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 36B4E1A1AB2 for ; Fri, 6 Feb 2015 05:57:39 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 30F7B12801A5; Fri, 6 Feb 2015 14:57:38 +0100 (CET) Date: Fri, 06 Feb 2015 14:57:38 +0100 (CET) Message-Id: <20150206.145738.1020979748838144472.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150206133607.GB91476@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / 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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 13:57:41 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDYgRmVi IDIwMTUsIGF0IDE0OjM2LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPiA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPiANCj4gPiBPbiBGcmksIEZlYiAw NiwgMjAxNSBhdCAwMToxODo1MlBNICswMTAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4+ IA0KPiA+PiBUaGUgcG9pbnQgcmVhbGx5IGlzIHRoYXQgdGhlcmUgbmVlZG4ndCBiZSBhbnkgY29t bW9uIHJ1bGVzIGZvciBhbGwNCj4gPj4gdXNlcw0KPiA+PiBvZiBhbnl4bWwsIGV4Y2VwdCB0aGF0 IGl0IGhhcyB0byBiZSB3ZWxsLWZvcm1lZCBmb3IgdGhlIGdpdmVuDQo+ID4+IGVuY29kaW5nLg0K PiA+PiANCj4gPiANCj4gPiBZb3VyIGludGVycHJldGF0aW9uIHRoYXQgYW55eG1sIG1lYW5zIGFu eS1lbmNvZGluZy1zcGVjaWZpYy1zdHVmZiBkb2VzDQo+ID4gYXBwYXJlbnRseSBub3QgbWF0Y2gg ZXZlcnlib2R5J3MgcmVhZGluZyBvZiBSRkMgNjAyMCdzIGRlZmluaXRpb24gb2YNCj4gPiBhbnl4 bWwuDQo+IA0KPiBXZWxsLCA2MDIwIG9ubHkgZGVhbHMgd2l0aCBYTUwgZW5jb2RpbmcgYW5kIHRo ZSBkZWZpbml0aW9uIGlzIGV4YWN0bHkNCj4gd2hhdCB5b3Ugc2FpZCAtIGFueSBYTUwgc3R1ZmY6 DQo+IA0KPiAgICBUaGUgImFueXhtbCIgc3RhdGVtZW50IGlzIHVzZWQgdG8gcmVwcmVzZW50IGFu IHVua25vd24gY2h1bmsgb2YgWE1MLg0KPiAgICBObyByZXN0cmljdGlvbnMgYXJlIHBsYWNlZCBv biB0aGUgWE1MLg0KPiANCj4gSSBkb27igJl0IGtub3cgd2h5IEpTT04gKG9yLCBmb3IgdGhhdCBt YXR0ZXIsIGFueSBvdGhlcikgZW5jb2Rpbmcgc2hvdWxkDQo+IGJlIGFueSBkaWZmZXJlbnQuDQoN CkFnYWluIHdlJ3JlIGdvaW5nIGluIGNpcmNsZXMuDQoNClJpZ2h0IG5vdyB3ZSBoYXZlIGEgcHJv YmxlbToNCg0KICAxLiAgV2Ugd2FudCBZQU5HIFBBVENIIHRvIGJlIGludGVyb3BlcmFibGUuDQoN CiAgMi4gIFlBTkcgUEFUQ0ggdXNlcyBhbnl4bWwuDQoNCiAgMy4gIFlBTkcgUEFUQ0ggc3VwcG9y dHMganNvbiBlbmNvZGluZyBhcyBkZWZpbmVkIGluIHRoZSBqc29uIGRyYWZ0Lg0KDQogIDQuICBU aGUganNvbiBkcmFmdCBzYXlzIHRoYXQgbm8gZW5jb2RpbmcgaXMgZGVmaW5lZCBmb3IgYW55eG1s Lg0KDQogIDUuICBDb25jbHVzaW9uOiAoMSkgY2Fubm90IGJlIHRydWUuDQoNCg0KU28gaG93IGRv IHdlIHNvbHZlIHRoaXM/DQoNCiAgQS4gIFdhaXQgZm9yIGFueWRhdGEsIGFuZCBkZWZpbmUganNv biBlbmNvZGluZyBydWxlcyBmb3IgYW55ZGF0YS4NCg0KICBCLiAgUmVtb3ZlIHN1cHBvcnQgZm9y IGpzb24gZnJvbSBZQU5HIFBBVENILg0KDQoNCi9tYXJ0aW4NCg0K From nobody Fri Feb 6 05:59:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4B71A1AC1 for ; Fri, 6 Feb 2015 05:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 3PNvO5W8Sqkh for ; Fri, 6 Feb 2015 05:59:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4113D1A1AB2 for ; Fri, 6 Feb 2015 05:59:19 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id D152C13F9AF; Fri, 6 Feb 2015 14:59:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423231157; bh=jGAqcS+pYiCtxbEvq3ZMGUYH8FINFDbeJ+Br5NLWIAg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=btDaWksUe06M7UjoihoqBVT+fBGmgK+JrUACHSGt/fFM85yAQLinkgNHrXoGwPiat ysOqXeg16+RvcRowC792sOGGO839obLjSpvJ/JnkH7c8bYnNzZnD2AFtlHFsuOFCTi 8f8i/ILiGoqr2RYFP5K0MGbm5D8o/y6DLrRjtCBk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150206135442.GA92163@elstar.local> Date: Fri, 6 Feb 2015 14:59:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <87FC5A15-E51D-4FB8-81EC-2EAAA4A6E980@nic.cz> References: <20150205.135210.818152609244122122.mbj@tail-f.com> <15CBB080-9288-4881-8F28-DE1A24279820@nic.cz> <20150205.214557.720578496688087827.mbj@tail-f.com> <20150206133607.GB91476@elstar.local> <20150206135442.GA92163@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 13:59:20 -0000 > On 06 Feb 2015, at 14:54, Juergen Schoenwaelder = wrote: >=20 > On Fri, Feb 06, 2015 at 02:47:26PM +0100, Ladislav Lhotka wrote: >>=20 >>> On 06 Feb 2015, at 14:36, Juergen Schoenwaelder = wrote: >>>=20 >>> On Fri, Feb 06, 2015 at 01:18:52PM +0100, Ladislav Lhotka wrote: >>>>=20 >>>> The point really is that there needn't be any common rules for all = uses >>>> of anyxml, except that it has to be well-formed for the given = encoding.=20 >>>>=20 >>>=20 >>> Your interpretation that anyxml means any-encoding-specific-stuff = does >>> apparently not match everybody's reading of RFC 6020's definition of >>> anyxml. >>=20 >> Well, 6020 only deals with XML encoding and the definition is exactly = what you said - any XML stuff: >>=20 >> The "anyxml" statement is used to represent an unknown chunk of = XML. >> No restrictions are placed on the XML. >>=20 >> I don=E2=80=99t know why JSON (or, for that matter, any other) = encoding should be any different. >>=20 >=20 > RFC 6020 very clearly defines what anyxml is. With YANG 1.1, we are > likely 'deprecating' anyxml and adding anydata, which is any data that > can be modeled with YANG. This, however, does not mean that anyxml > suddenly changes its meaning. And so far, the JSON mapping is based on > YANG 1.0, that is RFC 6020, where anyxml means any xml. How did you come to the conclusion that I want to change the meaning of = the 6020 definition of anyxml? Unlike others, I think anyxml in its current form can occasionally be = useful. 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 Fri Feb 6 06:12:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52071A1AC6 for ; Fri, 6 Feb 2015 06:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 S5a0o9OfH0z4 for ; Fri, 6 Feb 2015 06:12:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23221A1AC1 for ; Fri, 6 Feb 2015 06:12:42 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id 7C94513F7AF; Fri, 6 Feb 2015 15:12:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423231961; bh=hUYNf3246Z7sflnXN7QFaIC/j1OcYpH+8vrNQGOChA0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jKNDePcODLVITDp763lD0ll19RuIO/fsrr/SGtQRY3QptU1auVfesRqrS+6kYaqAV 5je82ZE18Uxw7mr7vRWRNFYIQrgyaJjhHAMr4TEsTsDsmi/1WAlUu26mKeK3K7cFNH ifrFHmBIJEfJmNm3Sjo7q7DcswbkujOTdVV8eOUw= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150206.145738.1020979748838144472.mbj@tail-f.com> Date: Fri, 6 Feb 2015 15:12:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150206133607.GB91476@elstar.local> <20150206.145738.1020979748838144472.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:12:44 -0000 > On 06 Feb 2015, at 14:57, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 06 Feb 2015, at 14:36, Juergen Schoenwaelder >>> wrote: >>>=20 >>> On Fri, Feb 06, 2015 at 01:18:52PM +0100, Ladislav Lhotka wrote: >>>>=20 >>>> The point really is that there needn't be any common rules for all >>>> uses >>>> of anyxml, except that it has to be well-formed for the given >>>> encoding. >>>>=20 >>>=20 >>> Your interpretation that anyxml means any-encoding-specific-stuff = does >>> apparently not match everybody's reading of RFC 6020's definition of >>> anyxml. >>=20 >> Well, 6020 only deals with XML encoding and the definition is exactly >> what you said - any XML stuff: >>=20 >> The "anyxml" statement is used to represent an unknown chunk of = XML. >> No restrictions are placed on the XML. >>=20 >> I don=E2=80=99t know why JSON (or, for that matter, any other) = encoding should >> be any different. >=20 > Again we're going in circles. >=20 > Right now we have a problem: >=20 > 1. We want YANG PATCH to be interoperable. >=20 > 2. YANG PATCH uses anyxml. >=20 > 3. YANG PATCH supports json encoding as defined in the json draft. >=20 > 4. The json draft says that no encoding is defined for anyxml. You probably mean the json draft defines no *mapping* for anyxml. This = of course doesn=E2=80=99t prevent the YANG PATCH document from defining = specific rules and XML-JSON mapping for the contents of its anyxml = nodes, perhaps exactly in the sense of anydata. Why is this a problem? Lada >=20 > 5. Conclusion: (1) cannot be true. >=20 >=20 > So how do we solve this? >=20 > A. Wait for anydata, and define json encoding rules for anydata. >=20 > B. Remove support for json from YANG PATCH. C. Define specific rules for anyxml appearing in YANG PATCH. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 6 06:22:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E2C1A1AD2 for ; Fri, 6 Feb 2015 06:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvIRQP7Q6Czb for ; Fri, 6 Feb 2015 06:22:25 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id BD9451A1AE5 for ; Fri, 6 Feb 2015 06:22:24 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 03A101280996; Fri, 6 Feb 2015 15:22:24 +0100 (CET) Date: Fri, 06 Feb 2015 15:22:23 +0100 (CET) Message-Id: <20150206.152223.1122646753947355607.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150206.145738.1020979748838144472.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / 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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:22:28 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDYgRmVi IDIwMTUsIGF0IDE0OjU3LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g DQo+ID4+PiBPbiAwNiBGZWIgMjAxNSwgYXQgMTQ6MzYsIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0K PiA+Pj4gPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ID4+ PiANCj4gPj4+IE9uIEZyaSwgRmViIDA2LCAyMDE1IGF0IDAxOjE4OjUyUE0gKzAxMDAsIExhZGlz bGF2IExob3RrYSB3cm90ZToNCj4gPj4+PiANCj4gPj4+PiBUaGUgcG9pbnQgcmVhbGx5IGlzIHRo YXQgdGhlcmUgbmVlZG4ndCBiZSBhbnkgY29tbW9uIHJ1bGVzIGZvciBhbGwNCj4gPj4+PiB1c2Vz DQo+ID4+Pj4gb2YgYW55eG1sLCBleGNlcHQgdGhhdCBpdCBoYXMgdG8gYmUgd2VsbC1mb3JtZWQg Zm9yIHRoZSBnaXZlbg0KPiA+Pj4+IGVuY29kaW5nLg0KPiA+Pj4+IA0KPiA+Pj4gDQo+ID4+PiBZ b3VyIGludGVycHJldGF0aW9uIHRoYXQgYW55eG1sIG1lYW5zIGFueS1lbmNvZGluZy1zcGVjaWZp Yy1zdHVmZiBkb2VzDQo+ID4+PiBhcHBhcmVudGx5IG5vdCBtYXRjaCBldmVyeWJvZHkncyByZWFk aW5nIG9mIFJGQyA2MDIwJ3MgZGVmaW5pdGlvbiBvZg0KPiA+Pj4gYW55eG1sLg0KPiA+PiANCj4g Pj4gV2VsbCwgNjAyMCBvbmx5IGRlYWxzIHdpdGggWE1MIGVuY29kaW5nIGFuZCB0aGUgZGVmaW5p dGlvbiBpcyBleGFjdGx5DQo+ID4+IHdoYXQgeW91IHNhaWQgLSBhbnkgWE1MIHN0dWZmOg0KPiA+ PiANCj4gPj4gICBUaGUgImFueXhtbCIgc3RhdGVtZW50IGlzIHVzZWQgdG8gcmVwcmVzZW50IGFu IHVua25vd24gY2h1bmsgb2YgWE1MLg0KPiA+PiAgIE5vIHJlc3RyaWN0aW9ucyBhcmUgcGxhY2Vk IG9uIHRoZSBYTUwuDQo+ID4+IA0KPiA+PiBJIGRvbuKAmXQga25vdyB3aHkgSlNPTiAob3IsIGZv ciB0aGF0IG1hdHRlciwgYW55IG90aGVyKSBlbmNvZGluZyBzaG91bGQNCj4gPj4gYmUgYW55IGRp ZmZlcmVudC4NCj4gPiANCj4gPiBBZ2FpbiB3ZSdyZSBnb2luZyBpbiBjaXJjbGVzLg0KPiA+IA0K PiA+IFJpZ2h0IG5vdyB3ZSBoYXZlIGEgcHJvYmxlbToNCj4gPiANCj4gPiAgMS4gIFdlIHdhbnQg WUFORyBQQVRDSCB0byBiZSBpbnRlcm9wZXJhYmxlLg0KPiA+IA0KPiA+ICAyLiAgWUFORyBQQVRD SCB1c2VzIGFueXhtbC4NCj4gPiANCj4gPiAgMy4gIFlBTkcgUEFUQ0ggc3VwcG9ydHMganNvbiBl bmNvZGluZyBhcyBkZWZpbmVkIGluIHRoZSBqc29uIGRyYWZ0Lg0KPiA+IA0KPiA+ICA0LiAgVGhl IGpzb24gZHJhZnQgc2F5cyB0aGF0IG5vIGVuY29kaW5nIGlzIGRlZmluZWQgZm9yIGFueXhtbC4N Cj4gDQo+IFlvdSBwcm9iYWJseSBtZWFuIHRoZSBqc29uIGRyYWZ0IGRlZmluZXMgbm8gKm1hcHBp bmcqIGZvciBhbnl4bWwuDQoNCk9rLCB0aGVyZSBpcyBubyBtYXBwaW5nIGRlZmluZWQsIGJ1dCBh bHNvLCB0aGUgKmVuY29kaW5nKiBpcyBub3QNCmNsZWFyOg0KDQogICBBbiBhbnl4bWwgaW5zdGFu Y2UgaXMgZW5jb2RlZCBhcyBhIG5hbWUvdmFsdWUgcGFpci4gIFRoZSB2YWx1ZSBjYW4NCiAgIGJl IG9mIGFueSB2YWxpZCBKU09OIHR5cGUNCg0KVGhpcyBtZWFucyB0aGF0IGluIGdlbmVyYWwsIHRo ZXJlIGlzIG5vIGludGVyb3BlcmFibGUgd2F5IHRvIGVuY29kZQ0KYW55eG1sIGluIGpzb24gKGFu ZCB0aGlzIEkgdGhpbmsgaXMganVzdCBmaW5lKS4NCg0KPiBUaGlzDQo+IG9mIGNvdXJzZSBkb2Vz buKAmXQgcHJldmVudCB0aGUgWUFORyBQQVRDSCBkb2N1bWVudCBmcm9tIGRlZmluaW5nDQo+IHNw ZWNpZmljIHJ1bGVzIGFuZCBYTUwtSlNPTiBtYXBwaW5nIGZvciB0aGUgY29udGVudHMgb2YgaXRz IGFueXhtbA0KPiBub2RlcywgcGVyaGFwcyBleGFjdGx5IGluIHRoZSBzZW5zZSBvZiBhbnlkYXRh Lg0KDQpJIGRvbid0IHRoaW5rIHRoaXMgcHJvcG9zYWwgaGFzIGNvbWUgdXAgYmVmb3JlLg0KDQpU aGVuIHRoZSBqc29uIGRvY3VtZW50IHNob3VsZCBwcm9iYWJseSBzYXkgdGhhdCBhbnkgdXNhZ2Ug b2YgYW55eG1sDQpNQVkgZGVmaW5lIHNwZWNpZmljIGVuY29kaW5nIGFuZCBtYXBwaW5nIHJ1bGVz Lg0KDQo+IFdoeSBpcyB0aGlzIGEgcHJvYmxlbT8NCg0KV2VsbCwgaXQgcHJvYmFibHkgd29ya3Mg aW4gb25lIG9yIHR3byB1c2UgY2FzZXMsIGJ1dCBpdCBpcyBub3QgdmVyeQ0Kc2NhbGFibGUuLi4N Cg0KPiA+ICA1LiAgQ29uY2x1c2lvbjogKDEpIGNhbm5vdCBiZSB0cnVlLg0KPiA+IA0KPiA+IA0K PiA+IFNvIGhvdyBkbyB3ZSBzb2x2ZSB0aGlzPw0KPiA+IA0KPiA+ICBBLiAgV2FpdCBmb3IgYW55 ZGF0YSwgYW5kIGRlZmluZSBqc29uIGVuY29kaW5nIHJ1bGVzIGZvciBhbnlkYXRhLg0KPiA+IA0K PiA+ICBCLiAgUmVtb3ZlIHN1cHBvcnQgZm9yIGpzb24gZnJvbSBZQU5HIFBBVENILg0KPiANCj4g ICBDLiBEZWZpbmUgc3BlY2lmaWMgcnVsZXMgZm9yIGFueXhtbCBhcHBlYXJpbmcgaW4gWUFORyBQ QVRDSC4NCg0KDQoNCi9tYXJ0aW4NCg== From nobody Fri Feb 6 06:36:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A281A1B24; Fri, 6 Feb 2015 06:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwNrpW-HnUns; Fri, 6 Feb 2015 06:36:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 996E01A1AC6; Fri, 6 Feb 2015 06:36:14 -0800 (PST) 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: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206143614.32589.84386.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 06:36:14 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:36:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Network Access Control List (ACL) YANG Data Model Authors : Dean Bogdanovic Kiran Agrahara Sreenivasa Lisa Huang Dana Blair Filename : draft-ietf-netmod-acl-model-01.txt Pages : 24 Date : 2015-02-05 Abstract: This document describes a data model of Access Control List (ACL) basic building blocks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-acl-model-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-01 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 Feb 6 06:50:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA07B1A1AE2 for ; Fri, 6 Feb 2015 06:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB7SSCux49Zj for ; Fri, 6 Feb 2015 06:50:32 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 1D6A41A1AD0 for ; Fri, 6 Feb 2015 06:50:32 -0800 (PST) Received: by labhs14 with SMTP id hs14so1587037lab.9 for ; Fri, 06 Feb 2015 06:50:30 -0800 (PST) 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:content-type; bh=xOW5GzpZMcg9kX5MhvFnfYrgDHarnYBXhxPyHnWnhnY=; b=IzwRG3ZI5QM7mhMprAiOjjS3rkRTqSR3AbI59ol4UXpnfltl7cvlxZWvbI5OBtkd3x zMMhJIFPjEjZ3xON131Q4Lzc44p9+k7pLFV20ZO5LulwNqs5Z9W+x9GLeppqagKwHz+T e9l0T/XE29vbqm4EvZt99orklH0im2Zt3+tSjLBrHqnX8jYmuQXiVWtxNtb+8O2KWZqc lvpRMfOIr5WOqVViEXSX5mVnxzrnrb61W/1WKqn1Pn5ZBGA9OVD1T3KudbwPm1xCrClE SENleaXizpee5aIh6bjrNJbKmuq5lVi/SpItcEuXpDMq81rJdgTTM/ImNXrjfY4YK6ft aVtQ== X-Gm-Message-State: ALoCoQmsFx4Rw6UJKZWuwRCeMH693TlPeNeoWYONRsjaEg21u5zzk8QAaQdrBF3fjEC06Gbvg0T2 MIME-Version: 1.0 X-Received: by 10.152.22.39 with SMTP id a7mr3046040laf.119.1423234230414; Fri, 06 Feb 2015 06:50:30 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 6 Feb 2015 06:50:30 -0800 (PST) In-Reply-To: <20874505.1423197343643.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> References: <20874505.1423197343643.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Fri, 6 Feb 2015 06:50:30 -0800 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:50:34 -0000 On Thu, Feb 5, 2015 at 8:35 PM, Randy Presuhn wrote: > Hi - > >>From: Andy Bierman >>Sent: Feb 5, 2015 8:27 AM >>To: Ladislav Lhotka >>Cc: "netmod@ietf.org" >>Subject: Re: [netmod] yang-json document > ... >>>>> NEW >>>>> >>>>> Names with namespace identifiers in the form shown in Figure 1 MUST >>>>> be used for all top-level YANG data nodes, and also for all nodes >>>>> whose parent node belongs to a different namespace. Otherwise, names >>>>> with namespace identifiers SHOULD NOT be used. >>>> >> >>I think MUST violates the RFC 2119 rules (issue Randy already raised). >>If the receiver gets "interfaces" instead of "ietf-interfaces:interfaces", >>and there is only 1 possible match, then the receiver is forced to >>reject input that it understands. Even if there are multiple matches, >>the receiver may be able to detect which object is being sent. >> >>Of course, if there are multiple matches and the receiver cannot >>detect which one is sent, the input MUST be rejected. > > Before anyone reads too much into what I wrote let me be clear(er) > about my concern: > > If the constraint is not necessary to ensure interoperability, using > "MUST" is inappropriate. As I understand Andy's argument, receivers > "may be able" to disambiguate. I'm not convinced that that's sufficient > to ensure interoperability. Unless the behaviour is adequately specified > so that all conformant implementaions will resolve in the same way the > potential "multiple matches" Andy describes, it sounds like the "MUST" > really *is* appropriate. > The previous iteration of the rule was interoperable: If there are multiple matches of the local-name, the receiver MUST reject the input. Since almost all designers try to avoid local-name conflicts, the liklihood of any matches at all is still very low. > Randy Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 6 06:51:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FF51A1B0D for ; Fri, 6 Feb 2015 06:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 CNppFOxqLZIM for ; Fri, 6 Feb 2015 06:51:25 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BC01A1AD0 for ; Fri, 6 Feb 2015 06:51:25 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id 8AE5B13F7AF; Fri, 6 Feb 2015 15:51:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423234283; bh=1BilfyXhQDInBVs4NKO6K1M8FeM/sYxsApxuWXT/Jq8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DfaJd/NFEIGUPK1M3KJkV0YIdGcZalEbhLQ5wBApr7Inob/WQrNR9HuktRI7ETeZ1 suOjlLCzt5f4DRrxbrl4M0Eo3mG18qXDNd5L1vkJSan8zGo6Mb4supkoUHHHnKcFJH FqGWRI68EXBzm/JCJWyUqxWWyjkWilqitZ8XmVvA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150206.152223.1122646753947355607.mbj@tail-f.com> Date: Fri, 6 Feb 2015 15:51:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4C6103B9-901D-43ED-8868-97711E6253D8@nic.cz> References: <20150206.145738.1020979748838144472.mbj@tail-f.com> <20150206.152223.1122646753947355607.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 14:51:27 -0000 > On 06 Feb 2015, at 15:22, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 06 Feb 2015, at 14:57, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 06 Feb 2015, at 14:36, Juergen Schoenwaelder >>>>> wrote: >>>>>=20 >>>>> On Fri, Feb 06, 2015 at 01:18:52PM +0100, Ladislav Lhotka wrote: >>>>>>=20 >>>>>> The point really is that there needn't be any common rules for = all >>>>>> uses >>>>>> of anyxml, except that it has to be well-formed for the given >>>>>> encoding. >>>>>>=20 >>>>>=20 >>>>> Your interpretation that anyxml means any-encoding-specific-stuff = does >>>>> apparently not match everybody's reading of RFC 6020's definition = of >>>>> anyxml. >>>>=20 >>>> Well, 6020 only deals with XML encoding and the definition is = exactly >>>> what you said - any XML stuff: >>>>=20 >>>> The "anyxml" statement is used to represent an unknown chunk of = XML. >>>> No restrictions are placed on the XML. >>>>=20 >>>> I don=E2=80=99t know why JSON (or, for that matter, any other) = encoding should >>>> be any different. >>>=20 >>> Again we're going in circles. >>>=20 >>> Right now we have a problem: >>>=20 >>> 1. We want YANG PATCH to be interoperable. >>>=20 >>> 2. YANG PATCH uses anyxml. >>>=20 >>> 3. YANG PATCH supports json encoding as defined in the json draft. >>>=20 >>> 4. The json draft says that no encoding is defined for anyxml. >>=20 >> You probably mean the json draft defines no *mapping* for anyxml. >=20 > Ok, there is no mapping defined, but also, the *encoding* is not > clear: >=20 > An anyxml instance is encoded as a name/value pair. The value can > be of any valid JSON type >=20 > This means that in general, there is no interoperable way to encode > anyxml in json (and this I think is just fine). The description of =E2=80=9Canyxml value=E2=80=9D in yang-patch is = pretty strict about what the content can be and the JSON encoding is = then straightforward. The XML snippet in the description would become "yang-patch:value": { "example-foo:foo": { "a": "some value", =E2=80=9Cb": 42 } } Yes, it is possible that for certain use cases anyxml content will be = defined only for XML encoding, a json client may simply receive null = (and the description of that anyxml node should say so). >=20 >> This >> of course doesn=E2=80=99t prevent the YANG PATCH document from = defining >> specific rules and XML-JSON mapping for the contents of its anyxml >> nodes, perhaps exactly in the sense of anydata. >=20 > I don't think this proposal has come up before. I am lazy to search through the previous discussions but I've always = claimed that every anyxml should be considered specific. If it is = defined to carry configlets, the client cannot expect the server will = accept an arbitrary XML content instead. >=20 > Then the json document should probably say that any usage of anyxml > MAY define specific encoding and mapping rules. OK, this is possible, but I=E2=80=99d rather say Any usage of anyxml MAY define a specific syntactic, semantic and = mapping rules. Actually, 6020bis can say it as well. >=20 >> Why is this a problem? >=20 > Well, it probably works in one or two use cases, but it is not very > scalable=E2=80=A6 What do you mean by scalability? Every anyxml is a node with its own = name, namespace and description. It is up to the data model designer to = decide what makes sense. Lada >=20 >>> 5. Conclusion: (1) cannot be true. >>>=20 >>>=20 >>> So how do we solve this? >>>=20 >>> A. Wait for anydata, and define json encoding rules for anydata. >>>=20 >>> B. Remove support for json from YANG PATCH. >>=20 >> C. Define specific rules for anyxml appearing in YANG PATCH. >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 6 07:17:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891141A1B3A for ; Fri, 6 Feb 2015 07:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO3xWnaOIGjL for ; Fri, 6 Feb 2015 07:17:06 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DBA551A1B4B for ; Fri, 6 Feb 2015 07:16:18 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id CD38F12801A5; Fri, 6 Feb 2015 16:16:17 +0100 (CET) Date: Fri, 06 Feb 2015 16:16:17 +0100 (CET) Message-Id: <20150206.161617.84679755667740396.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <4C6103B9-901D-43ED-8868-97711E6253D8@nic.cz> References: <20150206.152223.1122646753947355607.mbj@tail-f.com> <4C6103B9-901D-43ED-8868-97711E6253D8@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / 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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:17:08 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDYgRmVi IDIwMTUsIGF0IDE1OjIyLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g DQo+ID4+PiBPbiAwNiBGZWIgMjAxNSwgYXQgMTQ6NTcsIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0 YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+IA0KPiA+Pj4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FA bmljLmN6PiB3cm90ZToNCj4gPj4gVGhpcw0KPiA+PiBvZiBjb3Vyc2UgZG9lc27igJl0IHByZXZl bnQgdGhlIFlBTkcgUEFUQ0ggZG9jdW1lbnQgZnJvbSBkZWZpbmluZw0KPiA+PiBzcGVjaWZpYyBy dWxlcyBhbmQgWE1MLUpTT04gbWFwcGluZyBmb3IgdGhlIGNvbnRlbnRzIG9mIGl0cyBhbnl4bWwN Cj4gPj4gbm9kZXMsIHBlcmhhcHMgZXhhY3RseSBpbiB0aGUgc2Vuc2Ugb2YgYW55ZGF0YS4NCj4g PiANCj4gPiBJIGRvbid0IHRoaW5rIHRoaXMgcHJvcG9zYWwgaGFzIGNvbWUgdXAgYmVmb3JlLg0K PiANCj4gSSBhbSBsYXp5IHRvIHNlYXJjaCB0aHJvdWdoIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9u cyBidXQgSSd2ZSBhbHdheXMNCj4gY2xhaW1lZCB0aGF0IGV2ZXJ5IGFueXhtbCBzaG91bGQgYmUg Y29uc2lkZXJlZCBzcGVjaWZpYy4gSWYgaXQgaXMNCj4gZGVmaW5lZCB0byBjYXJyeSBjb25maWds ZXRzLCB0aGUgY2xpZW50IGNhbm5vdCBleHBlY3QgdGhlIHNlcnZlciB3aWxsDQo+IGFjY2VwdCBh biBhcmJpdHJhcnkgWE1MIGNvbnRlbnQgaW5zdGVhZC4NCj4gDQo+ID4gDQo+ID4gVGhlbiB0aGUg anNvbiBkb2N1bWVudCBzaG91bGQgcHJvYmFibHkgc2F5IHRoYXQgYW55IHVzYWdlIG9mIGFueXht bA0KPiA+IE1BWSBkZWZpbmUgc3BlY2lmaWMgZW5jb2RpbmcgYW5kIG1hcHBpbmcgcnVsZXMuDQo+ IA0KPiBPSywgdGhpcyBpcyBwb3NzaWJsZSwgYnV0IEnigJlkIHJhdGhlciBzYXkNCj4gDQo+IEFu eSB1c2FnZSBvZiBhbnl4bWwgTUFZIGRlZmluZSBhIHNwZWNpZmljIHN5bnRhY3RpYywgc2VtYW50 aWMgYW5kDQo+IG1hcHBpbmcgcnVsZXMuDQo+IA0KPiBBY3R1YWxseSwgNjAyMGJpcyBjYW4gc2F5 IGl0IGFzIHdlbGwuDQo+IA0KPiA+IA0KPiA+PiBXaHkgaXMgdGhpcyBhIHByb2JsZW0/DQoNCkl0 IGJyZWFrcyBhbGwgYWJzdHJhY3Rpb25zIGlmIHRoZSBkYXRhIG1vZGVsIHN0YXJ0cyB0byB0YWxr IGFib3V0IGhvdw0Kbm9kZXMgYXJlIGVuY29kZWQgdG8gZGlmZmVyZW50IGZvcm1hdHMuDQoNCj4g PiBXZWxsLCBpdCBwcm9iYWJseSB3b3JrcyBpbiBvbmUgb3IgdHdvIHVzZSBjYXNlcywgYnV0IGl0 IGlzIG5vdCB2ZXJ5DQo+ID4gc2NhbGFibGXigKYNCj4gDQo+IFdoYXQgZG8geW91IG1lYW4gYnkg c2NhbGFiaWxpdHk/IEV2ZXJ5IGFueXhtbCBpcyBhIG5vZGUgd2l0aCBpdHMgb3duDQo+IG5hbWUs IG5hbWVzcGFjZSBhbmQgZGVzY3JpcHRpb24uIEl0IGlzIHVwIHRvIHRoZSBkYXRhIG1vZGVsIGRl c2lnbmVyDQo+IHRvIGRlY2lkZSB3aGF0IG1ha2VzIHNlbnNlLg0KDQpFdmVyeSBzdWNoIG5vZGUg d291bGQgcmVxdWlyZSBzcGVjaWFsIGNvZGUuICBUaGVyZSBpcyBubyB3YXkgaW4NCmdlbmVyYWwg Zm9yIHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgdG8gaW1wYWN0IHRoZSBlbmNvZGluZywgYnV0 IHRoaXMNCndvdWxkIGJlIG5lZWRlZCBpbiBvcmRlciB0byBzdXBwb3J0IHRoaXMgLSBvciB0aGUg YmFzZSBjb2RlIG5lZWRzIHRvDQpoYXZlIHNwZWNpYWwgaGFja3MgZm9yIGFsbCBzdWNoIG5vZGVz Lg0KDQoNCi9tYXJ0aW4NCg== From nobody Fri Feb 6 07:22:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3022E1A1B1C for ; Fri, 6 Feb 2015 07:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdgc79ytAzZK for ; Fri, 6 Feb 2015 07:22:44 -0800 (PST) Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (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 691E91A00FF for ; Fri, 6 Feb 2015 07:22:44 -0800 (PST) Received: by labms9 with SMTP id ms9so1790774lab.1 for ; Fri, 06 Feb 2015 07:22:43 -0800 (PST) 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:content-type :content-transfer-encoding; bh=5iEw5cGjveLyrUKEcEXfyINggZujVDWxZhttU7JiB5E=; b=Wus3OtauWtbhepRAC/Ani4Nf+OIIt9cZmCVzlve69Qy6L3v57DeD/pTQUEJDtd22Fw fgtK4E53KRDLg4ExrmXzQwaqnPDWbTtnYeXnXWjrN/EXvNrg6b9nqeSCXcsFabm1p5Fq fmy/L/uFD32ndcg4iIlsuRzkNO+zD/1ohGSAHaGPRi0ruTUhxQaOC2ReVjHjG3SgUDUc R5DX4vC/FmxkHK6c8oPqO9SLPte5BVx/VVTGqhqVSWumPU6If8Q8kewf0qgbrrxR8aLS OvEnU0UIz3uVcfYN4vPGvYfqxYPv2/UZvvvXsqBRUqN5VwNHid4c9fXGXi7M+n70aKZa 5ANg== X-Gm-Message-State: ALoCoQngSJNj6ZiYakv9UCiuOiNOfqC9sBUGSkfzMX4/f/U52AQtwGrHxQmgSY9I2GZHwaqF2/Bm MIME-Version: 1.0 X-Received: by 10.152.5.101 with SMTP id r5mr3321117lar.33.1423236162866; Fri, 06 Feb 2015 07:22:42 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 6 Feb 2015 07:22:42 -0800 (PST) In-Reply-To: <20150206.161617.84679755667740396.mbj@tail-f.com> References: <20150206.152223.1122646753947355607.mbj@tail-f.com> <4C6103B9-901D-43ED-8868-97711E6253D8@nic.cz> <20150206.161617.84679755667740396.mbj@tail-f.com> Date: Fri, 6 Feb 2015 07:22:42 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:22:48 -0000 On Fri, Feb 6, 2015 at 7:16 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> > On 06 Feb 2015, at 15:22, Martin Bjorklund wrote: >> > >> > Ladislav Lhotka wrote: >> >> >> >>> On 06 Feb 2015, at 14:57, Martin Bjorklund wrote: >> >>> >> >>> Ladislav Lhotka wrote: >> >> This >> >> of course doesn=E2=80=99t prevent the YANG PATCH document from defini= ng >> >> specific rules and XML-JSON mapping for the contents of its anyxml >> >> nodes, perhaps exactly in the sense of anydata. >> > >> > I don't think this proposal has come up before. >> >> I am lazy to search through the previous discussions but I've always >> claimed that every anyxml should be considered specific. If it is >> defined to carry configlets, the client cannot expect the server will >> accept an arbitrary XML content instead. >> >> > >> > Then the json document should probably say that any usage of anyxml >> > MAY define specific encoding and mapping rules. >> >> OK, this is possible, but I=E2=80=99d rather say >> >> Any usage of anyxml MAY define a specific syntactic, semantic and >> mapping rules. >> >> Actually, 6020bis can say it as well. >> >> > >> >> Why is this a problem? > > It breaks all abstractions if the data model starts to talk about how > nodes are encoded to different formats. > +1 >> > Well, it probably works in one or two use cases, but it is not very >> > scalable=E2=80=A6 >> >> What do you mean by scalability? Every anyxml is a node with its own >> name, namespace and description. It is up to the data model designer >> to decide what makes sense. > > Every such node would require special code. There is no way in > general for the application developer to impact the encoding, but this > would be needed in order to support this - or the base code needs to > have special hacks for all such nodes. > This is the description-stmt for the anyxml 'value' node in YANG Patch: description "Value used for this edit operation. The anyxml value MUST represent a container with exactly one child node, which MUST identify the target resource associated with the 'target' leaf. For example, suppose the target node is a YANG container named foo: container foo { leaf a { type string; } leaf b { type int32; } } The value node will contain one instance of foo: some value 42 "; IMO this is the best we can do with YANG 1.0 and even YANG 1.1. An implementation of this data model has rules to follow. The description-stmt is just as normative as the type-stmt. People seem to forget that. > > /martin Andy From nobody Fri Feb 6 07:37:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AB01A1B0D for ; Fri, 6 Feb 2015 07:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bne7BUfCxN71 for ; Fri, 6 Feb 2015 07:36:53 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46DF1A0084 for ; Fri, 6 Feb 2015 07:36:52 -0800 (PST) Received: from BY2PR05CA046.namprd05.prod.outlook.com (10.141.250.36) by BLUPR05MB436.namprd05.prod.outlook.com (10.141.27.152) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 15:36:51 +0000 Received: from BY2FFO11FD041.protection.gbl (2a01:111:f400:7c0c::126) by BY2PR05CA046.outlook.office365.com (2a01:111:e400:2c5f::36) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Fri, 6 Feb 2015 15:36:50 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD041.mail.protection.outlook.com (10.1.14.226) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 15:36:50 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 07:36:50 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16FanW73933; Fri, 6 Feb 2015 07:36:49 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16FaYcY063833; Fri, 6 Feb 2015 10:36:34 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061536.t16FaYcY063833@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Fri, 6 Feb 2015 10:36:34 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(62966003)(50466002)(76506005)(77156002)(92566002)(48376002)(53416004)(2950100001)(77096005)(47776003)(110136001)(106466001)(46102003)(50986999)(54356999)(105596002)(6806004)(86362001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB436; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB436; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 15:36:50.8794 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB436 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:36:58 -0000 Andy Bierman writes: >by real-world you mean your server actually supports this config? Our DDL lacks anyxml, so we encode this as a string. >It's OK with me if the optional JSON encoding is dropped. >If corner-cases like this are deemed to be so important, >then just use XML and forget about JSON. I don't know that we can forget about JSON. My suggestion is encoding anyxml data as strings in JSON. Seems simple enough. Thanks, Phil From nobody Fri Feb 6 07:41:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23511A1B93 for ; Fri, 6 Feb 2015 07:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLfq6h2e0Xfe for ; Fri, 6 Feb 2015 07:41:05 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 4539D1A1B86 for ; Fri, 6 Feb 2015 07:41:04 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id p9so18686882lbv.4 for ; Fri, 06 Feb 2015 07:41:02 -0800 (PST) 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:content-type; bh=LILT8VUTfOlzWLVGifaLFKptZw5W2ZEflMsFV1Ryf7g=; b=MNZ9PeDpzuCn30OwryqsDtH/op8z1G9hVmysNYqxarqAR5L7g+JOEKTiQJ1nNyhdvx 66xbUHzfp+NUTQxxodRGeLMvVW68F4A1fWgpDunNhsW6ioXewo/vL5fxeLg8mkkKQFl3 aYY4hbFTBUCSMizNsXPLFSCAkKvWbNGmeeuWHzDd5E7s3hgzj1IZ+iElcyCXoh4C0tde /Y8buGW5jRxzkPvA//dmZ12OvCmULrtBVu2KixtDWMMoIZa5wM2+nk/05EzC/m+1KLsy 9abaldxcdGT99UZm0fI7iFCylhznWZOsL4g7uRvLNlrDhy/WEh6McsQpKwP4BHaXIOPd /Wcg== X-Gm-Message-State: ALoCoQnxMu/J2uEqBtt7Luj0Igsfgb7TLhwbltVfpyXKRuxF2n8Dt/PjK7IQrV0YkQRulqlfaxFo MIME-Version: 1.0 X-Received: by 10.152.28.129 with SMTP id b1mr3328024lah.37.1423237262671; Fri, 06 Feb 2015 07:41:02 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 6 Feb 2015 07:41:02 -0800 (PST) In-Reply-To: <201502060448.t164mNSX059800@idle.juniper.net> References: <201502060448.t164mNSX059800@idle.juniper.net> Date: Fri, 6 Feb 2015 07:41:02 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:41:06 -0000 .... >>XML has simple nodes which are empty and those which are not empty. >> XML non-empty simple node <--> JSON string >> XML empty node <--> JSON null >> XML complex node <--> JSON object > > This is an extreme oversimplification. You are right. 2 more rules: - Multiple matching siblings or ordered-by user list or leaf-list MUST sent as a JSON array to preserve the order. - XML attributes MUST be preserved in case descendant-or-self nodes have QNames in the content (most common: identityref leaf) > Consider the real-world > case: Our internal data structures have nowhere to put text interspersed with the YANG nodes. The "web-banner" would be a leaf of type string, not anyxml. This is the correct way to have the server store arbitrary HTML. > Thanks, > Phil Andy From nobody Fri Feb 6 07:41:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400F61A1B91 for ; Fri, 6 Feb 2015 07:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIbbYsMlxzrS for ; Fri, 6 Feb 2015 07:41:35 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219AE1A1B87 for ; Fri, 6 Feb 2015 07:41:31 -0800 (PST) Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB329.namprd05.prod.outlook.com (10.141.69.25) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 15:41:28 +0000 Received: from BL2PR05CA0035.namprd05.prod.outlook.com (10.255.226.35) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 15:41:26 +0000 Received: from BN1AFFO11FD028.protection.gbl (2a01:111:f400:7c10::186) by BL2PR05CA0035.outlook.office365.com (2a01:111:e400:c04::35) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Fri, 6 Feb 2015 15:41:25 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1AFFO11FD028.mail.protection.outlook.com (10.58.52.88) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 15:41:25 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 07:41:24 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16FfKW75504; Fri, 6 Feb 2015 07:41:20 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16Ff5l2063882; Fri, 6 Feb 2015 10:41:06 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061541.t16Ff5l2063882@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Fri, 6 Feb 2015 10:41:05 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; tail-f.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(53416004)(105596002)(46102003)(106466001)(92566002)(2950100001)(86362001)(76506005)(47776003)(50986999)(48376002)(110136001)(50466002)(6806004)(87936001)(62966003)(77096005)(77156002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB443; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 15:41:25.3071 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB329; X-OriginatorOrg: juniper.net Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:41:36 -0000 Ladislav Lhotka writes: >Exactly! I think most, if not all, uses of anyxml and anydata will >assume some specific syntax and semantics (that needs to be explained in >the description). But this may also include a sensible, perhaps >non-trivial, way for mapping XML to JSON and back. And if there is no >sensible mapping, it is IMO also acceptable that certain uses of anyxml will >only be possible in XML encoding. If you are saying that JSON can't traffic my entire config, then RESTCONF can't be used for simple tasks like backup and restore, since they won't see the full config. I don't think that's reasonable. Thanks, Phil From nobody Fri Feb 6 07:45:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1B61A1B93 for ; Fri, 6 Feb 2015 07:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 RFy3tOdPKow2 for ; Fri, 6 Feb 2015 07:45:13 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630661A1B60 for ; Fri, 6 Feb 2015 07:45:13 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id ED69B13F7A0; Fri, 6 Feb 2015 16:45:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423237512; bh=smZM+NjjfhPVOgyXPJXE2yd2tn1tM/T8SF3mDSM5ysE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=F0B0ICn7fEjD2NmKtcbMs08r0f/9iEi1Uwc8HllQEHOYaVmV5S8cw2OUCpsJrM/OX ftEq80IYMc9B1r0CZPqEQXapTFygtkQfU7HDACkqqMBhDNEnyqjeumR94AtwJy2U5e nB0RRrOAON+OdvQrRJaB/sIoIOwuCtfJWVPhNHys= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 6 Feb 2015 16:45:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20874505.1423197343643.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> To: Andy Bierman X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:45:15 -0000 > On 06 Feb 2015, at 15:50, Andy Bierman wrote: >=20 > On Thu, Feb 5, 2015 at 8:35 PM, Randy Presuhn > wrote: >> Hi - >>=20 >>> From: Andy Bierman >>> Sent: Feb 5, 2015 8:27 AM >>> To: Ladislav Lhotka >>> Cc: "netmod@ietf.org" >>> Subject: Re: [netmod] yang-json document >> ... >>>>>> NEW >>>>>>=20 >>>>>> Names with namespace identifiers in the form shown in Figure 1 = MUST >>>>>> be used for all top-level YANG data nodes, and also for all = nodes >>>>>> whose parent node belongs to a different namespace. Otherwise, = names >>>>>> with namespace identifiers SHOULD NOT be used. >>>>>=20 >>>=20 >>> I think MUST violates the RFC 2119 rules (issue Randy already = raised). >>> If the receiver gets "interfaces" instead of = "ietf-interfaces:interfaces", >>> and there is only 1 possible match, then the receiver is forced to >>> reject input that it understands. Even if there are multiple = matches, >>> the receiver may be able to detect which object is being sent. >>>=20 >>> Of course, if there are multiple matches and the receiver cannot >>> detect which one is sent, the input MUST be rejected. >>=20 >> Before anyone reads too much into what I wrote let me be clear(er) >> about my concern: >>=20 >> If the constraint is not necessary to ensure interoperability, using >> "MUST" is inappropriate. As I understand Andy's argument, receivers >> "may be able" to disambiguate. I'm not convinced that that's = sufficient >> to ensure interoperability. Unless the behaviour is adequately = specified >> so that all conformant implementaions will resolve in the same way = the >> potential "multiple matches" Andy describes, it sounds like the = "MUST" >> really *is* appropriate. >>=20 >=20 >=20 > The previous iteration of the rule was interoperable: >=20 > If there are multiple matches of the local-name, the receiver MUST > reject the input. Yes, but Martin rightly pointed out that this encoding is not stable in = the sense that an augment from a new module may require adding an = explicit namespace prefix to old nodes. The current encoding rules fix = this because the parent of every node is fixed and cannot be changed. >=20 > Since almost all designers try to avoid local-name conflicts, the = liklihood > of any matches at all is still very low. We could then get rid of namespaces entirely. Lada >=20 >=20 >> Randy >=20 >=20 > Andy >=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 6 07:45:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27EA1A1BBC for ; Fri, 6 Feb 2015 07:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toxMnAn2Pnd3 for ; Fri, 6 Feb 2015 07:45:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC721A1B8A for ; Fri, 6 Feb 2015 07:45:19 -0800 (PST) Received: from BLUPR05CA0069.namprd05.prod.outlook.com (10.141.20.39) by BN1PR05MB439.namprd05.prod.outlook.com (10.141.58.22) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 15:44:57 +0000 Received: from BN1AFFO11FD047.protection.gbl (2a01:111:f400:7c10::194) by BLUPR05CA0069.outlook.office365.com (2a01:111:e400:855::39) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Fri, 6 Feb 2015 15:44:57 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1AFFO11FD047.mail.protection.outlook.com (10.58.53.62) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 15:44:57 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 07:44:56 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16FitW77691; Fri, 6 Feb 2015 07:44:55 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16FiedI063939; Fri, 6 Feb 2015 10:44:40 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061544.t16FiedI063939@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Fri, 6 Feb 2015 10:44:40 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(86362001)(62966003)(77156002)(6806004)(50466002)(77096005)(87936001)(2950100001)(50986999)(48376002)(19580395003)(76506005)(47776003)(92566002)(53416004)(46102003)(110136001)(54356999)(18206015028)(106466001)(105596002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB439; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB439; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB439; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB439; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 15:44:57.5064 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB439 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:45:22 -0000 Ladislav Lhotka writes: >> What does the JSON for this look like? I think the only viable >> answer is: >> >> "web-banner": "

This is very sensitive data

\n> src="mister-yuk.png"/>\n

I'm serious, dude

\n" > >I don't think so, the following is IMO a much better option: > > "web-banner": > "This is *very sensitive* data. > > ![](mister-yuk.png) > > I'm serious, dude" > >To be able to do this, it should be sufficient that the description of >the "web-banner" anyxml node states that HTML has to be used in XML >encoding and markdown in JSON. Are you saying that YANG should not support HTML, only markdown? Aren't we trying to support more flexibility than that in our data? Thanks, Phil From nobody Fri Feb 6 07:55:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074851A1BC3 for ; Fri, 6 Feb 2015 07:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvSgOlBaJtG2 for ; Fri, 6 Feb 2015 07:55:10 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C5A1A1EE9 for ; Fri, 6 Feb 2015 07:55:08 -0800 (PST) Received: from BLUPR05CA0060.namprd05.prod.outlook.com (10.141.20.30) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 15:55:07 +0000 Received: from BN1BFFO11FD007.protection.gbl (2a01:111:f400:7c10::1:134) by BLUPR05CA0060.outlook.office365.com (2a01:111:e400:855::30) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Fri, 6 Feb 2015 15:55:06 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD007.mail.protection.outlook.com (10.58.144.70) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 15:55:06 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 07:55:05 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16Ft4W81034; Fri, 6 Feb 2015 07:55:04 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16FsnwS064052; Fri, 6 Feb 2015 10:54:49 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061554.t16FsnwS064052@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Fri, 6 Feb 2015 10:54:49 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2950100001)(76506005)(106466001)(53416004)(105596002)(46102003)(47776003)(110136001)(92566002)(50466002)(77156002)(6806004)(86362001)(62966003)(48376002)(54356999)(87936001)(50986999)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB444; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 15:55:06.3482 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB444 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:55:12 -0000 Ladislav Lhotka writes: >Well, 6020 only deals with XML encoding and the definition is exactly what you said - an >y XML stuff: > The "anyxml" statement is used to represent an unknown chunk of XML. > No restrictions are placed on the XML. >I don't know why JSON (or, for that matter, any other) encoding should be any different. I think you're missing something here. "anyxml banner" means that in my datastore, "banner" is (conceptualy) an arbitrary chunk of XML. When you fetch that via traditional NETCONF, that chunk of XML is copied into the data stream when/as needed. Incoming values for banner are stuffed into the database. For this to work via JSON, the same abilities need to exist. I need to put my arbitrary chunk of XML out of my database and insert it into my JSON data stream. When a value for banner arrives, I need to insert it into my database. JSON is just a means of encoding that data. Use of JSON doesn't invent the right to redefine that data, or to say that I should have been markdown, not HTML, or to say that the JSON encoding just won't work for banner. I continue to think that JSON needs to encode anyxml as strings. I can't see anything else working here. For that matter, I'm still not seeing way "anydata" isn't just "type string". If you wanted anyjson, XML would need to encode that data as a string. Then again, anydata and anyjson are new features, so we shouldn't go there. Thanks, Phil From nobody Fri Feb 6 07:56:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F04E1A1EE9 for ; Fri, 6 Feb 2015 07:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMOS8b-mP6C7 for ; Fri, 6 Feb 2015 07:56:12 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D0361A1B8C for ; Fri, 6 Feb 2015 07:56:12 -0800 (PST) Received: from BY2PR05CA033.namprd05.prod.outlook.com (10.141.250.23) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 15:56:10 +0000 Received: from BN1BFFO11FD035.protection.gbl (2a01:111:f400:7c10::1:157) by BY2PR05CA033.outlook.office365.com (2a01:111:e400:2c5f::23) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Fri, 6 Feb 2015 15:56:10 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD035.mail.protection.outlook.com (10.58.144.98) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 15:56:09 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 07:56:08 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16Fu7W81551; Fri, 6 Feb 2015 07:56:07 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16Ftrn7064097; Fri, 6 Feb 2015 10:55:53 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061555.t16Ftrn7064097@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20150206135442.GA92163@elstar.local> Date: Fri, 6 Feb 2015 10:55:53 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2950100001)(76506005)(106466001)(53416004)(105596002)(46102003)(47776003)(110136001)(92566002)(50466002)(77156002)(6806004)(86362001)(62966003)(48376002)(54356999)(87936001)(50986999)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB444; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 15:56:09.5848 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB444 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:56:13 -0000 Juergen Schoenwaelder writes: >RFC 6020 very clearly defines what anyxml is. With YANG 1.1, we are >likely 'deprecating' anyxml and adding anydata, which is any data that >can be modeled with YANG. This, however, does not mean that anyxml >suddenly changes its meaning. And so far, the JSON mapping is based on >YANG 1.0, that is RFC 6020, where anyxml means any xml. What's the logic/motivation in deprecating anyxml? Thanks, Phil From nobody Fri Feb 6 07:58:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654A71A1EF7 for ; Fri, 6 Feb 2015 07:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 btX7n384bZ1h for ; Fri, 6 Feb 2015 07:58:24 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF6C1A1F01 for ; Fri, 6 Feb 2015 07:58:23 -0800 (PST) Received: from [172.20.6.143] (unknown [172.20.6.143]) by mail.nic.cz (Postfix) with ESMTPSA id 6278713F653; Fri, 6 Feb 2015 16:58:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423238301; bh=mf5U+Al5trNf1uTIVeSRd7FUOjJYCGQzCKMN9QSeKX8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NAhI6QzK1s9uvw/XnGzzBZmsG5wwxUgkbVJBxiPYQh+NusXjNGsdDI6B/zxZxc1ch CmVwSKuu3162b2cr/AF2UbO0Mm/4eoH4o/CN4IW//ew7gUh/PoXc2GoSEOJ9cH8+aj /xE8I8E4S9lc7Fbu5HF1cAKUSIps0a1l1Uz8q2iI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150206.161617.84679755667740396.mbj@tail-f.com> Date: Fri, 6 Feb 2015 16:58:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150206.152223.1122646753947355607.mbj@tail-f.com> <4C6103B9-901D-43ED-8868-97711E6253D8@nic.cz> <20150206.161617.84679755667740396.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 15:58:25 -0000 > On 06 Feb 2015, at 16:16, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 06 Feb 2015, at 15:22, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 06 Feb 2015, at 14:57, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>> This >>>> of course doesn=E2=80=99t prevent the YANG PATCH document from = defining >>>> specific rules and XML-JSON mapping for the contents of its anyxml >>>> nodes, perhaps exactly in the sense of anydata. >>>=20 >>> I don't think this proposal has come up before. >>=20 >> I am lazy to search through the previous discussions but I've always >> claimed that every anyxml should be considered specific. If it is >> defined to carry configlets, the client cannot expect the server will >> accept an arbitrary XML content instead. >>=20 >>>=20 >>> Then the json document should probably say that any usage of anyxml >>> MAY define specific encoding and mapping rules. >>=20 >> OK, this is possible, but I=E2=80=99d rather say >>=20 >> Any usage of anyxml MAY define a specific syntactic, semantic and >> mapping rules. >>=20 >> Actually, 6020bis can say it as well. >>=20 >>>=20 >>>> Why is this a problem? >=20 > It breaks all abstractions if the data model starts to talk about how > nodes are encoded to different formats. Well, talking about abstractions in connection to anyxml doesn=E2=80=99t = make much sense to me. In my view, anyxml is just a backdoor that allows = to piggyback some content that, for some reason, cannot be made part of = a regular model. The position of anydata can be different but until we = have it I think the best option is to accept that every anyxml is = special. >=20 >>> Well, it probably works in one or two use cases, but it is not very >>> scalable=E2=80=A6 >>=20 >> What do you mean by scalability? Every anyxml is a node with its own >> name, namespace and description. It is up to the data model designer >> to decide what makes sense. >=20 > Every such node would require special code. There is no way in Yes, YANG PATCH requires special code, configlets require special code = etc. Lada > general for the application developer to impact the encoding, but this > would be needed in order to support this - or the base code needs to > have special hacks for all such nodes. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 6 08:00:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447DF1A1BDA for ; Fri, 6 Feb 2015 08:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGbuj95hfO36 for ; Fri, 6 Feb 2015 08:00:28 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 CEC131A1F1D for ; Fri, 6 Feb 2015 08:00:27 -0800 (PST) Received: by labge10 with SMTP id ge10so2017048lab.12 for ; Fri, 06 Feb 2015 08:00:26 -0800 (PST) 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:content-type :content-transfer-encoding; bh=R99EYY9FVzXf9OusxZ1PTmhUfc+52j2cxlsOKUJcMQo=; b=BWz6BvO/icPzIWBpc4p+pea8VoVbuq9ygCo0ti3UsjHMZCPMUZLz9FBlgj3BEGAXLP JjvAZ2xcMQY9TfE7iNuCExWwFVp4gw+9rkfKaOxjqNErYlF8C6lqkSxLhNcPbNXEl1W6 VvjFEowI31RjCS9krYglzwaEUloUjyapOxdnLJeo/dDN6gV4uuYKeGrl5L4qufD6IVZQ KXBmB2RFNahLBFRjMALt0ZMMQ8oYQyZ3VAWsxi/JhwAWJxJNR6fwdK10oLCnOP3csXEo T7VLY+KYgiaq9A9oqRWZi4PKkTDwhIzTZznSuAAivcrpWNfhtKEqUv6JGJZPDfJgfL4o C/eA== X-Gm-Message-State: ALoCoQl8I3cW2JMauENBtOCF7TLCzuKCNyrTSlw+h2klDxFJCqvLWxWLa+vdY715ZQTO9JWBqNKs MIME-Version: 1.0 X-Received: by 10.152.5.101 with SMTP id r5mr3548960lar.33.1423238426291; Fri, 06 Feb 2015 08:00:26 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 6 Feb 2015 08:00:26 -0800 (PST) In-Reply-To: References: <20874505.1423197343643.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Fri, 6 Feb 2015 08:00:26 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Randy Presuhn , "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:00:30 -0000 On Fri, Feb 6, 2015 at 7:45 AM, Ladislav Lhotka wrote: > >> On 06 Feb 2015, at 15:50, Andy Bierman wrote: >> >> On Thu, Feb 5, 2015 at 8:35 PM, Randy Presuhn >> wrote: >>> Hi - >>> >>>> From: Andy Bierman >>>> Sent: Feb 5, 2015 8:27 AM >>>> To: Ladislav Lhotka >>>> Cc: "netmod@ietf.org" >>>> Subject: Re: [netmod] yang-json document >>> ... >>>>>>> NEW >>>>>>> >>>>>>> Names with namespace identifiers in the form shown in Figure 1 MUS= T >>>>>>> be used for all top-level YANG data nodes, and also for all nodes >>>>>>> whose parent node belongs to a different namespace. Otherwise, na= mes >>>>>>> with namespace identifiers SHOULD NOT be used. >>>>>> >>>> >>>> I think MUST violates the RFC 2119 rules (issue Randy already raised). >>>> If the receiver gets "interfaces" instead of "ietf-interfaces:interfac= es", >>>> and there is only 1 possible match, then the receiver is forced to >>>> reject input that it understands. Even if there are multiple matches, >>>> the receiver may be able to detect which object is being sent. >>>> >>>> Of course, if there are multiple matches and the receiver cannot >>>> detect which one is sent, the input MUST be rejected. >>> >>> Before anyone reads too much into what I wrote let me be clear(er) >>> about my concern: >>> >>> If the constraint is not necessary to ensure interoperability, using >>> "MUST" is inappropriate. As I understand Andy's argument, receivers >>> "may be able" to disambiguate. I'm not convinced that that's sufficien= t >>> to ensure interoperability. Unless the behaviour is adequately specifi= ed >>> so that all conformant implementaions will resolve in the same way the >>> potential "multiple matches" Andy describes, it sounds like the "MUST" >>> really *is* appropriate. >>> >> >> >> The previous iteration of the rule was interoperable: >> >> If there are multiple matches of the local-name, the receiver MUST >> reject the input. > > Yes, but Martin rightly pointed out that this encoding is not stable in t= he sense that an augment from a new module may require adding an explicit n= amespace prefix to old nodes. The current encoding rules fix this because t= he parent of every node is fixed and cannot be changed. > Actually, it is impossible in YANG to augment another namespace with a top-level data node. For descendant nodes in the same module, the prefix will not be provided. For descendant nodes in a different module, the prefix will be provided. There is the possibility that a future release of the server will add a mod= ule that has a top-level data node with the same local-name. In this case, the old client will break. I have not seen any vendors want to do this. IMO, SHOULD use the top-level prefix is appropriate, not MUST. >> >> Since almost all designers try to avoid local-name conflicts, the liklih= ood >> of any matches at all is still very low. > > We could then get rid of namespaces entirely. > > Lada > Andy >> >> >>> Randy >> >> >> Andy >> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Feb 6 08:01:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673EA1A1E0F for ; Fri, 6 Feb 2015 08:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U71_lx9x91LQ for ; Fri, 6 Feb 2015 08:01:27 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3271A1B60 for ; Fri, 6 Feb 2015 08:01:24 -0800 (PST) Received: from CO2PR05CA041.namprd05.prod.outlook.com (10.141.241.169) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 16:01:21 +0000 Received: from BL2FFO11FD053.protection.gbl (2a01:111:f400:7c09::188) by CO2PR05CA041.outlook.office365.com (2a01:111:e400:1429::41) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Fri, 6 Feb 2015 16:01:20 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 16:01:20 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 08:01:18 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16G1HW85448; Fri, 6 Feb 2015 08:01:17 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16G13V4064167; Fri, 6 Feb 2015 11:01:03 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061601.t16G13V4064167@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <4C6103B9-901D-43ED-8868-97711E6253D8@nic.cz> Date: Fri, 6 Feb 2015 11:01:03 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(76506005)(50986999)(6806004)(77096005)(86362001)(2950100001)(50466002)(48376002)(47776003)(87936001)(54356999)(92566002)(110136001)(106466001)(105596002)(77156002)(62966003)(46102003)(53416004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB440; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 16:01:20.1953 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:01:39 -0000 Ladislav Lhotka writes: >I am lazy to search through the previous discussions but I've always claimed that every >anyxml should be considered specific. If it is defined to carry configlets, the client c >annot expect the server will accept an arbitrary XML content instead. If every anyxml requires special encoding rules, then are we removing the ability to generically process yang data? Thanks, Phil From nobody Fri Feb 6 08:04:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847411A3BA4 for ; Fri, 6 Feb 2015 08:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 vdqLbLCAXquw for ; Fri, 6 Feb 2015 08:04:09 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1881A3B9C for ; Fri, 6 Feb 2015 08:04:07 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id 577B513F7A0; Fri, 6 Feb 2015 17:04:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423238643; bh=3D/yP6IiBkifiby+CVzC8NJDmQRIEhO6BZo6dWHaoOo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TL5IZBy1v2UT5U2IVS9Mg1YM1ZA3C+tdr8fBRzzBm5zwdcX387cejweHcn6FBTx18 mFqyEfCAh8lziJLFPQ2j4nI0SgyzjtkOLOuQycHFT7ocOO20QfCaN9dIxaWZ1iXo8A phN93XFMgA+D6fK9RhG7ReWUJJw1RF7zYKf8C34M= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <201502061544.t16FiedI063939@idle.juniper.net> Date: Fri, 6 Feb 2015 17:04:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201502061544.t16FiedI063939@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:04:10 -0000 > On 06 Feb 2015, at 16:44, Phil Shafer wrote: >=20 > Ladislav Lhotka writes: >>> What does the JSON for this look like? I think the only viable >>> answer is: >>>=20 >>> "web-banner": "

This is very sensitive data

\n>> src=3D"mister-yuk.png"/>\n

I'm serious, dude

\n" >>=20 >> I don't think so, the following is IMO a much better option: >>=20 >> "web-banner": >> "This is *very sensitive* data. >>=20 >> ![](mister-yuk.png) >>=20 >> I'm serious, dude" >>=20 >> To be able to do this, it should be sufficient that the description = of >> the "web-banner" anyxml node states that HTML has to be used in XML >> encoding and markdown in JSON. >=20 > Are you saying that YANG should not support HTML, only markdown? YANG as such supports neither HTML nor markdown but a given anyxml node = could support both. Lada=20 > Aren't we trying to support more flexibility than that in our data? >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 6 08:07:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC69C1A6EE7 for ; Fri, 6 Feb 2015 08:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 K4LoJjv0p2rW for ; Fri, 6 Feb 2015 08:07:33 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F7B1A6EE1 for ; Fri, 6 Feb 2015 08:07:33 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:11]) by mail.nic.cz (Postfix) with ESMTPSA id 476D913F7A0; Fri, 6 Feb 2015 17:07:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423238851; bh=x4yD2EHejmtCVXbaD0tlraY4uqHsYILTaRKb4sHEbfQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=C43Bq+TrcMfJ946nVErt2BjZf9h49wv4gjzVrHvIyG9m/386HB/NqDF6l0bajVyhO OgLMQzn1yHYF5Xk1vMIYNxRqmUeUORfFUgIz9VDB1v2uUzZ3G9GzeB9xlFjs+TE/Nq DdHIeom9mdcgcQoVFTO7ITpElDsgAh9q3LtZy2Mo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <201502061541.t16Ff5l2063882@idle.juniper.net> Date: Fri, 6 Feb 2015 17:07:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <84C2F7B7-0701-44DB-84FB-FD2854AD161B@nic.cz> References: <201502061541.t16Ff5l2063882@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:07:38 -0000 > On 06 Feb 2015, at 16:41, Phil Shafer wrote: >=20 > Ladislav Lhotka writes: >> Exactly! I think most, if not all, uses of anyxml and anydata will >> assume some specific syntax and semantics (that needs to be explained = in >> the description). But this may also include a sensible, perhaps >> non-trivial, way for mapping XML to JSON and back. And if there is no >> sensible mapping, it is IMO also acceptable that certain uses of = anyxml will >> only be possible in XML encoding. >=20 > If you are saying that JSON can't traffic my entire config, then > RESTCONF can't be used for simple tasks like backup and restore, > since they won't see the full config. I don't think that's = reasonable. Most use cases for anyxml I am aware of are actually not in config. If = you want to have an anyxml node in config, you should probably make sure = a mapping exists in both ways. This is however still much easier than = defining a universal mapping. Lada >=20 > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 6 08:08:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE541A6F0B for ; Fri, 6 Feb 2015 08:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0vadzr0y130 for ; Fri, 6 Feb 2015 08:08:13 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0111.outbound.protection.outlook.com [207.46.100.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 9092D1A6EF3 for ; Fri, 6 Feb 2015 08:08:13 -0800 (PST) Received: from BL2PR05CA0042.namprd05.prod.outlook.com (10.255.226.42) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 16:08:11 +0000 Received: from BN1BFFO11OLC003.protection.gbl (2a01:111:f400:7c10::1:112) by BL2PR05CA0042.outlook.office365.com (2a01:111:e400:c04::42) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Fri, 6 Feb 2015 16:08:11 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11OLC003.mail.protection.outlook.com (10.58.145.14) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 16:08:11 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 08:08:10 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16G89W88717; Fri, 6 Feb 2015 08:08:09 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16G7sOG064307; Fri, 6 Feb 2015 11:07:55 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061607.t16G7sOG064307@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Fri, 6 Feb 2015 11:07:54 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(50986999)(48376002)(50466002)(46102003)(77096005)(54356999)(2950100001)(77156002)(62966003)(106466001)(6806004)(110136001)(76506005)(53416004)(86362001)(47776003)(92566002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:None; MLV:sfv; LANG:en; Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB435; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 16:08:11.6263 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB435 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:08:16 -0000 Andy Bierman writes: >.... >>>XML has simple nodes which are empty and those which are not empty. >>> XML non-empty simple node <--> JSON string >>> XML empty node <--> JSON null >>> XML complex node <--> JSON object >> >> This is an extreme oversimplification. > >You are right. 2 more rules: > > - Multiple matching siblings or ordered-by user list or leaf-list MUST > sent as a JSON array to preserve the order. > - XML attributes MUST be preserved in case descendant-or-self nodes > have QNames in the content (most common: identityref leaf) Still too simple, since XML can have matching siblings interleaved with other nodes. >Our internal data structures have nowhere to put text interspersed >with the YANG nodes. Then you'd need to carry anyxml content as strings within your database. >The "web-banner" would be a leaf of type >string, not anyxml. This is the correct way to have the server store >arbitrary HTML. Your ability to dictate "the correct way" to the modeler is not always guaranteed. ;^) Thanks, Phil From nobody Fri Feb 6 08:10:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8281A3BA6 for ; Fri, 6 Feb 2015 08:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaulM5kbFD4e for ; Fri, 6 Feb 2015 08:10:38 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (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 88C5B1A1F1D for ; Fri, 6 Feb 2015 08:10:37 -0800 (PST) Received: by labgf13 with SMTP id gf13so2103526lab.3 for ; Fri, 06 Feb 2015 08:10:36 -0800 (PST) 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:content-type; bh=diBBqr/S0OrtdDfuIdIT73MG+VYIZ7lDjDEpod/xZJY=; b=dDFTDlRw29fGV2sdHeH4XCyk4EATS2molhav0anj4w4M/2lpTKQze2AD9VMlANA6u7 +ykwmE6cA3ARTfxIEs9y+AlqZXfrma9SdcFOnTvF9TTHcvy6Wy+QAHCcjPAjHLdE9tPl 0fSiuJVGDfY+lG86cIv3gCI5f5y04esG3O/1NY0ip2kn81LTHP6t6PI5WB6V2W+vS8Jz xbLIxmgmPKBsdHpTY2G1LQ20Q2/w0Pxe+QBhO9bJ9utKrvn6xkFYTdggZxQSDUB/YFfO h/Y0CmZxOsLu7zUWhn2h+c/nUMMDN97sWYw1ITOqY/0e2Z5P69zlq8gTs+cG9+S4g2Ax SvFA== X-Gm-Message-State: ALoCoQkXzfvvSbD9pm3/+bAc01Ijlp/ljxA9Ds9N6G+/lhDh4q64wrBTtcaVS4G3Grcf0Je7cVpU MIME-Version: 1.0 X-Received: by 10.152.22.39 with SMTP id a7mr3508353laf.119.1423239036091; Fri, 06 Feb 2015 08:10:36 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 6 Feb 2015 08:10:35 -0800 (PST) In-Reply-To: <201502061601.t16G13V4064167@idle.juniper.net> References: <4C6103B9-901D-43ED-8868-97711E6253D8@nic.cz> <201502061601.t16G13V4064167@idle.juniper.net> Date: Fri, 6 Feb 2015 08:10:35 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:10:44 -0000 On Fri, Feb 6, 2015 at 8:01 AM, Phil Shafer wrote: > Ladislav Lhotka writes: >>I am lazy to search through the previous discussions but I've always claimed that every >>anyxml should be considered specific. If it is defined to carry configlets, the client c >>annot expect the server will accept an arbitrary XML content instead. > > If every anyxml requires special encoding rules, then are we removing > the ability to generically process yang data? > This reminds me of the SNMP debates about optimizing for generic tools like a MIB walker, or data-model-aware tools like an NMS. IMO your web-banner example is invalid because a string leaf is the proper YANG data model design, not anyxml. What do we expect tools to be able to do with anyxml if they do not understand/implement the data model containing the anyxml object? IMO, just display it, and JSON is readable enough whether the string is "42" instead of 42. > Thanks, > Phil > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 6 09:01:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993B41A00E2; Fri, 6 Feb 2015 09:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1HyKsep2aQY; Fri, 6 Feb 2015 09:00:55 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D957A1A6F2A; Fri, 6 Feb 2015 09:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1755; q=dns/txt; s=iport; t=1423242055; x=1424451655; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bAg8i7Q7+BrwrF8W/61vmw888dvYw2o1B79eX9uqiic=; b=Uvv9JFGdoKxQ4Eek/dQZGo38DnaBB/WUTXAc62bMIot2bi43CyNt1yyh VmyRsMCN1OTEz936xm/CO8f0mXtUqimzijIBdzg7gGyVS2vRagwqUAc1T aXpMmHkCTBVEPg08XRLw+Bwfa3lfQOGRLRvy5byn9k1HUQGTEhd3mpOtX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQFAPfy1FStJA2G/2dsb2JhbABagwZSVQUEwlQKhSdKAoEZQwEBAQEBfYQOAQQBAQE3NAsSAT43CyUCBAENBQmIJAgF1XcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj3gHhCkFjxqDUIVcgRc2gk2OUiKDbm+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,530,1418083200"; d="scan'208";a="394416949" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 06 Feb 2015 17:00:54 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t16H0smM028077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 17:00:54 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.150]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 11:00:53 -0600 From: "Lisa Huang (yihuan)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: draft-ietf-netmod-acl-model-01.txt Thread-Index: AQHQQi53Hb86lLgn0kiS6vhSXjaibA== Date: Fri, 6 Feb 2015 17:01:04 +0000 Message-ID: In-Reply-To: <20150206143614.32589.84386.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.154.204.32] Content-Type: text/plain; charset="us-ascii" Content-ID: <304A4E43EAD12A428E663E90F27E9C30@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 17:01:05 -0000 Hello Netmod Working Group, We have posted a new draft for Network Access Control List (ACL) YANG Data Model. The new version included examples to clarify port range usage. Please let us know if you have any comments. Thanks, Lisa On 2/6/15, 6:36 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the NETCONF Data Modeling Language Working >Group of the IETF. > > Title : Network Access Control List (ACL) YANG Data >Model > Authors : Dean Bogdanovic > Kiran Agrahara Sreenivasa > Lisa Huang > Dana Blair > Filename : draft-ietf-netmod-acl-model-01.txt > Pages : 24 > Date : 2015-02-05 > >Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netmod-acl-model-01 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-01 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 6 10:51:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E391A0469 for ; Fri, 6 Feb 2015 10:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os2srXXmpHhN for ; Fri, 6 Feb 2015 10:51:09 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA2B01A1A3B for ; Fri, 6 Feb 2015 10:51:08 -0800 (PST) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 18:50:45 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) with mapi id 15.01.0075.002; Fri, 6 Feb 2015 18:50:45 +0000 From: Dean Bogdanovic To: Juergen Schoenwaelder , "Thomas Nadeau" Thread-Topic: Ask for WGLC draft-ietf-netmod-acl-model-01.txt Thread-Index: AQHQQj3QKDLWeKd5s0SZ+JV3WylkLg== Date: Fri, 6 Feb 2015 18:50:44 +0000 Message-ID: <5A4D9237-B13D-4563-AAA3-A63A17139BE0@juniper.net> References: <20150206143614.32589.84386.idtracker@ietfa.amsl.com> In-Reply-To: <20150206143614.32589.84386.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(24454002)(51704005)(377454003)(230783001)(46102003)(122556002)(82746002)(57306001)(92566002)(19580395003)(33656002)(86362001)(40100003)(50226001)(50986999)(83716003)(19580405001)(102836002)(99286002)(1720100001)(229853001)(36756003)(2950100001)(76176999)(66066001)(106116001)(77156002)(62966003)(2900100001)(87936001)(2656002)(15975445007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <19A30BF9C7F2EC4B80E0CD08F6B1709F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2015 18:50:44.9763 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB423 Archived-At: Cc: "netmod@ietf.org" Subject: [netmod] Ask for WGLC draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 18:51:15 -0000 Chairs, Can you please make the WGLC for this draft? We believe it is ready for the= final review by the group Lisa, Kiran, Dana and Dean On Feb 6, 2015, at 9:36 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the NETCONF Data Modeling Language Working G= roup of the IETF. >=20 > Title : Network Access Control List (ACL) YANG Data Mode= l > Authors : Dean Bogdanovic > Kiran Agrahara Sreenivasa > Lisa Huang > Dana Blair > Filename : draft-ietf-netmod-acl-model-01.txt > Pages : 24 > Date : 2015-02-05 >=20 > Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-acl-model-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 6 10:59:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58361A877C for ; Fri, 6 Feb 2015 10:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Q7hfzV9bgCWT for ; Fri, 6 Feb 2015 10:59:32 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 471AE1A8762 for ; Fri, 6 Feb 2015 10:59:25 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id A7B762DEDADD for ; Fri, 6 Feb 2015 13:59:24 -0500 (EST) From: "Thomas D. Nadeau" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9307E060-237C-4AF7-B281-92E2B886F0F9@lucidvision.com> Date: Fri, 6 Feb 2015 13:59:24 -0500 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [netmod] IPR Poll for draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 18:59:33 -0000 Netmod WG: This mail starts the IPR poll on = draft-ietf-netmod-acl-model-01.txt. Are you aware of any IPR that applies to = draft-ietf-netmod-snmp-cfg-04? If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please = respond to this email explicitly regardless of whether or not you are aware of any = relevant IPR. *The response needs to be sent to the NETMOD wg mailing list.* The = document will not advance to the next stage until a response has been received = from *each author and contributor*. If you are on the NETMOD WG email list but are not listed as an = author or contributor, then please explicitly respond only if you are aware of any = IPR that has not yet been disclosed in conformance with IETF rules. Thank you, Tom and Juergen, NETMOD WG Chairs= From nobody Fri Feb 6 10:59:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F24D1A1A1D for ; Fri, 6 Feb 2015 10:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 9TrS_ds43imF for ; Fri, 6 Feb 2015 10:59:37 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id BEC4B1A876B for ; Fri, 6 Feb 2015 10:59:30 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 33E2C2DEDADE for ; Fri, 6 Feb 2015 13:59:30 -0500 (EST) From: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary="Apple-Mail=_73F023CE-6A07-477A-8F2B-38B7941810D1" Message-Id: <7C52DD5B-33F7-44D1-A701-90254AAD7C12@lucidvision.com> Date: Fri, 6 Feb 2015 13:59:30 -0500 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 18:59:38 -0000 --Apple-Mail=_73F023CE-6A07-477A-8F2B-38B7941810D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This commences a NETMOD WG Last call for = draft-ietf-netmod-acl-model-01.txt. Please send comments to the list by = 20-FEB-2015 by 9AM EST. Tom and Juergen, NETMOD WG Chairs --Apple-Mail=_73F023CE-6A07-477A-8F2B-38B7941810D1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

This commences a NETMOD WG Last call for draft-ietf-netmod-acl-model-01.txt.  Please send comments to the list by 20-FEB-2015 by 9AM EST.

Tom and Juergen, NETMOD WG Chairs




--Apple-Mail=_73F023CE-6A07-477A-8F2B-38B7941810D1-- From nobody Fri Feb 6 11:10:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63731A1A59 for ; Fri, 6 Feb 2015 11:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5H0_2cewX1K for ; Fri, 6 Feb 2015 11:10:05 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD661A877E for ; Fri, 6 Feb 2015 11:09:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dTnyzb46qHRZdoHNH60/Q2l+gqEQlRh4TC2QTMafKUpHtaDPwane2AK8IBZxdyMG; 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.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YJoHq-0006Vw-2a for netmod@ietf.org; Fri, 06 Feb 2015 14:09:54 -0500 Received: from 76.254.48.152 by webmail.earthlink.net with HTTP; Fri, 6 Feb 2015 14:09:53 -0500 Message-ID: <3195354.1423249793989.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Fri, 6 Feb 2015 11:09:53 -0800 (GMT-08: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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537666be2be609a0c0899589fa42c55214c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.26 Archived-At: Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 06 Feb 2015 19:10:14 -0000 Hi - >From: Andy Bierman >Sent: Feb 6, 2015 8:00 AM >To: Ladislav Lhotka >Cc: Randy Presuhn , "netmod@ietf.org" >Subject: Re: [netmod] yang-json document ... >There is the possibility that a future release of the server will add a module >that has a top-level data node with the same local-name. In this case, >the old client will break. I have not seen any vendors want to do this. > >IMO, SHOULD use the top-level prefix is appropriate, not MUST. Actually, the case you just described convincingly makes the case for "MUST" by demonstrating how a permitted (if unwise) deployment / implementation decision would lead to a non-interoperable (rather than merely inefficient) situation. Randy From nobody Fri Feb 6 11:24:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC2E1A1A40 for ; Fri, 6 Feb 2015 11:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsoAVUGRUbY1 for ; Fri, 6 Feb 2015 11:24:43 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 3D7131A0369 for ; Fri, 6 Feb 2015 11:24:43 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id b6so19825817lbj.11 for ; Fri, 06 Feb 2015 11:24:41 -0800 (PST) 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:content-type; bh=rUy4Kt0jjMYJSZVfvwg+OGV72Szn4anWfd6WYjwLOIw=; b=J3bvO2Y4IRb/rduCEhZLOiOHiY/l9wRtnArQsC4wLIxC6eimCBi8EHYKUPR8FwAqrb nCWPV78fYGzeHhrMlXqF1kgL9YV9mqE7OMC4GuTkEQ7oexGNvb1eFzkIshRyYmn9sVOz 1FVfqGkggVXUu8fh7swHhbQyFby5Wga8bVbeXwSoMZALTcDX9iRONndMf+ALpS5mve4E avkqRJ94xdLJkZue57ME9+/OZ7kRerlPXmG4RzyN8CO+EfBtRp9alz4Cp4+ObGFQfnWX qdld3U+wjXJ79XNY4SWWzcCT8TObF+uoAIxfvmanedGVKnhbBZFQvHBzrh3OxRb6XWVP geAQ== X-Gm-Message-State: ALoCoQnZ5uj3frC4/gBPBekpes6Qd0LkU03ZfCJVQ3LsQr6tF5uRKmvQvSGI7R/jZK9TVxVOEuPO MIME-Version: 1.0 X-Received: by 10.112.141.228 with SMTP id rr4mr3670903lbb.119.1423250681515; Fri, 06 Feb 2015 11:24:41 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 6 Feb 2015 11:24:41 -0800 (PST) In-Reply-To: <3195354.1423249793989.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> References: <3195354.1423249793989.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> Date: Fri, 6 Feb 2015 11:24:41 -0800 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 19:24:46 -0000 On Fri, Feb 6, 2015 at 11:09 AM, Randy Presuhn wrote: > Hi - > >>From: Andy Bierman >>Sent: Feb 6, 2015 8:00 AM >>To: Ladislav Lhotka >>Cc: Randy Presuhn , "netmod@ietf.org" >>Subject: Re: [netmod] yang-json document > ... >>There is the possibility that a future release of the server will add a module >>that has a top-level data node with the same local-name. In this case, >>the old client will break. I have not seen any vendors want to do this. >> >>IMO, SHOULD use the top-level prefix is appropriate, not MUST. > > Actually, the case you just described convincingly makes the case > for "MUST" by demonstrating how a permitted (if unwise) deployment / > implementation decision would lead to a non-interoperable (rather > than merely inefficient) situation. > In theory this is a problem. In reality, 2 top-level foo objects are never exactly the same. In almost all cases there will never be a top-level name collision, and the server knows "interfaces" means the one and only object named "interfaces". If our server started rejecting input like this, then customers would complain. IMO namespaces should not get in the way, if possible. But I can see how the IETF will see this differently and force everybody to design for maximum interoperability. > Randy > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 6 11:36:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355EB1A8704 for ; Fri, 6 Feb 2015 11:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eolIw0oyxX4 for ; Fri, 6 Feb 2015 11:36:26 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0137.outbound.protection.outlook.com [65.55.169.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8801A7002 for ; Fri, 6 Feb 2015 11:36:26 -0800 (PST) Received: from CO2PR05CA032.namprd05.prod.outlook.com (10.141.241.160) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 19:36:24 +0000 Received: from BN1AFFO11FD014.protection.gbl (2a01:111:f400:7c10::197) by CO2PR05CA032.outlook.office365.com (2a01:111:e400:1429::32) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Fri, 6 Feb 2015 19:36:23 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1AFFO11FD014.mail.protection.outlook.com (10.58.52.74) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 19:36:21 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 11:36:20 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16JaIW90575; Fri, 6 Feb 2015 11:36:18 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16Ja3uK065795; Fri, 6 Feb 2015 14:36:04 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061936.t16Ja3uK065795@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <84C2F7B7-0701-44DB-84FB-FD2854AD161B@nic.cz> Date: Fri, 6 Feb 2015 14:36:03 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; tail-f.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(46102003)(47776003)(105596002)(6806004)(106466001)(53416004)(76506005)(92566002)(87936001)(110136001)(86362001)(50986999)(54356999)(77156002)(50466002)(48376002)(62966003)(77096005)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB434; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB434; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 19:36:21.4204 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB434 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 19:36:28 -0000 Ladislav Lhotka writes: >Most use cases for anyxml I am aware of are actually not in config. If you want to have >an anyxml node in config, you should probably make sure a mapping exists in both ways. T >his is however still much easier than defining a universal mapping. Without a universal mapping, you're requiring that the central agent/proxy know/support all the specific mappings. Thanks, Phil From nobody Fri Feb 6 11:40:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B681A8775 for ; Fri, 6 Feb 2015 11:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkK9QUQr2UVB for ; Fri, 6 Feb 2015 11:40:01 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7031C1A87ED for ; Fri, 6 Feb 2015 11:39:40 -0800 (PST) Received: from BL2PR05CA0043.namprd05.prod.outlook.com (10.255.226.43) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 19:39:39 +0000 Received: from BN1AFFO11FD009.protection.gbl (2a01:111:f400:7c10::178) by BL2PR05CA0043.outlook.office365.com (2a01:111:e400:c04::43) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Fri, 6 Feb 2015 19:39:38 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1AFFO11FD009.mail.protection.outlook.com (10.58.52.69) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 19:39:38 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 11:39:35 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16JdYW92588; Fri, 6 Feb 2015 11:39:34 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16JdKNR065824; Fri, 6 Feb 2015 14:39:20 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061939.t16JdKNR065824@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Fri, 6 Feb 2015 14:39:20 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(87936001)(47776003)(54356999)(48376002)(50466002)(2950100001)(53416004)(46102003)(62966003)(106466001)(92566002)(77156002)(110136001)(105596002)(50986999)(76506005)(6806004)(77096005)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB440; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 19:39:38.7879 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 19:40:02 -0000 Andy Bierman writes: >This reminds me of the SNMP debates about optimizing for generic tools >like a MIB walker, or data-model-aware tools like an NMS. Sure and both types of tools have value. Combinations of both tools have value. >IMO your web-banner example is invalid because a string leaf is the proper >YANG data model design, not anyxml. Why isn't anyxml more proper? It requires the data to be valid XML, which is what I want. Why would using an opaque data type serve me better? Thanks, Phil From nobody Fri Feb 6 11:56:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDF61A1BC7 for ; Fri, 6 Feb 2015 11:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtzbhE_U_IhK for ; Fri, 6 Feb 2015 11:56:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0141A87A0 for ; Fri, 6 Feb 2015 11:56:49 -0800 (PST) Received: from BY2PR05CA047.namprd05.prod.outlook.com (10.141.250.37) by BN1PR05MB439.namprd05.prod.outlook.com (10.141.58.22) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 19:56:27 +0000 Received: from BN1BFFO11FD013.protection.gbl (2a01:111:f400:7c10::1:196) by BY2PR05CA047.outlook.office365.com (2a01:111:e400:2c5f::37) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Fri, 6 Feb 2015 19:56:26 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD013.mail.protection.outlook.com (10.58.144.76) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 19:56:26 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 11:56:24 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16JuNW00944; Fri, 6 Feb 2015 11:56:23 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16Ju98k065960; Fri, 6 Feb 2015 14:56:09 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502061956.t16Ju98k065960@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Fri, 6 Feb 2015 14:56:09 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51704005)(53416004)(46102003)(110136001)(92566002)(18206015028)(105596002)(106466001)(54356999)(6806004)(50466002)(77096005)(87936001)(86362001)(62966003)(77156002)(76506005)(47776003)(2950100001)(48376002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB439; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB439; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB439; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB439; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 19:56:26.2020 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB439 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 19:56:53 -0000 Andy Bierman writes: >> "web-banner": "

This is very sensitive data

\n\n

I'm serious, dude

\n" > >I don't see how this will possibly work. >How does the server know the JSON string is special >and should be rendered as raw XML? A normal server >is going to escape all the angle brackets if rendered in XML. The server is expected to have the data models for the content it is carrying, so it will know that web-banner is "anyxml". It knows that anyxml values are encoded in JSON as strings. It will accept that string value and stuff it into the database. If an XML client retrieves it, the value will be sent according to the XML encoding rules. Thanks, Phil From nobody Fri Feb 6 12:02:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85D01A87DB for ; Fri, 6 Feb 2015 12:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TxWDpTaMhml for ; Fri, 6 Feb 2015 12:02:51 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 C0FA21A87E8 for ; Fri, 6 Feb 2015 12:02:11 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id b6so13555651lbj.9 for ; Fri, 06 Feb 2015 12:02:10 -0800 (PST) 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:content-type; bh=YuUu6j1QEojuV/SfjH44ANRsNlvzE+WxIi7+rmwFE4Q=; b=MkffvXl0pz6eeLGheScSxiajQLOYe0Jy7PRTyl2y4jEW6H+/J7eO5ySD4sOxZFylij IYPT6U0xRuAs+IvL6ICAVnGcs/1tvVDOODqw/JoDveQq/SBERn0pjtOL9LfJcrJgxOeB T0gPggKf4S8mkkxCl3C0Dc7YClYE/AincdZBRBJHkFXlb0XrMblprqpvXYqu8bFNKD9D qoBny63EE82C6swD4Ed3JsIDf4WkzzEgS84DR15iylT8gRH7hKkVym8/U/fL8+m95kZo aYk7ZwVrZjFEAf+JeyQk10MKjBW/hQw3/WDL4XonQfGEy+X0UyeeLW8BFmFydISAmEV+ jNlw== X-Gm-Message-State: ALoCoQmwogUNGqOQXRLOiJbDdQ97SbvvIHJG+q9072pd/jk/Jo2jkVGug/AB7UwYyQYpEh9jcfy+ MIME-Version: 1.0 X-Received: by 10.112.166.73 with SMTP id ze9mr4641374lbb.38.1423252930197; Fri, 06 Feb 2015 12:02:10 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 6 Feb 2015 12:02:10 -0800 (PST) In-Reply-To: <201502061939.t16JdKNR065824@idle.juniper.net> References: <201502061939.t16JdKNR065824@idle.juniper.net> Date: Fri, 6 Feb 2015 12:02:10 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 20:02:55 -0000 On Fri, Feb 6, 2015 at 11:39 AM, Phil Shafer wrote: > Andy Bierman writes: >>This reminds me of the SNMP debates about optimizing for generic tools >>like a MIB walker, or data-model-aware tools like an NMS. > > Sure and both types of tools have value. Combinations of both tools > have value. > >>IMO your web-banner example is invalid because a string leaf is the proper >>YANG data model design, not anyxml. > > Why isn't anyxml more proper? It requires the data to be valid > XML, which is what I want. Why would using an opaque data type > serve me better? > Because there are very few implementations of anyxml. The ones that do exist vary in the XML they accept as input and the XML they generate as output. Some servers do not allow anyxml as data nodes at all. It is not surprising that the JSON encoding would be problematic, since we never had agreement on the XML encoding. I really do not like anyxml instead of real data nodes. I don't want to encourage the practice in YANG 1.1 by adding anydata. I think it is step in the wrong direction. Maybe we need to be thinking about standardizing the implementation magic that picks the correct media-type template for the anyxml node. E.g., for YANG Patch "application/yang.patch+xml" or "text/html" for your web-banner. > Thanks, > Phil Andy From nobody Fri Feb 6 12:16:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A301A87D9 for ; Fri, 6 Feb 2015 12:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N753AXB8ZzuR for ; Fri, 6 Feb 2015 12:15:50 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECBE1A1BE3 for ; Fri, 6 Feb 2015 12:15:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1C6FD1AB5; Fri, 6 Feb 2015 21:15:49 +0100 (CET) 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 mx5AMymhCBDW; Fri, 6 Feb 2015 21:15:20 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Feb 2015 21:15:48 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 463DD20037; Fri, 6 Feb 2015 21:15:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HGmraEm5KmtH; Fri, 6 Feb 2015 21:15:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEE4F20035; Fri, 6 Feb 2015 21:15:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D232431AE1A4; Fri, 6 Feb 2015 21:15:46 +0100 (CET) Date: Fri, 6 Feb 2015 21:15:46 +0100 From: Juergen Schoenwaelder To: "Thomas D. Nadeau" Message-ID: <20150206201546.GA911@elstar.local> Mail-Followup-To: "Thomas D. Nadeau" , NETMOD Working Group References: <7C52DD5B-33F7-44D1-A701-90254AAD7C12@lucidvision.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C52DD5B-33F7-44D1-A701-90254AAD7C12@lucidvision.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2015 20:15:58 -0000 On Fri, Feb 06, 2015 at 01:59:30PM -0500, Thomas D. Nadeau wrote: > > This commences a NETMOD WG Last call for draft-ietf-netmod-acl-model-01.txt. Please send comments to the list by 20-FEB-2015 by 9AM EST. > Before I read this in detail already a few quick comments: - The module name 'packet-fields' should follow RFC 6020 guidelines. - Non-normative example modules should be in an appendix marked as non-normative. - The security considerations include a TBD action item. - If ietf-route-filter.yang is an example, I would probably give it a different name that has less chance to be confused with an official module. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 6 12:35:23 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAA81A1B78 for ; Fri, 6 Feb 2015 12:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azC6ZFxqZKfh for ; Fri, 6 Feb 2015 12:35:19 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1201A00C6 for ; Fri, 6 Feb 2015 12:35:19 -0800 (PST) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 20:35:18 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) with mapi id 15.01.0075.002; Fri, 6 Feb 2015 20:35:18 +0000 From: Dean Bogdanovic To: NETMOD Working Group Thread-Topic: [netmod] IPR Poll for draft-ietf-netmod-acl-model-01.txt Thread-Index: AQHQQj8ZH5jjqjBvzUuXVG3P+XnETZzkFFYA Date: Fri, 6 Feb 2015 20:35:17 +0000 Message-ID: <3335B982-7A59-4577-A7BD-9837D790AD83@juniper.net> References: <9307E060-237C-4AF7-B281-92E2B886F0F9@lucidvision.com> In-Reply-To: <9307E060-237C-4AF7-B281-92E2B886F0F9@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(51704005)(50986999)(50226001)(102836002)(19580405001)(83716003)(99286002)(40100003)(86362001)(110136001)(87936001)(62966003)(15975445007)(2656002)(77156002)(2900100001)(450100001)(107886001)(76176999)(2950100001)(36756003)(106116001)(66066001)(92566002)(57306001)(230783001)(82746002)(46102003)(122556002)(19580395003)(33656002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2015 20:35:17.7931 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB423 Archived-At: Subject: Re: [netmod] IPR Poll for draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 20:35:22 -0000 I'm not aware of any IPR that applies to draft-ietf-netmod-acl-model-01.txt Dean On Feb 6, 2015, at 1:59 PM, Thomas D. Nadeau wrot= e: >=20 > Netmod WG: >=20 > This mail starts the IPR poll on draft-ietf-netmod-acl-model-01.txt. >=20 > Are you aware of any IPR that applies to draft-ietf-netmod-snmp-cfg-04? > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond to = this > email explicitly regardless of whether or not you are aware of any releva= nt IPR. > *The response needs to be sent to the NETMOD wg mailing list.* The docume= nt > will not advance to the next stage until a response has been received fro= m *each > author and contributor*. >=20 > If you are on the NETMOD WG email list but are not listed as an author o= r > contributor, then please explicitly respond only if you are aware of any = IPR that > has not yet been disclosed in conformance with IETF rules. >=20 > Thank you, >=20 > Tom and Juergen, NETMOD WG Chairs > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 6 13:14:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE891A1A64 for ; Fri, 6 Feb 2015 13:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwRUB1j2eTt8 for ; Fri, 6 Feb 2015 13:14:10 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D931A7003 for ; Fri, 6 Feb 2015 13:14:09 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0BACD1CF2; Fri, 6 Feb 2015 22:14:08 +0100 (CET) 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 m9PlZXjw4ZxM; Fri, 6 Feb 2015 22:13:39 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 6 Feb 2015 22:14:07 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF6B520036; Fri, 6 Feb 2015 22:14:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5nRYQpzl5-rz; Fri, 6 Feb 2015 22:14:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28FC820035; Fri, 6 Feb 2015 22:14:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2D9B331AEABE; Fri, 6 Feb 2015 22:14:04 +0100 (CET) Date: Fri, 6 Feb 2015 22:14:04 +0100 From: Juergen Schoenwaelder To: "Thomas D. Nadeau" , NETMOD Working Group Message-ID: <20150206211404.GA2595@elstar.local> Mail-Followup-To: "Thomas D. Nadeau" , NETMOD Working Group References: <7C52DD5B-33F7-44D1-A701-90254AAD7C12@lucidvision.com> <20150206201546.GA911@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150206201546.GA911@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2015 21:14:12 -0000 On Fri, Feb 06, 2015 at 09:15:46PM +0100, Juergen Schoenwaelder wrote: > On Fri, Feb 06, 2015 at 01:59:30PM -0500, Thomas D. Nadeau wrote: > > > > This commences a NETMOD WG Last call for draft-ietf-netmod-acl-model-01.txt. Please send comments to the list by 20-FEB-2015 by 9AM EST. > > > > Before I read this in detail already a few quick comments: > > - The module name 'packet-fields' should follow RFC 6020 guidelines. > > - Non-normative example modules should be in an appendix marked as > non-normative. > > - The security considerations include a TBD action item. > > - If ietf-route-filter.yang is an example, I would probably give it a > different name that has less chance to be confused with an official > module. > More comments: - Why do you use the prefix 'ietf' for ietf-yang-types? The default would have been 'yang'. - How is the packet-fields module updated? IETF process? Is this a candidate for IANA maintenance? - Do we need a copyright notice in the module descriptions? - The description of the revision does not make much sense, and the reference even less. I suggest to follow the YANG guidelines, RFC 6087. - Is layer 2 always ethernet or is this identity eth-acl { base "acl:acl-base"; description "layer 2 ACL type"; } just a misnomer? Perhaps the description of ip-acl also should be "IP layer ACL type" to be precise. But then, the associated grouping also includes layer 4 elements (port number ranges). - Since access-list/acl-type is optional, what is the meaning if it is not present? - I have no clue what to expect in the targets strings in acl-oper-data/targets. - The description of access-list talks about sequence numbers - I could not find them. Perhaps the text is outdated? - I personally would not inline the operational state nodes but this may be personal preference. - Is 'entry' the same as 'rule'? If so, why do we use two terms if one would be sufficient? - I do not understand this: The time range is identified by a name and then referenced by a function, so that those time restrictions are imposed on the function itself. I was surprised to find this since the introductory text never mentions time filters, it only talks about about packet filters and metadata filters. Well, this is filtering on the meta data when a packet is received but perhaps this deserves to be mentioned somewhere earlier. - You will be asked later on anyway to use the reserved example IP addresses in the examples, so make the changes now. - In the example in section 4.4, I suggest to remove all the edit-config stuff and to show only the config itself. I am also not sure the example is correct, has this been validated against the schema? - The explanation given at the beginning of section 4.5 belongs into the data model definition. What happens if I configure only an upper-port? What if I leave both ports out? What happens if the lower-port is larger than the upper-port? - I generally suggest to use the prefixed defined in an imported module unless there is a name clash that makes this impossible. If we always write inet:ipv4-prefix (where possible), it becomes simpler for human readers to read modules. - reference " "; avoids a warning but is otherwise not useful - The biggest thing that is unclear to me is how these generic acls are used in certain contexts. In the operational state, there is a list of opaque target strings but I do not know what they contain or how they are configured. So how do I use these generic acls? Suppose I want to use these acls to control access to my NC server. How would I have to extend the NC server config model to do that? - The IANA considerations are incomplete since I think you have two modules that need registration. - Since Section 10 is empty, remove it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 6 13:26:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C163D1A0155 for ; Fri, 6 Feb 2015 13:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ax-S7zhKtVdz for ; Fri, 6 Feb 2015 13:26:04 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4941A885D for ; Fri, 6 Feb 2015 13:26:03 -0800 (PST) Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 21:26:00 +0000 Received: from BLUPR05CA0048.namprd05.prod.outlook.com (10.141.20.18) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 21:26:00 +0000 Received: from BY2FFO11FD047.protection.gbl (2a01:111:f400:7c0c::159) by BLUPR05CA0048.outlook.office365.com (2a01:111:e400:855::18) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Fri, 6 Feb 2015 21:25:59 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD047.mail.protection.outlook.com (10.1.15.175) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 21:25:58 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 13:25:57 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16LPuW45988; Fri, 6 Feb 2015 13:25:56 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16LPf2D066736; Fri, 6 Feb 2015 16:25:41 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502062125.t16LPf2D066736@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Fri, 6 Feb 2015 16:25:41 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(47776003)(50986999)(2950100001)(76506005)(86362001)(87936001)(62966003)(77096005)(54356999)(77156002)(110136001)(48376002)(50466002)(6806004)(92566002)(106466001)(46102003)(53416004)(105596002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB443; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 21:25:58.3370 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; X-OriginatorOrg: juniper.net Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 21:26:06 -0000 Andy Bierman writes: >> Why isn't anyxml more proper? It requires the data to be valid >> XML, which is what I want. Why would using an opaque data type >> serve me better? >Because there are very few implementations of anyxml. >The ones that do exist vary in the XML they accept as input >and the XML they generate as output. Some servers do >not allow anyxml as data nodes at all. That sounds more like an issue of incomplete implementations than an explanation of why anyxml isn't a proper means of modeling xml data. Thanks, Phil From nobody Fri Feb 6 13:57:21 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B272B1A6FF2 for ; Fri, 6 Feb 2015 13:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73YJsifE2o4m for ; Fri, 6 Feb 2015 13:57:19 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 F18381A0155 for ; Fri, 6 Feb 2015 13:57:18 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n10so16191879lbv.6 for ; Fri, 06 Feb 2015 13:57:17 -0800 (PST) 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:content-type; bh=ni1LY3ApdygaQA1CZv51ZqX1fuCoHVMyGBe/9RhWoFg=; b=CG8oLpiq+t2fcLc7MxnIjfhGUFaEtubhONjfGDDg19FKkn3nqPE0VQaXiNj+43gwgL TMYBl2r7laXwV6GvCVC5nZm3p9IyiRKmuG1HPuEzkGZwQ9sTlOxtxogIXrDsACZl5yCI XrAVC7aSjUANW3lxnwxGI4ky2zM4fd8lrDvxutfCh2AxWBLo52dZXAW3tzyLSjUoXiXC cC8caM+eKG/08sZbg97vZHnRS28Fxk2mayIrepSe0quX2BU/3O2p4PoKS/BcXjXPBXLm dRe0e/PtCfrPg7v+W2RlYh4kBmiD5ST2QKDNbbFiOPgmwyw61P+1DCDJATkwPZIK3gcK 4cAg== X-Gm-Message-State: ALoCoQnI2P1i8R/oUKMbYphpKQljvFaFs2MddwkjdNB8wn5JBOxYbYaesUsusQ9PERNrTP/fRdNU MIME-Version: 1.0 X-Received: by 10.152.5.101 with SMTP id r5mr5052945lar.33.1423259837342; Fri, 06 Feb 2015 13:57:17 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 6 Feb 2015 13:57:17 -0800 (PST) In-Reply-To: <201502062125.t16LPf2D066736@idle.juniper.net> References: <201502062125.t16LPf2D066736@idle.juniper.net> Date: Fri, 6 Feb 2015 13:57:17 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 21:57:20 -0000 On Fri, Feb 6, 2015 at 1:25 PM, Phil Shafer wrote: > Andy Bierman writes: >>> Why isn't anyxml more proper? It requires the data to be valid >>> XML, which is what I want. Why would using an opaque data type >>> serve me better? >>Because there are very few implementations of anyxml. >>The ones that do exist vary in the XML they accept as input >>and the XML they generate as output. Some servers do >>not allow anyxml as data nodes at all. > > That sounds more like an issue of incomplete implementations > than an explanation of why anyxml isn't a proper means of > modeling xml data. > Why do you implement web-banner with a string instead of anyxml? Maybe the need for purely abstract or HTML data nodes is so rare that the significant resources needed to support it are not available. > Thanks, > Phil Andy From nobody Fri Feb 6 14:26:58 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F001A86EA for ; Fri, 6 Feb 2015 14:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ_q3DGH6yeu for ; Fri, 6 Feb 2015 14:26:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7391A6F2E for ; Fri, 6 Feb 2015 14:26:53 -0800 (PST) Received: from BY2PR05CA045.namprd05.prod.outlook.com (10.141.250.35) by BN1PR05MB439.namprd05.prod.outlook.com (10.141.58.22) with Microsoft SMTP Server (TLS) id 15.1.81.19; Fri, 6 Feb 2015 22:26:30 +0000 Received: from BY2FFO11FD005.protection.gbl (2a01:111:f400:7c0c::143) by BY2PR05CA045.outlook.office365.com (2a01:111:e400:2c5f::35) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Fri, 6 Feb 2015 22:26:30 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Fri, 6 Feb 2015 22:26:29 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 6 Feb 2015 14:26:29 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t16MQSW74627; Fri, 6 Feb 2015 14:26:28 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t16MQD6M067155; Fri, 6 Feb 2015 17:26:13 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502062226.t16MQD6M067155@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Fri, 6 Feb 2015 17:26:13 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(46102003)(53416004)(110136001)(106466001)(105596002)(54356999)(77096005)(6806004)(50466002)(87936001)(86362001)(62966003)(77156002)(92566002)(47776003)(76506005)(2950100001)(48376002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB439; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB439; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB439; X-Forefront-PRVS: 047999FF16 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB439; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2015 22:26:29.7806 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB439 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 22:26:55 -0000 Andy Bierman writes: >Why do you implement web-banner with a string instead of anyxml? Because that's what anyxml does. >Maybe the need for purely abstract or HTML data nodes is so rare that the >significant resources needed to support it are not available. Rare? Yes. Useful? Definitely. I can certainly see your desire to not waste your resources implementing it until one of your customers needs it, but that doesn't mean it's not a valid part of the YANG spec. I have similar feelings for the notification mechanism, which is far more ugly. I'll implement it when customer demand (current zero) exceeds my distaste (more than zero). That's my choice, but it doesn't effect the status of the notifications rfc. Thanks, Phil From nobody Fri Feb 6 14:42:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13C1A8792; Fri, 6 Feb 2015 14:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.054 X-Spam-Level: X-Spam-Status: No, score=-101.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRbFY_8NNWXV; Fri, 6 Feb 2015 14:42:35 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFC61A6F96; Fri, 6 Feb 2015 14:42:34 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> In-Reply-To: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> Date: Fri, 6 Feb 2015 17:42:21 -0500 Message-ID: <01d101d0425e$2d271740$877545c0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01D2_01D04234.44563F60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIyIa+OW8V9HkmziikvEba5jtd8kpwgdpuw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, NETCONF , netmod@ietf.org Subject: [netmod] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 22:42:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D2_01D04234.44563F60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01D3_01D04234.44563F60" ------=_NextPart_001_01D3_01D04234.44563F60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IDR WG will hold an interim on 2/9/2015 that focuses on BGP Yang = modules. The agenda is below.=20 =20 Sue Hares and John Scudder=20 =20 --------- =20 Agenda: (75 minutes 10:00 - 11:15am) =20 1) A review of draft-zhdankin-idr-bgp-cfg-00 (Keyur Patel) [30 minutes]=20 =20 2) Overview of Policy Yang drafts in IETF (Sue Hares) [10 minutes]=20 =20 Other policy drafts to read=20 = http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00 = http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ = http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/ = http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/ = http://datatracker.ietf.org/doc/draft-hareskini-i2rs-pbr-info-model/ =20 3) Discussion comparing 2 BGP Yang modules [30 minutes]=20 draft-zhdankin-idr-bgp-cfg-00=20 =20 = https://github.com/YangModels/yang/tree/master/experimental/openconfig =20 =20 From: IDR Working Group [mailto:messenger@webex.com]=20 Sent: Friday, February 06, 2015 4:48 PM To: shares@ndzh.com Subject: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules =20 Hello,=20 IDR Working Group invites you to join this WebEx meeting.=20 =20 =20 =20 IDR Interim 2/9 - BGP Yang Modules=20 Monday, February 9, 2015=20 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 2 hrs=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 646 680 229=20 Meeting password: bgpyang =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 680 229 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. =20 ------=_NextPart_001_01D3_01D04234.44563F60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

IDR WG will hold an interim on 2/9/2015 that focuses on BGP Yang = modules.=C2=A0 =C2=A0The agenda is below.

 

Sue Hares and John Scudder

 

---------

 

Agenda: (75 minutes 10:00 - 11:15am)=C2=A0

1) A review of draft-zhdankin-idr-bgp-cfg-00 (Keyur Patel) [30 = minutes]

 

2) Overview of Policy Yang drafts in IETF (Sue Hares) [10 minutes] =

 

Other policy drafts to read

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 = http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 = http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 = http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 = http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 = http://datatracker.ietf.org/doc/draft-hareskini-i2rs-pbr-info-model/=

 

3) Discussion comparing 2 BGP Yang modules [30 minutes] =

=C2=A0=C2=A0=C2=A0=C2=A0draft-zhdankin-idr-bgp-cfg-00 =

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 = https://github.com/YangModels/yang/tree/master/experimental/openconfig

 

 

From:= = IDR Working Group [mailto:messenger@webex.com]
Sent: Friday, = February 06, 2015 4:48 PM
To: = shares@ndzh.com
Subject: WebEx meeting invitation: IDR Interim = 2/9 - BGP Yang Modules

 

Hello,

IDR Working Group invites you to join this WebEx meeting. =

 

 

 

IDR Interim 2/9 = - BGP Yang Modules =

Monday, February 9, 2015

10:00 am  |  Eastern Standard Time (New York, = GMT-05:00)  |  2 hrs =

 

 

 

Join = WebEx meeting =

 

Meeting number:

646 680 229

Meeting password:

bgpyang

 

 

 

Join by = phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 646 680 229

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your = calendar.

 

 

 

Can't join the meeting? Contact support. =

 

 

 

= IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session.

 

------=_NextPart_001_01D3_01D04234.44563F60-- ------=_NextPart_000_01D2_01D04234.44563F60 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting.ics" BEGIN:VCALENDAR=0A= PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN=0A= VERSION:2.0=0A= METHOD:REQUEST=0A= BEGIN:VTIMEZONE=0A= TZID:Eastern Time=0A= BEGIN:STANDARD=0A= DTSTART:20131101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0A= TZOFFSETTO:-0500=0A= TZNAME:Standard Time=0A= END:STANDARD=0A= BEGIN:DAYLIGHT=0A= DTSTART:20130301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0A= TZOFFSETTO:-0400=0A= TZNAME:Daylight Savings Time=0A= END:DAYLIGHT=0A= END:VTIMEZONE=0A= BEGIN:VEVENT=0A= ATTENDEE;CN=3D"";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:shares@ndzh.co= m=0A= ORGANIZER;CN=3D"IDR Working Group":MAILTO:idr-chairs@tools.ietf.org=0A= DTSTART;TZID=3D"Eastern Time":20150209T100000=0A= DTEND;TZID=3D"Eastern Time":20150209T120000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1423259294=0A= UID:95914718-393c-49c6-aef5-acbec7e921f4=0A= DTSTAMP:20150209T150000Z=0A= DESCRIPTION:\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dma5c2c23113c957b1cb77c1= 39ac4c0220\nMeeting number: 646 680 229\nMeeting password: = bgpyang\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free number = (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess = code: 646 680 229\n\nToll-free dialing restrictions: = \nhttp://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join = the meeting? Contact support = here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during = the session to be recorded, which may be discoverable in a legal matter. = By joining this session, you automatically consent to such recordings. = If you do not consent to being recorded, discuss your concerns with the = host or do not join the session.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:  
Join WebEx = meeting =
Meeting number: 646 680 = 229
Meeting = password:bgpyang
 
 
Join by = phone 
1-877-668-4493 Call-in toll free = number (US/Canada) 
1-650-479-3208 Call-in toll number = (US/Canada) 
Access code: 646 680 229 
Toll-free calling = restrictions  


 
Can't join the = meeting? Contact support. =  
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the session.=0A= SUMMARY:IDR Interim 2/9 - BGP Yang Modules=0A= PRIORITY:5=0A= CLASS:PUBLIC=0A= BEGIN:VALARM=0A= TRIGGER:-PT5M=0A= ACTION:DISPLAY=0A= DESCRIPTION:Reminder=0A= END:VALARM=0A= END:VEVENT=0A= END:VCALENDAR=0A= ------=_NextPart_000_01D2_01D04234.44563F60-- From nobody Fri Feb 6 14:53:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2380E1A87D5 for ; Fri, 6 Feb 2015 14:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uw_0rzCktHZ for ; Fri, 6 Feb 2015 14:53:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id D77B91A87AB for ; Fri, 6 Feb 2015 14:53:48 -0800 (PST) Received: from [10.24.18.51] (128-107-239-233.cisco.com [128.107.239.233]) by mail.tail-f.com (Postfix) with ESMTPSA id E96231280996 for ; Fri, 6 Feb 2015 23:53:46 +0100 (CET) From: Carl Moberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <67352F3D-DDCC-416E-A6F4-714C444DCF74@tail-f.com> Date: Fri, 6 Feb 2015 14:53:43 -0800 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [netmod] Looking for YANG training material X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 22:53:50 -0000 NETMOD, As part of the efforts of the newly formed YANG module coordination = group we're looking at trying to build a common and freely available = presentation on the YANG language and associated technologies (e.g. = NETCONF, RESTCONF). We would likely try and release it under some sort = of permissive license to make sure it's unencumbered and can be freely = (re-)used. There are a number of presentations available on sites like = netconfcentral.org and yang-central.org, but I would like to get in = touch with those of you who have actually created presentations and = would be willing to contribute existing content, or perhaps even help = write new content on these topics. Contact me directly if you're interested and able to help in this = effort. -- Carl Moberg From nobody Fri Feb 6 14:54:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CB01A87B0 for ; Fri, 6 Feb 2015 14:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVelUHLzn6d3 for ; Fri, 6 Feb 2015 14:54:23 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 44D0A1A87AB for ; Fri, 6 Feb 2015 14:54:23 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id u10so7339126lbd.7 for ; Fri, 06 Feb 2015 14:54:21 -0800 (PST) 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:content-type; bh=hFtFl5CVpUTngLqsgCsvAubs6hs3lgRJs26CP7KhH/g=; b=Rtd3XJoY7p7OWNwNZx91ZnRUkH7wYG5dLKpV59ViuFORKnBM0rXVNH+JPGRYe1279K ZJAWVN+powywfe7VLTQQrX1OUdykEq3eArjHPK+FNT5V0NkDyz/3aElvP3K79HueKWbG yrovuPD2BsC3rvfvZc4cq5z6LoMLrMOyQZkiXsrYglannglN5zSb2djxQAs6riDZbIgs DONox+Lb8Z9xJ9wpEudmExNRk7Y6YRR2O0rvmvc9Mb43asWAsH1Kc1D1ZbSQrlZDFZJV mUG2L+MATweaLKXraombfRUnx1FEdeJJtuEbO/rxFI5pXfmbNSvVxMW1susx19bmbfXf EMkQ== X-Gm-Message-State: ALoCoQmxHDp7sz/dolEYXcKbKSLfA1fro5+ipDeH1j0z7RcZJc/aOZ+Yk58mJjpt1qrdxdAR6cL7 MIME-Version: 1.0 X-Received: by 10.112.142.168 with SMTP id rx8mr5054934lbb.37.1423263261679; Fri, 06 Feb 2015 14:54:21 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 6 Feb 2015 14:54:21 -0800 (PST) In-Reply-To: <201502062226.t16MQD6M067155@idle.juniper.net> References: <201502062226.t16MQD6M067155@idle.juniper.net> Date: Fri, 6 Feb 2015 14:54:21 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 22:54:24 -0000 On Fri, Feb 6, 2015 at 2:26 PM, Phil Shafer wrote: > Andy Bierman writes: >>Why do you implement web-banner with a string instead of anyxml? > > Because that's what anyxml does. > >>Maybe the need for purely abstract or HTML data nodes is so rare that the >>significant resources needed to support it are not available. > > Rare? Yes. Useful? Definitely. I can certainly see your desire > to not waste your resources implementing it until one of your > customers needs it, but that doesn't mean it's not a valid part of > the YANG spec. It is more than that. I want to be very careful about the mandatory to implement standards. If supporting a 1% use-case has a significant impact on footprint, complexity, development costs, support costs, etc., then it won't get implemented. That seems to be what already happened with anyxml. > > I have similar feelings for the notification mechanism, which is > far more ugly. I'll implement it when customer demand (current > zero) exceeds my distaste (more than zero). That's my choice, but > it doesn't effect the status of the notifications rfc. > But this is optional to implement. Big difference. We actually support anyxml data nodes in the config or operational data, but the implementation does not support mixed mode XML. Internally, anyxml looks more like a leaf than anything else. > Thanks, > Phil Andy From nobody Sat Feb 7 02:15:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2A91A1A6A; Sat, 7 Feb 2015 00:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyI_5sE2K77m; Sat, 7 Feb 2015 00:43:50 -0800 (PST) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187B21A8938; Sat, 7 Feb 2015 00:43:49 -0800 (PST) Received: from Macintosh-6.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id pLjl1p00G3vXPcr01LjnYu; Sat, 07 Feb 2015 09:43:47 +0100 Message-ID: <54D5D041.5070307@bwijnen.net> Date: Sat, 07 Feb 2015 09:43:45 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Susan Hares , idr wg References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> In-Reply-To: <01d101d0425e$2d271740$877545c0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sat, 07 Feb 2015 02:15:15 -0800 Cc: Rtg-yang-coord@ietf.org, NETCONF , netmod@ietf.org Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 08:43:52 -0000 On 06/02/15 23:42, Susan Hares wrote: > Agenda: (75 minutes 10:00 - 11:15am) any specifics on time zone? we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? Bert From nobody Sat Feb 7 06:48:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5051A8735; Sat, 7 Feb 2015 06:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCD7ssjIPJhn; Sat, 7 Feb 2015 06:48:24 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D331A8731; Sat, 7 Feb 2015 06:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=491; q=dns/txt; s=iport; t=1423320504; x=1424530104; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XgU3GPNTHQq2fv15ivCYBbae6zwDgQSLVRns6+wnaW0=; b=gTYaO3dvNq5JZofQxKmpVFbminotOHXTYMV8k691/zuE+yXy4dhX9BD+ /BrAi/ifPz7BJIFhcGmIIe+9hneNnrX/6L/x+M65uOw/+brHdYh5CLEfq RwC+easGARehyyIeXYqLr0cjv784/ZO2rO5Efq1Z3IdkrJyZKLIbRpTHu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A/BQCbJNZU/4ENJK1bgwZSWgTCcgqFJ0oCgQ9DAQEBAQEBfIQMAQEBBAEBATc0CxACAQgYHhAnCxwJAgQBDQWILQ3PPgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjEgBgy8HhCoBBI8biSyScCKCDyOBPG+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,535,1418083200"; d="scan'208";a="121483980" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 07 Feb 2015 14:48:23 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t17EmNW4024643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Feb 2015 14:48:23 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Sat, 7 Feb 2015 08:48:23 -0600 From: "Acee Lindem (acee)" To: "Bert Wijnen (IETF)" , Susan Hares , idr wg Thread-Topic: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules Thread-Index: AQHQQr8Dw4Yj9R/hCUyYBX1U1m3HoZzlRMMA Date: Sat, 7 Feb 2015 14:48:22 +0000 Message-ID: References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> <54D5D041.5070307@bwijnen.net> In-Reply-To: <54D5D041.5070307@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.185.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <2609C62857BBC14196B149647A39CF38@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Rtg-yang-coord@ietf.org" , NETCONF , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 14:48:25 -0000 Hi Bert, If you look at the WebEx, it is 10 AM EST (GMT - 5). Acee=20 On 2/7/15, 2:43 AM, "Bert Wijnen (IETF)" wrote: >On 06/02/15 23:42, Susan Hares wrote: >> Agenda: (75 minutes 10:00 - 11:15am) >any specifics on time zone? > >we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? > >Bert > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Sat Feb 7 08:31:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86ED81A1AEA; Sat, 7 Feb 2015 08:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.055 X-Spam-Level: X-Spam-Status: No, score=-101.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez6SrlgQlGUc; Sat, 7 Feb 2015 08:28:49 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D51A0084; Sat, 7 Feb 2015 08:28:49 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , "'Bert Wijnen \(IETF\)'" , "'idr wg'" References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> <54D5D041.5070307@bwijnen.net> In-Reply-To: Date: Sat, 7 Feb 2015 11:28:40 -0500 Message-ID: <003001d042f3$22c77ed0$68567c70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIyIa+OW8V9HkmziikvEba5jtd8kgJZ/j75Awex5hcBDXZmPJvuKZaQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, 'NETCONF' , netmod@ietf.org Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 16:28:51 -0000 Bert: 10 - 11:30 am ET. My apologies for missing it. Sue -----Original Message----- From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: Saturday, February 07, 2015 9:48 AM To: Bert Wijnen (IETF); Susan Hares; idr wg Cc: Rtg-yang-coord@ietf.org; NETCONF; netmod@ietf.org Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules Hi Bert, If you look at the WebEx, it is 10 AM EST (GMT - 5). Acee On 2/7/15, 2:43 AM, "Bert Wijnen (IETF)" wrote: >On 06/02/15 23:42, Susan Hares wrote: >> Agenda: (75 minutes 10:00 - 11:15am) >any specifics on time zone? > >we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? > >Bert > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Feb 8 01:45:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487F21A890A for ; Sun, 8 Feb 2015 01:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIMZBk985Jw5 for ; Sun, 8 Feb 2015 01:44:50 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBAE1A1A75 for ; Sun, 8 Feb 2015 01:44:50 -0800 (PST) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 100E71CC094E; Sun, 8 Feb 2015 10:44:49 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201502061554.t16FsnwS064052@idle.juniper.net> References: <201502061554.t16FsnwS064052@idle.juniper.net> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Sun, 08 Feb 2015 10:44:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 09:44:52 -0000 Phil Shafer writes: > Ladislav Lhotka writes: >>Well, 6020 only deals with XML encoding and the definition is exactly what you said - an >>y XML stuff: >> The "anyxml" statement is used to represent an unknown chunk of XML. >> No restrictions are placed on the XML. >>I don't know why JSON (or, for that matter, any other) encoding should be any different. > > I think you're missing something here. "anyxml banner" means that > in my datastore, "banner" is (conceptualy) an arbitrary chunk of > XML. When you fetch that via traditional NETCONF, that chunk of > XML is copied into the data stream when/as needed. Incoming values > for banner are stuffed into the database. I don't think I am missing anything, actually I used pretty much the same example previously: http://www.ietf.org/mail-archive/web/netmod/current/msg11700.html What you put to a database is one thing and what's presented to NETCONF clients is another. If you decide to store HTML internally, you'd need to translate input/output from/to JSON clients to markdown. But you can also do it the other way around: store markdown and perform the translations for XML clients. I am not saying this is the only or best way for implementing this particular use case, I just don't think that XML-in-JSON-string is the only option because it has its share of problems, too. For the record, I am not in favor of removing anyxml in its current form. The only problem I have with it is the name. I think it can be useful to have a node in YANG that allows for exchanging schema-less chunks in *any* encoding. Lada > > For this to work via JSON, the same abilities need to exist. I > need to put my arbitrary chunk of XML out of my database and insert > it into my JSON data stream. When a value for banner arrives, I > need to insert it into my database. JSON is just a means of encoding > that data. Use of JSON doesn't invent the right to redefine that data, > or to say that I should have been markdown, not HTML, or to say that > the JSON encoding just won't work for banner. > > I continue to think that JSON needs to encode anyxml as strings. > I can't see anything else working here. > > For that matter, I'm still not seeing way "anydata" isn't just "type string". > > If you wanted anyjson, XML would need to encode that data as a > string. Then again, anydata and anyjson are new features, so we > shouldn't go there. > > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Feb 8 02:18:43 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B771A8927 for ; Sun, 8 Feb 2015 02:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0Cw7z63xBd1 for ; Sun, 8 Feb 2015 02:18:37 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DF3461A005A for ; Sun, 8 Feb 2015 02:18:36 -0800 (PST) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id 395A01CC0248 for ; Sun, 8 Feb 2015 11:18:36 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Sun, 08 Feb 2015 11:18:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netmod] [Ladislav Lhotka] Re: yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 10:18:40 -0000 Juergen Schoenwaelder writes: > On Fri, Feb 06, 2015 at 04:32:13PM +0100, Ladislav Lhotka wrote: >>=20 >> > On 06 Feb 2015, at 15:36, Juergen Schoenwaelder wrote: >> >=20 >> > On Fri, Feb 06, 2015 at 02:54:54PM +0100, Ladislav Lhotka wrote: >> >>=20 >> >>> On 06 Feb 2015, at 14:38, Juergen Schoenwaelder wrote: >> >>>=20 >> >>> On Fri, Feb 06, 2015 at 01:49:02PM +0100, Ladislav Lhotka wrote: >> >>>> Phil Shafer writes: >> >>>>=20 >> >>>>>=20 >> >>>>> What does the JSON for this look like? I think the only viable >> >>>>> answer is: >> >>>>>=20 >> >>>>> "web-banner": "

This is very sensitive data

\n> >>>>> src=3D"mister-yuk.png"/>\n

I'm serious, dude

\n" >> >>>>=20 >> >>>> I don't think so, the following is IMO a much better option: >> >>>>=20 >> >>>> "web-banner": >> >>>> "This is *very sensitive* data. >> >>>>=20 >> >>>> ![](mister-yuk.png) >> >>>>=20 >> >>>> I'm serious, dude" >> >>>>=20 >> >>>> To be able to do this, it should be sufficient that the description= of >> >>>> the "web-banner" anyxml node states that HTML has to be used in XML >> >>>> encoding and markdown in JSON. >> >>>>=20 >> >>>> Note that the -00 version of the draft contained a very similar exa= mple: >> >>>>=20 >> >>>> http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00#section-3= .2.5 >> >>>>=20 >> >>>=20 >> >>> As technical contributor, I do not agree that an encoder is tasked to >> >>> arbitrarily render XML content in the hope that the receiver likes t= he >> >>> result. >> >>=20 >> >> It is not an arbitrary rendering, it is what the definition of the an= yxml node demands - and both HTML and markdown are supposedly well-defined = so that there is no guesswork involved. Both parties just follow the data m= odel, nothing else. >> >>=20 >> >=20 >> > How does your _encoder_ know the receiver wanted markdown? This idea >> > is really broken and, as I said before, encoders are not translators >> > that transform at their own will say XHTML into markdown. >>=20 >> My application knows whether it will send XML or JSON, so it prepares ap= propriate data (HTML or markdown) and calls the corresponding encoder. >>=20 >> It is still the same: you and Andy cater for the application model where= the data are put into an intermediate =E2=80=9Cencoding-agnostic=E2=80=9D = structure from which it can be, as the very last step, serialised to either= XML or JSON by a dumb encoder. But because the intermediate structure is t= he DOM or something like that, it isn=E2=80=99t in fact encoding-agnostic: = it is pure XML, and that=E2=80=99s why you demand that JSON encoding follow= the XML suit where possible. >>=20 >> If you start with an XML-only application, this may be a good strategy f= or adding JSON with minimal development effort, but I am strongly against = =E2=80=9Coptimizing=E2=80=9D the JSON encoding specifically for this model. >> > > I am strongly against breaking layering abstractions. The code > handling the data store operations should not do encoding specific > stuff. This is a major layering violation. If we break layering for There are two problems with this layering abstraction: 1. XML and JSON are not just encodings, their infosets are significantly different. Creating a layered abstraction thus necessarily means that either XML or JSON is chosen as primary and the other has to be coerced into looking the same. Hence the discussions about using only strings in JSON or, conversely, eliminating mixed content, comments and processing instructions in XML. 2. JSON APIs are very different from XML ones in that they are much closer to the native data structures of applications. Processing JSON in the same way as XML, except (de)serialisation, begs the question of what's the benefit of using JSON in the first place. That said, I think much of this hairy discussion is really moot. Instead, I'd love to hear concrete proposals for changing the text in section 5.5 of the yang-json draft. Lada > JSON, we will have to break it again for CBOR and who knows what comes > next. The result will be a mess. Please check who is speaking up on > the list in favor of your interpretation of anyxml and who is having > concerns with it. > > /js > > --=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 -------------------- End of forwarded message -------------------- --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Feb 8 07:53:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA01AC447 for ; Sun, 8 Feb 2015 07:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVm0WBC1uc_F for ; Sun, 8 Feb 2015 07:51:21 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (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 6DB011A8771 for ; Sun, 8 Feb 2015 07:51:20 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so25640850lbj.0 for ; Sun, 08 Feb 2015 07:51:19 -0800 (PST) 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:content-type :content-transfer-encoding; bh=11L897O9cIih4qn41lGcSL5OITYU/7G0crHyyvhXMYU=; b=WKCiTSZzYeG3Q2v5/NTB1ZIUQwH5nC2WfP1BYiytvRDRmjYHfE0EZ0U7eidWKE2Wup cydtHZWjwAoiRzb299odJsO8bBUvduiSOwFKhUjIWctiML/trii9MbmT8biNLOoK063N a96xUHDsD+wKJroH5tW+LEpN16VupsyPXZnUk4zm9hr3d19UFV9V8JQXdT5i3qt6CBsL hOYvo8mnWh8n69yc7zH+kke6GapCXSFTLF7bGtwaZm1XBizA/q8RidTJ0Av/I6I5vZxl QUIzKT9YqWe3jxzWJp9pLlGXtZgz1KK+WMIthLKQGYp4kZgBdEbQlodhuI+0WJpTGcwT rIgg== X-Gm-Message-State: ALoCoQnO0A5Ah/wiEHNz6qCv/MfEN1yKYTVIMyHuga721Wqlxj2vBX9iakqgXCd+FgXbRGZcmaBP MIME-Version: 1.0 X-Received: by 10.152.216.132 with SMTP id oq4mr4544625lac.123.1423410678864; Sun, 08 Feb 2015 07:51:18 -0800 (PST) Received: by 10.112.78.3 with HTTP; Sun, 8 Feb 2015 07:51:18 -0800 (PST) In-Reply-To: References: Date: Sun, 8 Feb 2015 07:51:18 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] [Ladislav Lhotka] Re: yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 15:51:23 -0000 On Sun, Feb 8, 2015 at 2:18 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > >> On Fri, Feb 06, 2015 at 04:32:13PM +0100, Ladislav Lhotka wrote: >>> >>> > On 06 Feb 2015, at 15:36, Juergen Schoenwaelder wrote: >>> > >>> > On Fri, Feb 06, 2015 at 02:54:54PM +0100, Ladislav Lhotka wrote: >>> >> >>> >>> On 06 Feb 2015, at 14:38, Juergen Schoenwaelder wrote: >>> >>> >>> >>> On Fri, Feb 06, 2015 at 01:49:02PM +0100, Ladislav Lhotka wrote: >>> >>>> Phil Shafer writes: >>> >>>> >>> >>>>> >>> >>>>> What does the JSON for this look like? I think the only viable >>> >>>>> answer is: >>> >>>>> >>> >>>>> "web-banner": "

This is very sensitive data

\n>> >>>>> src=3D"mister-yuk.png"/>\n

I'm serious, dude

\n" >>> >>>> >>> >>>> I don't think so, the following is IMO a much better option: >>> >>>> >>> >>>> "web-banner": >>> >>>> "This is *very sensitive* data. >>> >>>> >>> >>>> ![](mister-yuk.png) >>> >>>> >>> >>>> I'm serious, dude" >>> >>>> >>> >>>> To be able to do this, it should be sufficient that the descriptio= n of >>> >>>> the "web-banner" anyxml node states that HTML has to be used in XM= L >>> >>>> encoding and markdown in JSON. >>> >>>> >>> >>>> Note that the -00 version of the draft contained a very similar ex= ample: >>> >>>> >>> >>>> http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00#section-= 3.2.5 >>> >>>> >>> >>> >>> >>> As technical contributor, I do not agree that an encoder is tasked = to >>> >>> arbitrarily render XML content in the hope that the receiver likes = the >>> >>> result. >>> >> >>> >> It is not an arbitrary rendering, it is what the definition of the a= nyxml node demands - and both HTML and markdown are supposedly well-defined= so that there is no guesswork involved. Both parties just follow the data = model, nothing else. >>> >> >>> > >>> > How does your _encoder_ know the receiver wanted markdown? This idea >>> > is really broken and, as I said before, encoders are not translators >>> > that transform at their own will say XHTML into markdown. >>> >>> My application knows whether it will send XML or JSON, so it prepares a= ppropriate data (HTML or markdown) and calls the corresponding encoder. >>> >>> It is still the same: you and Andy cater for the application model wher= e the data are put into an intermediate =E2=80=9Cencoding-agnostic=E2=80=9D= structure from which it can be, as the very last step, serialised to eithe= r XML or JSON by a dumb encoder. But because the intermediate structure is = the DOM or something like that, it isn=E2=80=99t in fact encoding-agnostic:= it is pure XML, and that=E2=80=99s why you demand that JSON encoding follo= w the XML suit where possible. >>> >>> If you start with an XML-only application, this may be a good strategy = for adding JSON with minimal development effort, but I am strongly against = =E2=80=9Coptimizing=E2=80=9D the JSON encoding specifically for this model. >>> >> >> I am strongly against breaking layering abstractions. The code >> handling the data store operations should not do encoding specific >> stuff. This is a major layering violation. If we break layering for > > There are two problems with this layering abstraction: > > 1. XML and JSON are not just encodings, their infosets are significantly > different. Creating a layered abstraction thus necessarily means that > either XML or JSON is chosen as primary and the other has to be > coerced into looking the same. Hence the discussions about using only > strings in JSON or, conversely, eliminating mixed content, comments > and processing instructions in XML. > > 2. JSON APIs are very different from XML ones in that they are much > closer to the native data structures of applications. Processing JSON > in the same way as XML, except (de)serialisation, begs the question of > what's the benefit of using JSON in the first place. > > That said, I think much of this hairy discussion is really > moot. Instead, I'd love to hear concrete proposals for changing the text > in section 5.5 of the yang-json draft. > I have offered several specific mappings that attempt to utilize the common features of both XML and JSON. What use is JSON? It is a more efficient encoding format. Period. There seems to be a lot of confusion about who "owns" the schema. It's always the server. The client cannot give the server some "poor man's schema" in the form of particular JSON encoding choices. The server has no obligation whatsoever to pay any attention to client schema hints. YANG "anyxml" means no schema. It does not mean client-provided mini-schema. > Lada Andy > >> JSON, we will have to break it again for CBOR and who knows what comes >> next. The result will be a mess. Please check who is speaking up on >> the list in favor of your interpretation of anyxml and who is having >> concerns with it. >> >> /js >> >> -- >> 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 > -------------------- End of forwarded message -------------------- > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Feb 8 08:00:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3C31AC44D for ; Sun, 8 Feb 2015 08:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmWlvzRKSOsH for ; Sun, 8 Feb 2015 08:00:01 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC9F1AC44B for ; Sun, 8 Feb 2015 08:00:01 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 42ADC128097B; Sun, 8 Feb 2015 16:59:59 +0100 (CET) Date: Sun, 08 Feb 2015 16:59:59 +0100 (CET) Message-Id: <20150208.165959.1664690960227290529.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] [Ladislav Lhotka] Re: yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 16:00:02 -0000 Andy Bierman wrote: > What use is JSON? It is a more efficient encoding format. Period. For some definition of "efficient"... uncompressed JSON produces fewer bytes than uncompressed XML, but JSON requires the receiver to buffer everything. I think the main attraction of JSON is non-technical. /martin From nobody Sun Feb 8 08:10:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514CA1A1B43 for ; Sun, 8 Feb 2015 08:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMLgQ9rLdBYp for ; Sun, 8 Feb 2015 08:10:03 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 59DCF1A1B34 for ; Sun, 8 Feb 2015 08:10:03 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id f15so25719911lbj.5 for ; Sun, 08 Feb 2015 08:10:01 -0800 (PST) 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:content-type; bh=rIZBOYen0buvetECftUKrBI/CQaIve9X6eLGXz9pm4M=; b=goPmXCJhaJQVuUowWO2NIXZBONKHs4d75PCnyLk6woemeubxhQXfuBWTgWoMQFdQqi 0x4AMjSiz+U4qcn8zMoIl2xHpoZU716pJQfkONUaQVduHUNogD1oatevBXAyO8vmHFSK X38I73CDIuEm/NS4lThQQnp9VEP72KUNi6zk9MmBbTrbeZAAKPDV1ZLOSEyjGotsZ0Zu q8NkYg6am74vpkjJQxj7vnMCKBa9oI7n+xtU7BByrPT4oj4YQtSG0s6zjzlC1Fmm8O7x xaNzHCovvx4rbV3bZIK0n6BCUMzMEU4PBHNqCFNZutKUUfbN3o9BaP6+/PWdzWwlJbII +bjw== X-Gm-Message-State: ALoCoQnG5nJyEaWwzUbs8LJKjZMqgV9eAysIezn8+Xem+eDIIaUlP+Voj7lOiF7qDxICfTmZnTFp MIME-Version: 1.0 X-Received: by 10.152.203.230 with SMTP id kt6mr12434947lac.38.1423411801689; Sun, 08 Feb 2015 08:10:01 -0800 (PST) Received: by 10.112.78.3 with HTTP; Sun, 8 Feb 2015 08:10:01 -0800 (PST) In-Reply-To: <20150208.165959.1664690960227290529.mbj@tail-f.com> References: <20150208.165959.1664690960227290529.mbj@tail-f.com> Date: Sun, 8 Feb 2015 08:10:01 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] [Ladislav Lhotka] Re: yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 16:10:06 -0000 On Sun, Feb 8, 2015 at 7:59 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> What use is JSON? It is a more efficient encoding format. Period. > > For some definition of "efficient"... uncompressed JSON produces > fewer bytes than uncompressed XML, but JSON requires the receiver to > buffer everything. > good point. JSON is also a nightmare for a server to stream compared to XML. > I think the main attraction of JSON is non-technical. I think the appeal is rapid-prototyping, and that works OK except stay away from anyxml. Using input without checking it is never wise, but even worse when the data modeling language is telling you "there is no schema for this data". > > > /martin Andy > > > > > > > > > > From nobody Sun Feb 8 08:37:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF101ACD17 for ; Sun, 8 Feb 2015 08:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Flf9u_7JDigB for ; Sun, 8 Feb 2015 08:37:34 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 94F2A1ACD13 for ; Sun, 8 Feb 2015 08:37:33 -0800 (PST) Received: by labgm9 with SMTP id gm9so4544330lab.2 for ; Sun, 08 Feb 2015 08:37:32 -0800 (PST) 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:content-type; bh=wAOTMP5ntMGgcf5lf4yzveHkJhNJ1ZMZLzEnBLwu7JE=; b=Pv19+yU4O2kALKI3Msoek05cfzWqPO5aT4QA+2QnRjfT4bKZdQQFxThMtZ2SdXYcIu xrMA1iGAEj+g0xjgv1YS3bD2PATHXNLZiDSXuj/jccqhkhiEJIIrpp9q5sUZgujk3dtt QOOKFab9/TcQSBDA4JZ7Qg6C+s2qwQsSFVZ/SOGyE0QH0q7WBmxQnyzfBe2bVhuJLSjW qoozEowWbYMMThsM4XvJb2bpiBZNr82B6W6vMqYrHzrqUwIToF77tPZtxAjpYZIpeWiY CihLZfD54fs9KhLIaWdkaUtjP9FefhTsmnlkfvTrltzJP2T8NOvgbV1fKHhPy7TAk0k5 Xvzg== X-Gm-Message-State: ALoCoQmwScErWPxh3CRQ7YUEAe14bQpqGKqHgg58t9sMSUJTqfaHtuOW1tMfJ2kgDSTcUwXS8wbF MIME-Version: 1.0 X-Received: by 10.112.164.101 with SMTP id yp5mr12481196lbb.82.1423413452031; Sun, 08 Feb 2015 08:37:32 -0800 (PST) Received: by 10.112.78.3 with HTTP; Sun, 8 Feb 2015 08:37:31 -0800 (PST) In-Reply-To: References: <201502061554.t16FsnwS064052@idle.juniper.net> Date: Sun, 8 Feb 2015 08:37:31 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 16:37:36 -0000 On Sun, Feb 8, 2015 at 1:44 AM, Ladislav Lhotka wrote: > Phil Shafer writes: > >> Ladislav Lhotka writes: ...... > For the record, I am not in favor of removing anyxml in its current > form. The only problem I have with it is the name. I think it can be > useful to have a node in YANG that allows for exchanging schema-less > chunks in *any* encoding. > I agree. So here is solution proposal Y34-06. (BTW, Y34-05 was never added to the issue list). Solution Y34-06 - do not deprecate anyxml - do not add anydata (no agreement on rules) - implementations MAY restrict the XML accepted in anyxml - MAY ignore processing instructions - MAY reject mixed mode input - document in YANG 1.1 that anyxml is not considered interoperable if PIs and mixed mode XML are used - The guidelines document should say that YANG Doctors will review each use of anyxml in IETF modules > Lada Andy > >> >> For this to work via JSON, the same abilities need to exist. I >> need to put my arbitrary chunk of XML out of my database and insert >> it into my JSON data stream. When a value for banner arrives, I >> need to insert it into my database. JSON is just a means of encoding >> that data. Use of JSON doesn't invent the right to redefine that data, >> or to say that I should have been markdown, not HTML, or to say that >> the JSON encoding just won't work for banner. >> >> I continue to think that JSON needs to encode anyxml as strings. >> I can't see anything else working here. >> >> For that matter, I'm still not seeing way "anydata" isn't just "type string". >> >> If you wanted anyjson, XML would need to encode that data as a >> string. Then again, anydata and anyjson are new features, so we >> shouldn't go there. >> >> Thanks, >> Phil > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Feb 8 15:04:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E761A710D for ; Sun, 8 Feb 2015 15:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPqjmMI6kRII for ; Sun, 8 Feb 2015 15:04:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:793]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D1E1A7113 for ; Sun, 8 Feb 2015 15:04:19 -0800 (PST) Received: from BLUPR05CA0071.namprd05.prod.outlook.com (10.141.20.41) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.1.81.19; Sun, 8 Feb 2015 23:03:57 +0000 Received: from BN1BFFO11FD011.protection.gbl (2a01:111:f400:7c10::1:174) by BLUPR05CA0071.outlook.office365.com (2a01:111:e400:855::41) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Sun, 8 Feb 2015 23:03:56 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD011.mail.protection.outlook.com (10.58.144.74) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Sun, 8 Feb 2015 23:03:55 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 8 Feb 2015 15:03:54 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t18N3rW53417; Sun, 8 Feb 2015 15:03:53 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t18N3cEQ076249; Sun, 8 Feb 2015 18:03:38 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502082303.t18N3cEQ076249@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Sun, 8 Feb 2015 18:03:38 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(110136001)(53416004)(76506005)(86362001)(50986999)(54356999)(105596002)(62966003)(77156002)(46102003)(77096005)(106466001)(47776003)(92566002)(6806004)(2950100001)(87936001)(48376002)(50466002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB444; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB444; X-Forefront-PRVS: 048111149A X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB444; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2015 23:03:55.6084 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB444 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 23:04:24 -0000 Ladislav Lhotka writes: >What you put to a database is one thing and what's presented to NETCONF >clients is another. If you decide to store HTML internally, you'd need to >translate input/output from/to JSON clients to markdown. But you can >also do it the other way around: store markdown and perform the >translations for XML clients. If my data model says it's a chunk of XHTML and your server gives me markdown, someone's going to be very unhappy. >For the record, I am not in favor of removing anyxml in its current >form. The only problem I have with it is the name. I think it can be >useful to have a node in YANG that allows for exchanging schema-less >chunks in *any* encoding. anyxml isn't encoding agnostic. It specifies a chunk of XML data. The spec's fairly clear about that: The "anyxml" statement is used to represent an unknown chunk of XML. No restrictions are placed on the XML. This Thanks, Phil From nobody Sun Feb 8 15:34:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2DF1A1AE3 for ; Sun, 8 Feb 2015 15:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYcokWc-V8Qw for ; Sun, 8 Feb 2015 15:34:34 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 2C6641A1AB4 for ; Sun, 8 Feb 2015 15:34:34 -0800 (PST) Received: by labhv19 with SMTP id hv19so10168191lab.10 for ; Sun, 08 Feb 2015 15:34:32 -0800 (PST) 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:content-type; bh=j4f9xLYfpFtxeYo8X9uq5edxWAYGu6yH25aO2r41V1Y=; b=JFECGBW1vsYyWl1Dh8ITJpSzLeJjONu2r/ApZmcVYjusdWcQx8s3NB4ilC5LLI2rT4 t0CEJ9+1CId9ZJnc++yTDqBKeEN4eTxSVX573EFosPhUAENc4cgYR6VcNAwaS3vxgyFB TJPWMdbeVra3SJBaEdsM3Y0i2dfuVJ/ZY/7rmrFnHCw6F4yCRwYoVOxhI+UDHYV5Yl7G nocbZoz4tRmNcyeAyiGt+jRvrV6fLPg3rRf+Hsn2NzK/XMOFsa2AJNMD8vK15FA2fqke uPcKkGIqyS+ikkM3R7sjsfSNEFFGXN1NEeH0Tf2vun46ajM86w1nb6/+Ogij5Gco86Bo jdxA== X-Gm-Message-State: ALoCoQk15Eq9lkatLXiiKD7/V98TcQZhYiRUq8Td7JDsG8grgSeAJaANy0KFdaArCmlZ2DElk1P6 MIME-Version: 1.0 X-Received: by 10.112.164.101 with SMTP id yp5mr13704795lbb.82.1423438472675; Sun, 08 Feb 2015 15:34:32 -0800 (PST) Received: by 10.112.78.3 with HTTP; Sun, 8 Feb 2015 15:34:32 -0800 (PST) In-Reply-To: <201502082303.t18N3cEQ076249@idle.juniper.net> References: <201502082303.t18N3cEQ076249@idle.juniper.net> Date: Sun, 8 Feb 2015 15:34:32 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 23:34:37 -0000 On Sun, Feb 8, 2015 at 3:03 PM, Phil Shafer wrote: > Ladislav Lhotka writes: >>What you put to a database is one thing and what's presented to NETCONF >>clients is another. If you decide to store HTML internally, you'd need to >>translate input/output from/to JSON clients to markdown. But you can >>also do it the other way around: store markdown and perform the >>translations for XML clients. > > If my data model says it's a chunk of XHTML and your server gives me > markdown, someone's going to be very unhappy. > >>For the record, I am not in favor of removing anyxml in its current >>form. The only problem I have with it is the name. I think it can be >>useful to have a node in YANG that allows for exchanging schema-less >>chunks in *any* encoding. > > anyxml isn't encoding agnostic. It specifies a chunk of XML data. > The spec's fairly clear about that: > > The "anyxml" statement is used to represent an unknown chunk of XML. > No restrictions are placed on the XML. This > I agree RFC 6020 and 6241 do not prohibit mixed XML context, except in get, get-config filtering. Since very few implementations of anyxml-as-data-node exist in the wild, it is a non-problem I guess. If we cared about advancing YANG to be a full standard, then it would matter. However, it is hard to ignore the problem that we claim anyxml-as-data-node is mandatory to implement in all servers, now that RESTCONF (and CoMI) are being added to the mix. Clearly we cannot have encoding-specific data nodes if we want YANG to be encoding-independent. Vendors will want to support a unified data node implementation somehow, no matter what the standard says. > Thanks, > Phil > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sun Feb 8 16:08:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA911A7003 for ; Sun, 8 Feb 2015 16:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVmKo2lYDk-y for ; Sun, 8 Feb 2015 16:08:29 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 EB0601A70FD for ; Sun, 8 Feb 2015 16:08:27 -0800 (PST) Received: by labhz20 with SMTP id hz20so10256951lab.0 for ; Sun, 08 Feb 2015 16:08:26 -0800 (PST) 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:content-type; bh=ZLcDVldphTs4Lt/GnCy+gpnZmm2hJWddFa+Z7Iv2Kmg=; b=NxWt8jbBbTFggXF3K48cX4hxx15Rx4vJNOEoIO+ykoeQOVeY3eC4I/daF7uPxvZOlp x4Z+9MtekH3viThNKmdohzOOZ3SK2cSe42Pw2r+EOWXtahGnNfiDpqVbGrr/3a3151bs fWdTAkzeJOBPjYPty8kWi4FgmP+at2CNH3L6bpEdTqXiPle/l7tpYt+4zOKpLOMGFwPh oMR+WxDkuIZCRR/WjYlVcGU9LcvwxhBg5rUQB2VPnc1PpHivaGofiXDM/Tk+ARFP6uCV QBJXq5yE2h81xE3fASjYvfEVKXdspmguMMXoJCyVsH7K1ly0UpQoUetb2DULFrtHthdr +xJQ== X-Gm-Message-State: ALoCoQmIvS9B0LEyenPcoVamVvbwP1IDiJpheCPzPQNC1TIW1ihfqdN2/WwvflZ9DP8G0+dvBaYe MIME-Version: 1.0 X-Received: by 10.112.137.196 with SMTP id qk4mr13969574lbb.33.1423440506485; Sun, 08 Feb 2015 16:08:26 -0800 (PST) Received: by 10.112.78.3 with HTTP; Sun, 8 Feb 2015 16:08:26 -0800 (PST) In-Reply-To: References: <201502082303.t18N3cEQ076249@idle.juniper.net> Date: Sun, 8 Feb 2015 16:08:26 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 00:08:31 -0000 On Sun, Feb 8, 2015 at 3:34 PM, Andy Bierman wrote: > On Sun, Feb 8, 2015 at 3:03 PM, Phil Shafer wrote: >> Ladislav Lhotka writes: >>>What you put to a database is one thing and what's presented to NETCONF >>>clients is another. If you decide to store HTML internally, you'd need to >>>translate input/output from/to JSON clients to markdown. But you can >>>also do it the other way around: store markdown and perform the >>>translations for XML clients. >> >> If my data model says it's a chunk of XHTML and your server gives me >> markdown, someone's going to be very unhappy. >> >>>For the record, I am not in favor of removing anyxml in its current >>>form. The only problem I have with it is the name. I think it can be >>>useful to have a node in YANG that allows for exchanging schema-less >>>chunks in *any* encoding. >> >> anyxml isn't encoding agnostic. It specifies a chunk of XML data. >> The spec's fairly clear about that: >> >> The "anyxml" statement is used to represent an unknown chunk of XML. >> No restrictions are placed on the XML. This >> > > I agree RFC 6020 and 6241 do not prohibit mixed XML context, > except in get, get-config filtering. > > Since very few implementations of anyxml-as-data-node exist in the wild, > it is a non-problem I guess. If we cared about advancing YANG > to be a full standard, then it would matter. > > However, it is hard to ignore the problem that we claim anyxml-as-data-node > is mandatory to implement in all servers, now that RESTCONF (and CoMI) > are being added to the mix. Clearly we cannot have encoding-specific data nodes > if we want YANG to be encoding-independent. Vendors will want to support > a unified data node implementation somehow, no matter what the standard says. > I do not think processing instructions are a problem. XML parsers handle them. RFC 6241, sec. 3.2 says: Document type declarations (see Section 2.8 of [W3C.REC-xml-20001006]) MUST NOT appear in NETCONF content. The only problem seems to be mixed mode because it is ordered, so JSON objects need to be encoded as arrays instead. An XML parser will treat a mixed text node as an unnamed string node, and JSON allows zero-length identifier names:

This is very sensitive data

I'm serious, dude

 (Not sure if the JSON is right ;-)) { "web-banner" : [ "p" : [ "": "This is", "em": "very", "": "sensitive data" ], "img": [null], "@img": { "src":"mister-yuk.png" }, "p": "I'm serious, dud" ] } I think even mixed XML can be encoded in JSON in a standard way. > >> Thanks, >> Phil >> Andy From nobody Sun Feb 8 17:28:34 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF941A6FEE for ; Sun, 8 Feb 2015 17:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQG9_C6ralAV for ; Sun, 8 Feb 2015 17:28:31 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5DCF1A1B7F for ; Sun, 8 Feb 2015 17:28:31 -0800 (PST) Received: from CO2PR05CA019.namprd05.prod.outlook.com (10.141.241.147) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.81.19; Mon, 9 Feb 2015 01:28:30 +0000 Received: from BY2FFO11FD034.protection.gbl (2a01:111:f400:7c0c::105) by CO2PR05CA019.outlook.office365.com (2a01:111:e400:1429::19) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Mon, 9 Feb 2015 01:28:29 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD034.mail.protection.outlook.com (10.1.14.219) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Mon, 9 Feb 2015 01:28:29 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 8 Feb 2015 17:28:28 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t191SRW11479; Sun, 8 Feb 2015 17:28:27 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t191SCow076671; Sun, 8 Feb 2015 20:28:13 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502090128.t191SCow076671@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Sun, 8 Feb 2015 20:28:12 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(2950100001)(77096005)(47776003)(76506005)(53416004)(50986999)(561944003)(54356999)(6806004)(86362001)(46102003)(110136001)(106466001)(62966003)(92566002)(48376002)(50466002)(77156002)(105596002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB440; X-Forefront-PRVS: 04825EA361 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2015 01:28:29.1961 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 01:28:33 -0000 Andy Bierman writes: >Solution Y34-06 > - do not deprecate anyxml > - do not add anydata (no agreement on rules) > - implementations MAY restrict the XML accepted in anyxml > - MAY ignore processing instructions > - MAY reject mixed mode input > - document in YANG 1.1 that anyxml is not considered interoperable > if PIs and mixed mode XML are used This is essenially "be aware that server implementations might not implement all of YANG". > - The guidelines document should say that YANG Doctors will review > each use of anyxml in IETF modules This part I completely agree with. Here's my proposal: Solution Y34-07 - do not change YANG - Change the JSON encoding rules to encode anyxml nodes as strings - The guidelines document should say that YANG Doctors will review each use of anyxml in IETF modules (lifted from Y34-06) Thanks, Phil From nobody Sun Feb 8 17:37:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE22A1A6FEE for ; Sun, 8 Feb 2015 17:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5UtVyrkF5f5 for ; Sun, 8 Feb 2015 17:34:48 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E17B01A1B7F for ; Sun, 8 Feb 2015 17:34:46 -0800 (PST) Received: from BL2PR05CA0047.namprd05.prod.outlook.com (10.255.226.47) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.81.19; Mon, 9 Feb 2015 01:34:24 +0000 Received: from BY2FFO11FD036.protection.gbl (2a01:111:f400:7c0c::115) by BL2PR05CA0047.outlook.office365.com (2a01:111:e400:c04::47) with Microsoft SMTP Server (TLS) id 15.1.75.20 via Frontend Transport; Mon, 9 Feb 2015 01:34:24 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD036.mail.protection.outlook.com (10.1.14.221) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Mon, 9 Feb 2015 01:34:24 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 8 Feb 2015 17:34:23 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t191YNW13600; Sun, 8 Feb 2015 17:34:23 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t191Y8Is076787; Sun, 8 Feb 2015 20:34:08 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502090134.t191Y8Is076787@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Sun, 8 Feb 2015 20:34:08 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(46102003)(110136001)(106466001)(86362001)(105596002)(87936001)(92566002)(50466002)(48376002)(62966003)(77156002)(2950100001)(50986999)(53416004)(6806004)(54356999)(47776003)(77096005)(76506005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BN1PR05MB440; X-Forefront-PRVS: 04825EA361 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2015 01:34:24.3700 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 01:34:50 -0000 Andy Bierman writes: >However, it is hard to ignore the problem that we claim anyxml-as-data-node >is mandatory to implement in all servers, now that RESTCONF (and CoMI) >are being added to the mix. Clearly we cannot have encoding-specific data nodes >if we want YANG to be encoding-independent. Vendors will want to support >a unified data node implementation somehow, no matter what the standard says. anyxml is not "encoding-specific data". The data is a chunk of XML. When you go to encode it in XML, the encoding is trivial, basically something simple like: encoded = data; When you go to encode it in JSON, it's also trivial if you do it as a string. All you need to do is escape any quotes to satisfy JSON: encoded = json_string_escape(data); The data itself is not tied to the encoding. It's a chunk of XML. There's nothing magic going on that ties "the data is XML" to "the encoding is XML", except that the encoding is slightly more trivial. Thanks, Phil From nobody Sun Feb 8 17:38:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B1E1A1B7F for ; Sun, 8 Feb 2015 17:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmSOT_xVOCsu for ; Sun, 8 Feb 2015 17:38:41 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A191A0673 for ; Sun, 8 Feb 2015 17:38:41 -0800 (PST) Received: from CO2PR05CA025.namprd05.prod.outlook.com (10.141.241.153) by BLUPR05MB436.namprd05.prod.outlook.com (10.141.27.152) with Microsoft SMTP Server (TLS) id 15.1.75.20; Mon, 9 Feb 2015 01:38:18 +0000 Received: from BY2FFO11FD045.protection.gbl (2a01:111:f400:7c0c::119) by CO2PR05CA025.outlook.office365.com (2a01:111:e400:1429::25) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Mon, 9 Feb 2015 01:38:17 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD045.mail.protection.outlook.com (10.1.15.177) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Mon, 9 Feb 2015 01:38:17 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 8 Feb 2015 17:38:16 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t191cFW15587; Sun, 8 Feb 2015 17:38:15 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t191c1eG076852; Sun, 8 Feb 2015 20:38:01 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502090138.t191c1eG076852@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Sun, 8 Feb 2015 20:38:01 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(164054003)(92566002)(47776003)(76506005)(53416004)(50466002)(48376002)(77156002)(62966003)(77096005)(110136001)(106466001)(2950100001)(46102003)(50986999)(105596002)(54356999)(18206015028)(87936001)(86362001)(19580395003)(6806004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB436; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB436; X-Forefront-PRVS: 04825EA361 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2015 01:38:17.1272 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB436 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 01:38:44 -0000 Andy Bierman writes: >(Not sure if the JSON is right ;-)) > { "web-banner" : [ > "p" : [ > "": "This is", > "em": "very", > "": "sensitive data" > ], > "img": [null], > "@img": { > "src":"mister-yuk.png" > }, > "p": "I'm serious, dud" > ] > } >I think even mixed XML can be encoded in JSON in a standard way. I picked this example because this encoding doesn't work. JSON allows but doesn't like multiple instances of the same name. I-JSON makes it invalid. The second "p" breaks this encoding. On the other hand: "web-banner": '

This is very sensitive data

I'm serious, dude

' works fine and doesn't mix layering, require AI-based conversions, or tax the implementor's brains. Thanks, Phil From nobody Mon Feb 9 00:19:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD6D1A0087 for ; Mon, 9 Feb 2015 00:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnnO-6ywz63v for ; Mon, 9 Feb 2015 00:18:36 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 465BB1A00A9 for ; Mon, 9 Feb 2015 00:18:36 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 494F41280453; Mon, 9 Feb 2015 09:18:35 +0100 (CET) Date: Mon, 09 Feb 2015 09:18:38 +0100 (CET) Message-Id: <20150209.091838.2239188145158636181.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201502090128.t191SCow076671@idle.juniper.net> References: <201502090128.t191SCow076671@idle.juniper.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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 08:18:38 -0000 Phil Shafer wrote: > Andy Bierman writes: > >Solution Y34-06 > > - do not deprecate anyxml > > - do not add anydata (no agreement on rules) > > - implementations MAY restrict the XML accepted in anyxml > > - MAY ignore processing instructions > > - MAY reject mixed mode input > > - document in YANG 1.1 that anyxml is not considered interoperable > > if PIs and mixed mode XML are used > > This is essenially "be aware that server implementations might not > implement all of YANG". > > > - The guidelines document should say that YANG Doctors will review > > each use of anyxml in IETF modules > > This part I completely agree with. > > Here's my proposal: > > Solution Y34-07 > - do not change YANG > - Change the JSON encoding rules to encode anyxml nodes as strings > - The guidelines document should say that YANG Doctors will review > each use of anyxml in IETF modules (lifted from Y34-06) This is fine (*) as one part of the solution, but by itself it isn't sufficient. The problem is illustrated in YANG PATCH, which is supposed to work for both XML and JSON. If YANG PATCH uses anyxml, it means that the JSON encoding of a YANG PATCH is pretty much useless (since the edit would be expressed as XML, but the reast in JSON). This is why we have suggested to add anydata, which YANG PATCH then should use instead of anyxml. (*) Actually it is not trivial to simply encode an anxml element as a string b/c of the namespace prefix issue (prefixes may have been declared above the anyxml element, but used in the anyxml). /martin From nobody Mon Feb 9 00:21:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF871A00A9 for ; Mon, 9 Feb 2015 00:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQdTSprbOxc0 for ; Mon, 9 Feb 2015 00:20:24 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE7B1A0097 for ; Mon, 9 Feb 2015 00:20:24 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id AA0AD1CC02A7; Mon, 9 Feb 2015 09:20:24 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <201502061554.t16FsnwS064052@idle.juniper.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 09 Feb 2015 09:20:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 08:20:28 -0000 Andy Bierman writes: > On Sun, Feb 8, 2015 at 1:44 AM, Ladislav Lhotka wrote: >> Phil Shafer writes: >> >>> Ladislav Lhotka writes: > ...... >> For the record, I am not in favor of removing anyxml in its current >> form. The only problem I have with it is the name. I think it can be >> useful to have a node in YANG that allows for exchanging schema-less >> chunks in *any* encoding. >> > > I agree. > So here is solution proposal Y34-06. > (BTW, Y34-05 was never added to the issue list). > > > Solution Y34-06 > - do not deprecate anyxml > - do not add anydata (no agreement on rules) In this case I'd suggest to rename anyxml to anydata so as to open the possibility of sending schema-less chunks in JSON and other encodings - re-using anyxml for this purpose is possible but the name is misleading. > - implementations MAY restrict the XML accepted in anyxml > - MAY ignore processing instructions > - MAY reject mixed mode input I think it is a data model, rather than implementation, that could formulate such restrictions. > - document in YANG 1.1 that anyxml is not considered interoperable > if PIs and mixed mode XML are used It depends on the definition of interoperability. In NETCONF, all this can be perfectly interoperable. It is about interoperability in protocols that support multiple encodings. I'd say it is the responsibility of a data modeller to define mappings between whatever formats that need to be supported. > - The guidelines document should say that YANG Doctors will review > each use of anyxml in IETF modules It should be sufficient to give guidelines - it then goes without saying that it should be part of the review by YANG doctors. Lada > > > >> Lada > > > Andy > >> >>> >>> For this to work via JSON, the same abilities need to exist. I >>> need to put my arbitrary chunk of XML out of my database and insert >>> it into my JSON data stream. When a value for banner arrives, I >>> need to insert it into my database. JSON is just a means of encoding >>> that data. Use of JSON doesn't invent the right to redefine that data, >>> or to say that I should have been markdown, not HTML, or to say that >>> the JSON encoding just won't work for banner. >>> >>> I continue to think that JSON needs to encode anyxml as strings. >>> I can't see anything else working here. >>> >>> For that matter, I'm still not seeing way "anydata" isn't just "type string". >>> >>> If you wanted anyjson, XML would need to encode that data as a >>> string. Then again, anydata and anyjson are new features, so we >>> shouldn't go there. >>> >>> Thanks, >>> Phil >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> 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 Feb 9 00:29:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5B51A0091; Mon, 9 Feb 2015 00:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqiFFcAlpwkG; Mon, 9 Feb 2015 00:29:41 -0800 (PST) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBB91A007E; Mon, 9 Feb 2015 00:29:39 -0800 (PST) Received: from Macintosh-6.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id q8VY1p00E3vXPcr018VZeP; Mon, 09 Feb 2015 09:29:36 +0100 Message-ID: <54D86FEC.6030004@bwijnen.net> Date: Mon, 09 Feb 2015 09:29:32 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Susan Hares , "'Acee Lindem (acee)'" , 'idr wg' References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> <54D5D041.5070307@bwijnen.net> <003001d042f3$22c77ed0$68567c70$@ndzh.com> In-Reply-To: <003001d042f3$22c77ed0$68567c70$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Rtg-yang-coord@ietf.org, 'NETCONF' , netmod@ietf.org Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 08:29:43 -0000 On 07/02/15 17:28, Susan Hares wrote: > Bert: > > 10 - 11:30 am ET. My apologies for missing it. No problem. That time is probably difficult or impossible for me. Bert > Sue > > -----Original Message----- > From: Acee Lindem (acee) [mailto:acee@cisco.com] > Sent: Saturday, February 07, 2015 9:48 AM > To: Bert Wijnen (IETF); Susan Hares; idr wg > Cc: Rtg-yang-coord@ietf.org; NETCONF; netmod@ietf.org > Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim > 2/9 - BGP Yang Modules > > Hi Bert, > > If you look at the WebEx, it is 10 AM EST (GMT - 5). > > Acee > > On 2/7/15, 2:43 AM, "Bert Wijnen (IETF)" wrote: > >> On 06/02/15 23:42, Susan Hares wrote: >>> Agenda: (75 minutes 10:00 - 11:15am) >> any specifics on time zone? >> >> we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? >> >> Bert >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > From nobody Mon Feb 9 00:41:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D781A00B8 for ; Mon, 9 Feb 2015 00:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDUrv3mysrHY for ; Mon, 9 Feb 2015 00:41:12 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CFB411A00AE for ; Mon, 9 Feb 2015 00:41:11 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E99371CC02A7; Mon, 9 Feb 2015 09:41:12 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150208.165959.1664690960227290529.mbj@tail-f.com> References: <20150208.165959.1664690960227290529.mbj@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 09 Feb 2015 09:41:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Ladislav Lhotka] Re: yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 08:41:13 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> What use is JSON? It is a more efficient encoding format. Period. > > For some definition of "efficient"... uncompressed JSON produces > fewer bytes than uncompressed XML, but JSON requires the receiver to > buffer everything. > > I think the main attraction of JSON is non-technical. I disagree. It is actually the API that's the main attraction. For example, look at Python: >>> import json >>> json.dumps(['foo', {'bar': ('baz', None, 1.0, 2)}]) '["foo", {"bar": ["baz", null, 1.0, 2]}]' Compare this to XML where you have to set up additional structures or callback functions. Libraries like libxml2 are relatively bulky and still have gaps and problems. BTW, my (technical) colleagues are now designing a new YAML-based configuration format for the Knot DNS server, and a special remote configuration protocol - despite the fact that I've been harassing them with NETCONF and YANG for several years. And they refused NETCONF specifically because of the fact it is limited to XML. Lada > > > /martin > > > > > > > > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 9 01:02:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798031A00FD for ; Mon, 9 Feb 2015 00:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIoCAZCp9c-M for ; Mon, 9 Feb 2015 00:59:27 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 36D1A1A00F3 for ; Mon, 9 Feb 2015 00:59:24 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id u10so15019894lbd.7 for ; Mon, 09 Feb 2015 00:59:22 -0800 (PST) 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:content-type; bh=7Gm+jsLhObgwfXYtEuS20xUyOgrFgt0FAfqNge7kraI=; b=VWuaKoRqXy9rwqqOnAakgLI1rSWqjddheHSuOhc6hD+QZh/W8prFYPAx8tCN1h1zr2 fEGgelKkd8aHdR3blawEiabJ9YuwwT6+Cd77Zl4l+1kvL1HCXo5iKvwInvKRuaygYr7P LoNZkDh5nvqCqrk718Zfzu2xjReptmydYhNukaa6gZVIGlmKFT8ctK+NI3/P6RgszZbP xMmrScGu+L7roMxnrJlk05oiJgczF2fFYHyigHvV4ZfE8teydd6eXtesIiR+pDVWXYwV G0CHPyqhwwM/Df8TtHLlgVa3bQ66dF0KibH1/UOG2Ct7G+TgI6yFxkGPzanyBfd/r6gv zKlA== X-Gm-Message-State: ALoCoQlHNC8QQa2mkXGw9RIuNqyF5pXEl6xAKPtOVqaPuvnJ+kCFA2vkzM5uu5mHgdbUIXUJAnSv MIME-Version: 1.0 X-Received: by 10.152.5.101 with SMTP id r5mr15362840lar.33.1423472362619; Mon, 09 Feb 2015 00:59:22 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 9 Feb 2015 00:59:22 -0800 (PST) In-Reply-To: <20150209.091838.2239188145158636181.mbj@tail-f.com> References: <201502090128.t191SCow076671@idle.juniper.net> <20150209.091838.2239188145158636181.mbj@tail-f.com> Date: Mon, 9 Feb 2015 00:59:22 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 08:59:29 -0000 On Mon, Feb 9, 2015 at 12:18 AM, Martin Bjorklund wrote: > Phil Shafer wrote: >> Andy Bierman writes: >> >Solution Y34-06 >> > - do not deprecate anyxml >> > - do not add anydata (no agreement on rules) >> > - implementations MAY restrict the XML accepted in anyxml >> > - MAY ignore processing instructions >> > - MAY reject mixed mode input >> > - document in YANG 1.1 that anyxml is not considered interoperable >> > if PIs and mixed mode XML are used >> >> This is essenially "be aware that server implementations might not >> implement all of YANG". >> Isn't this already the case? Why is it that not all servers fully support anyxml? >> > - The guidelines document should say that YANG Doctors will review >> > each use of anyxml in IETF modules >> >> This part I completely agree with. >> >> Here's my proposal: >> >> Solution Y34-07 >> - do not change YANG >> - Change the JSON encoding rules to encode anyxml nodes as strings >> - The guidelines document should say that YANG Doctors will review >> each use of anyxml in IETF modules (lifted from Y34-06) > > This is fine (*) as one part of the solution, but by itself it isn't > sufficient. > > The problem is illustrated in YANG PATCH, which is supposed to work > for both XML and JSON. If YANG PATCH uses anyxml, it means that the > JSON encoding of a YANG PATCH is pretty much useless (since the edit > would be expressed as XML, but the reast in JSON). > > This is why we have suggested to add anydata, which YANG PATCH then > should use instead of anyxml. > I strongly object to making YANG Patch YANG 1.1 only. I would rather drop JSON support. > (*) Actually it is not trivial to simply encode an anxml element as a > string b/c of the namespace prefix issue (prefixes may have been > declared above the anyxml element, but used in the anyxml). > good point > > /martin Andy From nobody Mon Feb 9 01:04:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13E01A0115 for ; Mon, 9 Feb 2015 00:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 IWlSrznRCINH for ; Mon, 9 Feb 2015 00:59:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C0A1A0102 for ; Mon, 9 Feb 2015 00:59:27 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 4479D141614; Mon, 9 Feb 2015 09:59:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423472366; bh=jnn4HSbhdt3ARsSq0o373INpKynC2ccR2tO8J3plung=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PGo+76pL2UZ181RI3VTEjEnwXalKxke7eLo9TdtCOlzSwoPjCX5XogQ3FkIwnZYD0 PR8G4GASU8IgoeLKFJ5M2FazAeJbr7e7qbP7wloEuzOgCm2PlwURYOnvm7t5GX+YWI ESBUqsqdRxHw2xvqEynwaFmV68eDDjAWm0f9CIes= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150209.091838.2239188145158636181.mbj@tail-f.com> Date: Mon, 9 Feb 2015 09:59:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201502090128.t191SCow076671@idle.juniper.net> <20150209.091838.2239188145158636181.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 08:59:31 -0000 > On 09 Feb 2015, at 09:18, Martin Bjorklund wrote: >=20 > Phil Shafer wrote: >> Andy Bierman writes: >>> Solution Y34-06 >>> - do not deprecate anyxml >>> - do not add anydata (no agreement on rules) >>> - implementations MAY restrict the XML accepted in anyxml >>> - MAY ignore processing instructions >>> - MAY reject mixed mode input >>> - document in YANG 1.1 that anyxml is not considered interoperable >>> if PIs and mixed mode XML are used >>=20 >> This is essenially "be aware that server implementations might not >> implement all of YANG". >>=20 >>> - The guidelines document should say that YANG Doctors will review >>> each use of anyxml in IETF modules >>=20 >> This part I completely agree with. >>=20 >> Here's my proposal: >>=20 >> Solution Y34-07 >> - do not change YANG >> - Change the JSON encoding rules to encode anyxml nodes as strings >> - The guidelines document should say that YANG Doctors will review >> each use of anyxml in IETF modules (lifted from Y34-06) >=20 > This is fine (*) as one part of the solution, but by itself it isn't > sufficient. >=20 > The problem is illustrated in YANG PATCH, which is supposed to work > for both XML and JSON. If YANG PATCH uses anyxml, it means that the > JSON encoding of a YANG PATCH is pretty much useless (since the edit > would be expressed as XML, but the reast in JSON). >=20 > This is why we have suggested to add anydata, which YANG PATCH then > should use instead of anyxml. So how about (i) renaming =E2=80=9Canyxml=E2=80=9D to =E2=80=9Canydata=E2=80= =9D and extending it to represent schema-less chunks in any encoding = with no a priori guarantee of a loss-less mapping, and (ii) introducing = =E2=80=9Croot=E2=80=9D for embedded YANG schemas with defined mappings = between all supported encodings? >=20 > (*) Actually it is not trivial to simply encode an anxml element as a > string b/c of the namespace prefix issue (prefixes may have been > declared above the anyxml element, but used in the anyxml). +1 Lada >=20 >=20 > /martin >=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 Feb 9 02:08:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D861A01E7 for ; Mon, 9 Feb 2015 02:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 fH2Y25MniVeR for ; Mon, 9 Feb 2015 02:08:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248411A0194 for ; Mon, 9 Feb 2015 02:08:44 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 51F49140C7B; Mon, 9 Feb 2015 11:08:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423476522; bh=ubJ1WtAabqhc93nLXmoZyjwFcDYCX3DGVd7mjLUIG40=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=xWXE3ekgZMq+RDUDTzdr8JUcAnJ3WIbuK1HYExW15kWeQEyu0n7pZowEh/thQyplR WN2g/bOmIrqt5nzxbfX4OEq0ECT9iVXXCkWi2gh5nU3BPhBeJGBaS1A3ZBroNTEdqu Gha+0IcBocNTlsyR/yFrYeWmsUoGoIjzanrrWIA4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 9 Feb 2015 11:08:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201502090128.t191SCow076671@idle.juniper.net> <20150209.091838.2239188145158636181.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 10:08:46 -0000 > On 09 Feb 2015, at 09:59, Andy Bierman wrote: >=20 > On Mon, Feb 9, 2015 at 12:18 AM, Martin Bjorklund = wrote: >> Phil Shafer wrote: >>> Andy Bierman writes: >>>> Solution Y34-06 >>>> - do not deprecate anyxml >>>> - do not add anydata (no agreement on rules) >>>> - implementations MAY restrict the XML accepted in anyxml >>>> - MAY ignore processing instructions >>>> - MAY reject mixed mode input >>>> - document in YANG 1.1 that anyxml is not considered = interoperable >>>> if PIs and mixed mode XML are used >>>=20 >>> This is essenially "be aware that server implementations might not >>> implement all of YANG". >>>=20 >=20 > Isn't this already the case? > Why is it that not all servers fully support anyxml? >=20 >=20 >>>> - The guidelines document should say that YANG Doctors will = review >>>> each use of anyxml in IETF modules >>>=20 >>> This part I completely agree with. >>>=20 >>> Here's my proposal: >>>=20 >>> Solution Y34-07 >>> - do not change YANG >>> - Change the JSON encoding rules to encode anyxml nodes as strings >>> - The guidelines document should say that YANG Doctors will review >>> each use of anyxml in IETF modules (lifted from Y34-06) >>=20 >> This is fine (*) as one part of the solution, but by itself it isn't >> sufficient. >>=20 >> The problem is illustrated in YANG PATCH, which is supposed to work >> for both XML and JSON. If YANG PATCH uses anyxml, it means that the >> JSON encoding of a YANG PATCH is pretty much useless (since the edit >> would be expressed as XML, but the reast in JSON). >>=20 >> This is why we have suggested to add anydata, which YANG PATCH then >> should use instead of anyxml. >>=20 >=20 >=20 > I strongly object to making YANG Patch YANG 1.1 only. > I would rather drop JSON support. I think you can continue using anyxml in YANG PATCH, IMO there is = nothing wrong with it. If the module gets upgraded to YANG 1.1, the = descriptions could perhaps be made shorter, and that=E2=80=99s all. Lada=20 >=20 >> (*) Actually it is not trivial to simply encode an anxml element as a >> string b/c of the namespace prefix issue (prefixes may have been >> declared above the anyxml element, but used in the anyxml). >>=20 >=20 > good point >=20 >>=20 >> /martin >=20 > Andy >=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 Feb 9 04:56:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD91A0383 for ; Mon, 9 Feb 2015 04:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1oJn1uV9-KO for ; Mon, 9 Feb 2015 04:56:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2170F1A037F for ; Mon, 9 Feb 2015 04:56:52 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 339721280C19; Mon, 9 Feb 2015 13:56:51 +0100 (CET) Date: Mon, 09 Feb 2015 13:56:51 +0100 (CET) Message-Id: <20150209.135651.1017394851894918029.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20150209.091838.2239188145158636181.mbj@tail-f.com> 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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 12:56:54 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDkgRmVi IDIwMTUsIGF0IDA5OjU5LCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gT24gTW9uLCBGZWIgOSwgMjAxNSBhdCAxMjoxOCBBTSwgTWFydGluIEJqb3Jr bHVuZCA8bWJqQHRhaWwtZi5jb20+DQo+ID4gd3JvdGU6DQo+ID4+IFBoaWwgU2hhZmVyIDxwaGls QGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPj4+IEFuZHkgQmllcm1hbiB3cml0ZXM6DQo+ID4+Pj4g U29sdXRpb24gWTM0LTA2DQo+ID4+Pj4gICAtIGRvIG5vdCBkZXByZWNhdGUgYW55eG1sDQo+ID4+ Pj4gICAtIGRvIG5vdCBhZGQgYW55ZGF0YSAobm8gYWdyZWVtZW50IG9uIHJ1bGVzKQ0KPiA+Pj4+ ICAgLSBpbXBsZW1lbnRhdGlvbnMgTUFZIHJlc3RyaWN0IHRoZSBYTUwgYWNjZXB0ZWQgaW4gYW55 eG1sDQo+ID4+Pj4gICAgICAtIE1BWSBpZ25vcmUgcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnMNCj4g Pj4+PiAgICAgIC0gTUFZIHJlamVjdCBtaXhlZCBtb2RlIGlucHV0DQo+ID4+Pj4gICAtIGRvY3Vt ZW50IGluIFlBTkcgMS4xIHRoYXQgYW55eG1sIGlzIG5vdCBjb25zaWRlcmVkIGludGVyb3BlcmFi bGUNCj4gPj4+PiAgICAgaWYgUElzIGFuZCBtaXhlZCBtb2RlIFhNTCBhcmUgdXNlZA0KPiA+Pj4g DQo+ID4+PiBUaGlzIGlzIGVzc2VuaWFsbHkgImJlIGF3YXJlIHRoYXQgc2VydmVyIGltcGxlbWVu dGF0aW9ucyBtaWdodCBub3QNCj4gPj4+IGltcGxlbWVudCBhbGwgb2YgWUFORyIuDQo+ID4+PiAN Cj4gPiANCj4gPiBJc24ndCB0aGlzIGFscmVhZHkgdGhlIGNhc2U/DQo+ID4gV2h5IGlzIGl0IHRo YXQgbm90IGFsbCBzZXJ2ZXJzIGZ1bGx5IHN1cHBvcnQgYW55eG1sPw0KPiA+IA0KPiA+IA0KPiA+ Pj4+ICAgLSBUaGUgZ3VpZGVsaW5lcyBkb2N1bWVudCBzaG91bGQgc2F5IHRoYXQgWUFORyBEb2N0 b3JzIHdpbGwgcmV2aWV3DQo+ID4+Pj4gICAgIGVhY2ggdXNlIG9mIGFueXhtbCBpbiBJRVRGIG1v ZHVsZXMNCj4gPj4+IA0KPiA+Pj4gVGhpcyBwYXJ0IEkgY29tcGxldGVseSBhZ3JlZSB3aXRoLg0K PiA+Pj4gDQo+ID4+PiBIZXJlJ3MgbXkgcHJvcG9zYWw6DQo+ID4+PiANCj4gPj4+IFNvbHV0aW9u IFkzNC0wNw0KPiA+Pj4gIC0gZG8gbm90IGNoYW5nZSBZQU5HDQo+ID4+PiAgLSBDaGFuZ2UgdGhl IEpTT04gZW5jb2RpbmcgcnVsZXMgdG8gZW5jb2RlIGFueXhtbCBub2RlcyBhcyBzdHJpbmdzDQo+ ID4+PiAgLSBUaGUgZ3VpZGVsaW5lcyBkb2N1bWVudCBzaG91bGQgc2F5IHRoYXQgWUFORyBEb2N0 b3JzIHdpbGwgcmV2aWV3DQo+ID4+PiAgICBlYWNoIHVzZSBvZiBhbnl4bWwgaW4gSUVURiBtb2R1 bGVzIChsaWZ0ZWQgZnJvbSBZMzQtMDYpDQo+ID4+IA0KPiA+PiBUaGlzIGlzIGZpbmUgKCopIGFz IG9uZSBwYXJ0IG9mIHRoZSBzb2x1dGlvbiwgYnV0IGJ5IGl0c2VsZiBpdCBpc24ndA0KPiA+PiBz dWZmaWNpZW50Lg0KPiA+PiANCj4gPj4gVGhlIHByb2JsZW0gaXMgaWxsdXN0cmF0ZWQgaW4gWUFO RyBQQVRDSCwgd2hpY2ggaXMgc3VwcG9zZWQgdG8gd29yaw0KPiA+PiBmb3IgYm90aCBYTUwgYW5k IEpTT04uICBJZiBZQU5HIFBBVENIIHVzZXMgYW55eG1sLCBpdCBtZWFucyB0aGF0IHRoZQ0KPiA+ PiBKU09OIGVuY29kaW5nIG9mIGEgWUFORyBQQVRDSCBpcyBwcmV0dHkgbXVjaCB1c2VsZXNzIChz aW5jZSB0aGUgZWRpdA0KPiA+PiB3b3VsZCBiZSBleHByZXNzZWQgYXMgWE1MLCBidXQgdGhlIHJl YXN0IGluIEpTT04pLg0KPiA+PiANCj4gPj4gVGhpcyBpcyB3aHkgd2UgaGF2ZSBzdWdnZXN0ZWQg dG8gYWRkIGFueWRhdGEsIHdoaWNoIFlBTkcgUEFUQ0ggdGhlbg0KPiA+PiBzaG91bGQgdXNlIGlu c3RlYWQgb2YgYW55eG1sLg0KPiA+PiANCj4gPiANCj4gPiANCj4gPiBJIHN0cm9uZ2x5IG9iamVj dCB0byBtYWtpbmcgWUFORyBQYXRjaCBZQU5HIDEuMSBvbmx5Lg0KPiA+IEkgd291bGQgcmF0aGVy IGRyb3AgSlNPTiBzdXBwb3J0Lg0KPiANCj4gSSB0aGluayB5b3UgY2FuIGNvbnRpbnVlIHVzaW5n IGFueXhtbCBpbiBZQU5HIFBBVENILCBJTU8gdGhlcmUgaXMNCj4gbm90aGluZyB3cm9uZyB3aXRo IGl0LiBJZiB0aGUgbW9kdWxlIGdldHMgdXBncmFkZWQgdG8gWUFORyAxLjEsIHRoZQ0KPiBkZXNj cmlwdGlvbnMgY291bGQgcGVyaGFwcyBiZSBtYWRlIHNob3J0ZXIsIGFuZCB0aGF04oCZcyBhbGwu DQoNCkkgdGhpbmsgeW91J3JlIG1pc3NpbmcgdGhlIGNvbnRleHQuICBQaGlsIHN1Z2dlc3RlZCB0 aGF0IGFueXhtbCBzaG91bGQNCmJlIGVuY29kZWQgYXMgYSBzdHJpbmcgaW4ganNvbiwgYW5kIHdl J3JlIGRpc2N1c3NpbmcgdGhlIGltcGxpY2F0aW9ucw0Kb2YgdGhhdC4gIEluIHRoaXMgY29udGV4 dCwgSSBkbyBub3QgdGhpbmsgdGhhdCBhbnl4bWwgY2FuIGJlIHVzZWQgaW4NCllBTkcgUEFUQ0gg LSBvciB3ZSBkbyB3aGF0IEFuZHkgc3VnZ2VzdHMsIGRyb3AganNvbiBzdXBwb3J0Lg0KDQoNCi9t YXJ0aW4NCg== From nobody Mon Feb 9 05:18:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CC81A00F4 for ; Mon, 9 Feb 2015 05:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 1HRSRmmmXNj2 for ; Mon, 9 Feb 2015 05:15:07 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD47E1A0018 for ; Mon, 9 Feb 2015 05:15:06 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:d0a5:b44f:7a29:653a] (unknown [IPv6:2001:718:1a02:1:d0a5:b44f:7a29:653a]) by mail.nic.cz (Postfix) with ESMTPSA id D15A3140BD1; Mon, 9 Feb 2015 14:15:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423487703; bh=kx0v0mCBMzDdYUwUqW8m41T1UQ17SF+yBAoWZi0REmE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VLLFqqoRg8g4KTGMeRnO2a0cq/wuv5jd/PFIkIKp9DhF+q+PDEZS6W0z/mPlZ9FIM qgL9eS7sFh5cDYL98/+ysm4c8rxH1FYMoP+PVyC+mRmLuhudVG2/TxpT7h/YGVlFJq hp6hb6WSe0FIwJvpoP01K1W8FQm4GXiHV+1uQ8LU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <20150209.135651.1017394851894918029.mbj@tail-f.com> Date: Mon, 9 Feb 2015 14:15:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <182994D6-5396-44D2-B625-5E80D2165124@nic.cz> References: <20150209.091838.2239188145158636181.mbj@tail-f.com> <20150209.135651.1017394851894918029.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 13:15:09 -0000 > On 09 Feb 2015, at 13:56, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 09 Feb 2015, at 09:59, Andy Bierman wrote: >>>=20 >>> On Mon, Feb 9, 2015 at 12:18 AM, Martin Bjorklund >>> wrote: >>>> Phil Shafer wrote: >>>>> Andy Bierman writes: >>>>>> Solution Y34-06 >>>>>> - do not deprecate anyxml >>>>>> - do not add anydata (no agreement on rules) >>>>>> - implementations MAY restrict the XML accepted in anyxml >>>>>> - MAY ignore processing instructions >>>>>> - MAY reject mixed mode input >>>>>> - document in YANG 1.1 that anyxml is not considered = interoperable >>>>>> if PIs and mixed mode XML are used >>>>>=20 >>>>> This is essenially "be aware that server implementations might not >>>>> implement all of YANG". >>>>>=20 >>>=20 >>> Isn't this already the case? >>> Why is it that not all servers fully support anyxml? >>>=20 >>>=20 >>>>>> - The guidelines document should say that YANG Doctors will = review >>>>>> each use of anyxml in IETF modules >>>>>=20 >>>>> This part I completely agree with. >>>>>=20 >>>>> Here's my proposal: >>>>>=20 >>>>> Solution Y34-07 >>>>> - do not change YANG >>>>> - Change the JSON encoding rules to encode anyxml nodes as strings >>>>> - The guidelines document should say that YANG Doctors will review >>>>> each use of anyxml in IETF modules (lifted from Y34-06) >>>>=20 >>>> This is fine (*) as one part of the solution, but by itself it = isn't >>>> sufficient. >>>>=20 >>>> The problem is illustrated in YANG PATCH, which is supposed to work >>>> for both XML and JSON. If YANG PATCH uses anyxml, it means that = the >>>> JSON encoding of a YANG PATCH is pretty much useless (since the = edit >>>> would be expressed as XML, but the reast in JSON). >>>>=20 >>>> This is why we have suggested to add anydata, which YANG PATCH then >>>> should use instead of anyxml. >>>>=20 >>>=20 >>>=20 >>> I strongly object to making YANG Patch YANG 1.1 only. >>> I would rather drop JSON support. >>=20 >> I think you can continue using anyxml in YANG PATCH, IMO there is >> nothing wrong with it. If the module gets upgraded to YANG 1.1, the >> descriptions could perhaps be made shorter, and that=E2=80=99s all. >=20 > I think you're missing the context. Phil suggested that anyxml should > be encoded as a string in json, and we're discussing the implications > of that. In this context, I do not think that anyxml can be used in > YANG PATCH - or we do what Andy suggests, drop json support. OK. Anyway, I am opposed to that encoding of anyxml in JSON. Apart from = the problems you mentioned it is also asymmetric: no equivalent is = available for JSON. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 9 05:33:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EDB1A0318 for ; Mon, 9 Feb 2015 05:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McdD3VbrkJX3 for ; Mon, 9 Feb 2015 05:33:03 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450: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 653F81A0161 for ; Mon, 9 Feb 2015 05:33:03 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id bs8so3968921wib.0 for ; Mon, 09 Feb 2015 05:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=UG3nVjDW6oMzGidgY9U//d8k3MB0Y8Nn5Z8EqjhuR7w=; b=vWakCRthdPgDGnBE76u+ikJAITpDWmRPIJMV6LHeQQpXrWoTw4brI9dhxKY42X1Cx5 1PThc4s5kFiepBZJ7tt/q55XHhpfc7LhPoL38hYBQfNMsO111KDUli5GkfrZvREQHCpu XJixZYpPqZXqehACZLJt7k01bluC+9RCVWnOCaSN6xOJ1hptPuSTavnnCbNQ/NMb3SUB jhb9EldxNyFssh9maokH38jSRsSp3SrKHk33z49AyTBS1I/xlgD2vlWm/4lRE3CmGzup P5vkQ7PF924JddSB9lM6i8xcQsE7+53Jb5fUqrXmR4TJK9MhCxFQj9DiinY6ButFJ3/F v9/w== X-Received: by 10.180.79.131 with SMTP id j3mr26020410wix.33.1423488780952; Mon, 09 Feb 2015 05:33:00 -0800 (PST) Received: from host-2003-1c09-0021-0d00-652a-f3a8-7501-539f.1c09-h.de.terastrm.net (host-2003-1c09-0021-0d00-652a-f3a8-7501-539f.1c09-h.de.terastrm.net. [2003:1c09:21:d00:652a:f3a8:7501:539f]) by mx.google.com with ESMTPSA id vq9sm16416617wjc.6.2015.02.09.05.32.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 05:33:00 -0800 (PST) From: Qi Sun Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <6E5CF023-8D3F-42D5-9760-2476C4A4BC22@gmail.com> Date: Mon, 9 Feb 2015 14:32:57 +0100 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: Subject: [netmod] Question about node identifiers naming scheme X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 13:33:06 -0000 Hi netmod,=20 I=92m recently working on YANG modelling with some compiling tools. I = find something a little confusing to me, about the node identifier = naming scheme. It seems that the =93key words=94 defined in RFC6020 can also be used as = a node identifier, which might cause confusions. For example: leaf =93container=94 { type uint16; } The above definition is valid and passes the compiling. It represents a = node called =93container=94 but is actually a leaf node, which is not = allowed to =93contain=94 more than one node.=20 I checked with RFC6020, where there is no such restrictions like =93the = word =91container/import/module/uint32=92 SHOULD NOT be used as a node = identifier=94. (Like in C++ language, one is not allowed to use =93case=94= as an identifier for a user-defined parameter) I=92m wondering if the naming scheme like the above example makes sense. = Since I=92m relatively new to the wg, I might have missed some stories = about the develop of YANG language. Please feel free to correct me if my = understanding is wrong.=20 Thanks! Qi Sun From nobody Mon Feb 9 05:43:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D1E1A0242 for ; Mon, 9 Feb 2015 05:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 lc6Le6Ci_oaR for ; Mon, 9 Feb 2015 05:42:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6068F1A00EA for ; Mon, 9 Feb 2015 05:42:59 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id E5C39140471; Mon, 9 Feb 2015 14:42:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423489377; bh=TUio2cM3Vlp8D/OAsm8NbkEQaepo6p31zLFtwgvrRQc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VBAZyYok+xzINa8hUMut5v/ukgJe97QDjSvz/yk62PTp6RTgPHKgjmp45pwJint2/ yY0G2sysaYmpQ8/8AaUrj8bUSFPAABkvFuLjpYe0D0JT8LNrtSAJKH6WpgtULSyLtR wzZ4ufeoSKB08YzybZPHMgJ0eC50UvK/2G07RZNQ= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: <6E5CF023-8D3F-42D5-9760-2476C4A4BC22@gmail.com> Date: Mon, 9 Feb 2015 14:42:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <907125E5-B44D-4E14-B390-BF4D0DA10B39@nic.cz> References: <6E5CF023-8D3F-42D5-9760-2476C4A4BC22@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Question about node identifiers naming scheme X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 13:43:01 -0000 > On 09 Feb 2015, at 14:32, Qi Sun wrote: >=20 > Hi netmod,=20 >=20 > I=92m recently working on YANG modelling with some compiling tools. I = find something a little confusing to me, about the node identifier = naming scheme. >=20 > It seems that the =93key words=94 defined in RFC6020 can also be used = as a node identifier, which might cause confusions. For example: >=20 > leaf =93container=94 { > type uint16; > } >=20 This is perfectly legal, albeit perhaps not very wise. You can see other = examples in the existing NETMOD modules, e.g. this is quite common: leaf =93description=94 { type string; =85 } > The above definition is valid and passes the compiling. It represents = a node called =93container=94 but is actually a leaf node, which is not = allowed to =93contain=94 more than one node.=20 >=20 > I checked with RFC6020, where there is no such restrictions like =93the = word =91container/import/module/uint32=92 SHOULD NOT be used as a node = identifier=94. (Like in C++ language, one is not allowed to use =93case=94= as an identifier for a user-defined parameter) It poses no problems is YANG because of the fixed structure of = statements. A more appropriate comparison is with XML schema languages, = and they all allow this. Lada >=20 > I=92m wondering if the naming scheme like the above example makes = sense. Since I=92m relatively new to the wg, I might have missed some = stories about the develop of YANG language. Please feel free to correct = me if my understanding is wrong. >=20 > Thanks! > Qi Sun >=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 Mon Feb 9 05:49:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182871A0058 for ; Mon, 9 Feb 2015 05:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC0DAemm2nrM for ; Mon, 9 Feb 2015 05:49:30 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::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 D0D431A03A5 for ; Mon, 9 Feb 2015 05:49:29 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id q59so18173997wes.1 for ; Mon, 09 Feb 2015 05:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q2Jl3FxKtX7h5RKz43oAcpOqt5Y8prIGQksDnwFRaCY=; b=BHB+8LIpdqZAm0BK5XSANuUGYvxFW7aMdOb8wSF/4ijtRCt6Yea6Bmw5GvlBT7FnTb cRDOkpOJ5FEBrV++xQsCksB7Ld50/N/nwRDKcYNVqoE8THefekR5JHvu4Uk4thFZ2YP5 0dwZg9oMcCI8Cils5dM63pv/epy7UgoC8HsbdwfPHpRSj+w/uTyuwC9WLnQET6RSS+1l 8MHP1CRhvvjJqtvqCcuU0LloTRAt2j/5dQBU+gWyfUxaVjXKJpiPBu2+Vd1M4MlidW7X nP+rSzuZifttAMRxNY53uHC0RopJEYb/YXZj3wVPGayo9v+DgqXm3w6xTVKOgIyN4t04 XStg== X-Received: by 10.194.236.200 with SMTP id uw8mr41750943wjc.10.1423489768500; Mon, 09 Feb 2015 05:49:28 -0800 (PST) Received: from host-2003-1c09-0021-0d00-652a-f3a8-7501-539f.1c09-h.de.terastrm.net (host-2003-1c09-0021-0d00-652a-f3a8-7501-539f.1c09-h.de.terastrm.net. [2003:1c09:21:d00:652a:f3a8:7501:539f]) by mx.google.com with ESMTPSA id mz10sm14509709wic.9.2015.02.09.05.49.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Feb 2015 05:49:27 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Qi Sun In-Reply-To: <907125E5-B44D-4E14-B390-BF4D0DA10B39@nic.cz> Date: Mon, 9 Feb 2015 14:49:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E5CF023-8D3F-42D5-9760-2476C4A4BC22@gmail.com> <907125E5-B44D-4E14-B390-BF4D0DA10B39@nic.cz> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1874) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Question about node identifiers naming scheme X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 13:49:32 -0000 OK. Thanks for the explanation! Cheers, Qi On Feb 9, 2015, at 2:42 PM, Ladislav Lhotka wrote: >=20 >> On 09 Feb 2015, at 14:32, Qi Sun wrote: >>=20 >> Hi netmod,=20 >>=20 >> I=92m recently working on YANG modelling with some compiling tools. I = find something a little confusing to me, about the node identifier = naming scheme. >>=20 >> It seems that the =93key words=94 defined in RFC6020 can also be used = as a node identifier, which might cause confusions. For example: >>=20 >> leaf =93container=94 { >> type uint16; >> } >>=20 >=20 > This is perfectly legal, albeit perhaps not very wise. You can see = other examples in the existing NETMOD modules, e.g. this is quite = common: >=20 > leaf =93description=94 { > type string; > =85 > } >=20 >> The above definition is valid and passes the compiling. It represents = a node called =93container=94 but is actually a leaf node, which is not = allowed to =93contain=94 more than one node.=20 >>=20 >> I checked with RFC6020, where there is no such restrictions like =93the= word =91container/import/module/uint32=92 SHOULD NOT be used as a node = identifier=94. (Like in C++ language, one is not allowed to use =93case=94= as an identifier for a user-defined parameter) >=20 > It poses no problems is YANG because of the fixed structure of = statements. A more appropriate comparison is with XML schema languages, = and they all allow this. >=20 > Lada >=20 >>=20 >> I=92m wondering if the naming scheme like the above example makes = sense. Since I=92m relatively new to the wg, I might have missed some = stories about the develop of YANG language. Please feel free to correct = me if my understanding is wrong. >>=20 >> Thanks! >> Qi Sun >>=20 >>=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 From nobody Mon Feb 9 06:45:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD04A1A040B; Mon, 9 Feb 2015 06:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 9r_ptshYfuu6; Mon, 9 Feb 2015 06:36:43 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3721A040C; Mon, 9 Feb 2015 06:36:43 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" Date: Mon, 9 Feb 2015 09:36:34 -0500 Message-ID: <002501d04475$ce534350$6af9c9f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01D0444B.E581A820" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBEdai3z7yWVzjrTOqO+IQwBqOYNg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netmod@ietf.org Subject: [netmod] IDR interim meeting on February 9th - BGP Yang modules - Begins in 30 minutes X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 14:36:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0026_01D0444B.E581A820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IDR Interim 2/9 - BGP Yang Modules Monday, February 9, 2015 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 2 hrs Join WebEx meeting https://ietf.webex.com/ietf/j.php?MTID=m4abcb89450e5dfb6c1288168e2123820 Meeting number: 646 680 229 Meeting password: bgpyang Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 680 229 Toll-free calling restrictions Agenda Agenda: (75 minutes 10:00 - 11:15am) 1) A review of draft-zhdankin-idr-bgp-cfg-00 (Keyur Patel) [30 minutes] 2) Overview of Policy Yang drafts in IETF (Sue Hares) [10 minutes] http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00 http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/ http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/ http://datatracker.ietf.org/doc/draft-hareskini-i2rs-pbr-info-model/ 3) Discussion of drafts 3) Discussion comparing 2 BGP Yang modules [30 minutes] draft-zhdankin-idr-bgp-cfg-00 https://github.com/YangModels/yang/tree/master/experimental/openconfig Questions for the discussion: 1) Should we use base-BGP versus extension (Yang augmentation) approach? If so, what is the minimal subset? 2) Does the container form provide values in a) pulling the status of a BGP neighbor or a group of neighbors b) How should 4) Summary and Next steps (5 minutes) ------=_NextPart_000_0026_01D0444B.E581A820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IDR = Interim 2/9 - BGP Yang Modules

Monday, February 9, 2015

10:00 am  |  Eastern Standard Time (New = York, GMT-05:00)  |  2 hrs

 

Join WebEx = meeting

https://ietf.webex.com/ietf/j.php?MTID=3Dm4abcb89450e5d= fb6c1288168e2123820

 

 

Meeting = number:            646 = 680 229

Meeting = password:         = bgpyang

 

Join by phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in = toll number (US/Canada)

Access code: = 646 680 229

Toll-free calling = restrictions

 

Agenda

Agenda: (75 = minutes 10:00 - 11:15am) 

1) A = review of draft-zhdankin-idr-bgp-cfg-00 (Keyur Patel) [30 minutes] =

 

2) Overview of Policy Yang drafts in IETF (Sue Hares) = [10 minutes]

 

         &= nbsp;      = http://tools.ietf.org/html/draft-shaikh-rtgwg-policy-model-00<= /p>

         &= nbsp;      = http://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

         &= nbsp;      = http://datatracker.ietf.org/doc/draft-wang-netmod-yang-policy-dm/

         &= nbsp;      = http://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-info-model/

         &= nbsp;      http://datatracker.ietf.org/doc/draft-hareskini-i2rs-pbr-info-model/=

3) Discussion of drafts =

 

3) Discussion comparing 2 BGP Yang modules [30 = minutes]

    draft-zhdankin-idr-bgp-cfg-00 =

 

         &= nbsp;      = https://github.com/YangModels/yang/tree/master/experimental/openconfig

         &= nbsp;     

= Questions for the discussion:

   1) Should we use base-BGP versus = extension (Yang augmentation) approach?

      If so, what is the = minimal subset?

         &= nbsp;        

   2) Does the container form provide = values in

         &= nbsp;      a) pulling the status of a BGP = neighbor or a group of neighbors

         &= nbsp;      b) How should

 

4) Summary = and Next steps (5 minutes)

         &= nbsp;     

------=_NextPart_000_0026_01D0444B.E581A820-- From nobody Mon Feb 9 07:46:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66371A1A27 for ; Mon, 9 Feb 2015 07:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rORl9T7QLr74 for ; Mon, 9 Feb 2015 07:44:55 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (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 6D9471A1A1B for ; Mon, 9 Feb 2015 07:44:55 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so30528638lbv.3 for ; Mon, 09 Feb 2015 07:44:53 -0800 (PST) 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:content-type :content-transfer-encoding; bh=WBmEKNI+BcuZ3zP4JkRz76/EcR6J/8ZHFmwfn2i7Bew=; b=VhgoiyiXCWt3tCCwhV11kY+7Y5bg/NOizHe5qjK7lP6Oy6LokbBmmRELGfOgt5OQ/v h1BnQwkLhEagu2jqeVSXriByKIKYRP863NqTLI4bJXG9dqZ+qI79gM/u5SC9dNC2u9ld lpSkLoRZr6AgZd1+l5jSVXtZzYd067q7ROa1Yg85EHjJmjQSMQJ2r5uvsBmqv79Gc0hL Um7bD+bYBClQLiTrr996s4xPcooWkdjKaJsUD6wQnWdDLoMPkV5AAOphrUO4ccNt0QRx ++A4s8Zq3UA86ARu+bSmzqR4/YwttLfLsRiHGVayvZP0cVFkgVnCr19m1pszKtx8XDj0 W/Bg== X-Gm-Message-State: ALoCoQnx1cqelGk033I1oA6beXrbkQx24Kh4K3X/7M4e0eaXk00/98+luYMPMnZ1J3rsEfRHDzDN MIME-Version: 1.0 X-Received: by 10.112.164.101 with SMTP id yp5mr17901027lbb.82.1423496693627; Mon, 09 Feb 2015 07:44:53 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 9 Feb 2015 07:44:53 -0800 (PST) In-Reply-To: <20150209.163304.1056665518440015232.mbj@tail-f.com> References: <20150209.135651.1017394851894918029.mbj@tail-f.com> <20150209.163304.1056665518440015232.mbj@tail-f.com> Date: Mon, 9 Feb 2015 07:44:53 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:44:58 -0000 On Mon, Feb 9, 2015 at 7:33 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Mon, Feb 9, 2015 at 4:56 AM, Martin Bjorklund wrote: >> > Ladislav Lhotka wrote: >> >> >> >> > On 09 Feb 2015, at 09:59, Andy Bierman wrote: >> >> > >> >> > On Mon, Feb 9, 2015 at 12:18 AM, Martin Bjorklund >> >> > wrote: >> >> >> Phil Shafer wrote: >> >> >>> Andy Bierman writes: >> >> >>>> Solution Y34-06 >> >> >>>> - do not deprecate anyxml >> >> >>>> - do not add anydata (no agreement on rules) >> >> >>>> - implementations MAY restrict the XML accepted in anyxml >> >> >>>> - MAY ignore processing instructions >> >> >>>> - MAY reject mixed mode input >> >> >>>> - document in YANG 1.1 that anyxml is not considered interoper= able >> >> >>>> if PIs and mixed mode XML are used >> >> >>> >> >> >>> This is essenially "be aware that server implementations might no= t >> >> >>> implement all of YANG". >> >> >>> >> >> > >> >> > Isn't this already the case? >> >> > Why is it that not all servers fully support anyxml? >> >> > >> >> > >> >> >>>> - The guidelines document should say that YANG Doctors will re= view >> >> >>>> each use of anyxml in IETF modules >> >> >>> >> >> >>> This part I completely agree with. >> >> >>> >> >> >>> Here's my proposal: >> >> >>> >> >> >>> Solution Y34-07 >> >> >>> - do not change YANG >> >> >>> - Change the JSON encoding rules to encode anyxml nodes as strin= gs >> >> >>> - The guidelines document should say that YANG Doctors will revi= ew >> >> >>> each use of anyxml in IETF modules (lifted from Y34-06) >> >> >> >> >> >> This is fine (*) as one part of the solution, but by itself it isn= 't >> >> >> sufficient. >> >> >> >> >> >> The problem is illustrated in YANG PATCH, which is supposed to wor= k >> >> >> for both XML and JSON. If YANG PATCH uses anyxml, it means that t= he >> >> >> JSON encoding of a YANG PATCH is pretty much useless (since the ed= it >> >> >> would be expressed as XML, but the reast in JSON). >> >> >> >> >> >> This is why we have suggested to add anydata, which YANG PATCH the= n >> >> >> should use instead of anyxml. >> >> >> >> >> > >> >> > >> >> > I strongly object to making YANG Patch YANG 1.1 only. >> >> > I would rather drop JSON support. >> >> >> >> I think you can continue using anyxml in YANG PATCH, IMO there is >> >> nothing wrong with it. If the module gets upgraded to YANG 1.1, the >> >> descriptions could perhaps be made shorter, and that=E2=80=99s all. >> > >> > I think you're missing the context. Phil suggested that anyxml should >> > be encoded as a string in json, and we're discussing the implications >> > of that. In this context, I do not think that anyxml can be used in >> > YANG PATCH - or we do what Andy suggests, drop json support. >> > >> >> It would be a shame to drop JSON support, because implementations will >> ignore the standard and continue to support JSON in proprietary ways. >> >> The frustrating part for me is that there is not 1 single implementation >> that is actually using anyxml as configuration storage for HTML. >> If this is such a great use-case, then why isn't anybody doing it? >> >> OTOH, using anyxml as free-form YANG data nodes is implemented >> by many vendors, in many forms, and has been working fine for years. > > Agreed. But this is not anyxml, it is anydata. So if we introduce > anydata, we're standardizing what people are doing already. > > anyxml is still needed in order to correctly define the NETCONF > protocol. There are actually quite a few NETCONF implementations that > still use some proprietary language; i.e., even if we had anydata it > would be inappropraite to use it in the ietf-netconf.yang model. > >> I don't know why we would design for the 0% use-case instead of the >> 100% use-cases. The IETF seems to get wrapped around the axle >> far too easily. > > To me it seems the only issue is timing. If we had YANG 1.1. w/ > anydata today, YANG PATCH would use it, and everyone would be happy. > I agree with Lada that YANG Patch can use its current definition. The 'value' node is not free-form XML. it MUST be a container which contains 1 YANG data node, which MUST be an instance of the specified target. > anydata would have a clear encoding and mapping in JSON, and anyxml > would not. > We can republish YANG Patch if/when anydata is available in the future. > > /martin Andy From nobody Mon Feb 9 08:02:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61B21A1A03 for ; Mon, 9 Feb 2015 07:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y925DU7kwZMn for ; Mon, 9 Feb 2015 07:55:24 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 049861A1A1B for ; Mon, 9 Feb 2015 07:55:24 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id b6so8014329lbj.12 for ; Mon, 09 Feb 2015 07:55:22 -0800 (PST) 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:content-type; bh=Scz/w9tIM/EtVIBziEDGnZ2lKP6XxMtVWmPQrIqMKQU=; b=MY+YDMYpoe/NYaEiOyrZ/4X15wLGjvEhl0Cb/Zx1F5wLnNRnH/srSLupzEBVSmraKC ae5GFO/H478sGvm4i543GeP9Ao2oNq+vRcrtp1yBKFoAQ2/0RVpYUjJLTi+g885ObBIw DDpB14jT1ESirXw6lNBEiV8W/SC7KIIwrNtxyjAbCfa/hmQb83ofBRmCBU7+A9rJdmrH Qe1z0PcmKv0QVshFRUH7GKm+KBXNSx1NPzEhEt48SjKLFCXRyoLmGNBJgObUuwGNQ/M8 x5HixBrAUVyhZh3h/6L2YuClG9r+xxrtrqOlppDC3vrCl2/Qdja2xnZ5SkAtq90ejaHz XZ8g== X-Gm-Message-State: ALoCoQlYp/puaGrp6LU2Bh5qN65QxNLdC2r7YH6WNjhZIaBvPZCDt+p75XGKnedQgZY2SQFR7MfV MIME-Version: 1.0 X-Received: by 10.152.5.101 with SMTP id r5mr18222144lar.33.1423497322485; Mon, 09 Feb 2015 07:55:22 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 9 Feb 2015 07:55:22 -0800 (PST) In-Reply-To: References: <20150209.135651.1017394851894918029.mbj@tail-f.com> <20150209.163304.1056665518440015232.mbj@tail-f.com> Date: Mon, 9 Feb 2015 07:55:22 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:55:26 -0000 .... > > I agree with Lada that YANG Patch can use its current definition. > The 'value' node is not free-form XML. it MUST be a container > which contains 1 YANG data node, which MUST be an instance of > the specified target. >... Of course, if the specified datastore target is anyxml (or contains amyxml), then all bets are off. In theory, this could be embedded HTML. If we add anydata, then IMO anyxml MUST NOT be used as a data node in a YANG 1.1 module. anyxml can only be used in rpc and notification in YANG 1.1. >> >> /martin > > Andy Andy From nobody Mon Feb 9 09:23:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC911A1A15 for ; Mon, 9 Feb 2015 09:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 MWJ-t2RHluvw for ; Mon, 9 Feb 2015 09:00:42 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1BA21A1B59 for ; Mon, 9 Feb 2015 09:00:41 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 188F41409FA; Mon, 9 Feb 2015 18:00:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1423501239; bh=bnrps50krkUiURBFA6KqB3V/KadVwwBfLwFjUl39IUQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eIANVzN17JZEXwzFRahvwMI4x6pL68u/ZzVXq2R5Qzedny4azw4TNjqzEn4eBPbng gvHIEEj45nh3MxzvPscJ1Y4GjeKVVxjKgjA7+8qTXkzl9aa6m758g/GzEYXtaSBMrm 1MimtpwOpvhHawxdxvW21b6vve+zWpXODVugl0w4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 9 Feb 2015 18:00:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91035312-088A-4A3B-8EF7-7C87E8830959@nic.cz> References: <20150209.091838.2239188145158636181.mbj@tail-f.com> <20150209.135651.1017394851894918029.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 17:00:44 -0000 > On 09 Feb 2015, at 16:25, Andy Bierman wrote: >=20 > On Mon, Feb 9, 2015 at 4:56 AM, Martin Bjorklund = wrote: >> Ladislav Lhotka wrote: >>>=20 >>>> On 09 Feb 2015, at 09:59, Andy Bierman wrote: >>>>=20 >>>> On Mon, Feb 9, 2015 at 12:18 AM, Martin Bjorklund >>>> wrote: >>>>> Phil Shafer wrote: >>>>>> Andy Bierman writes: >>>>>>> Solution Y34-06 >>>>>>> - do not deprecate anyxml >>>>>>> - do not add anydata (no agreement on rules) >>>>>>> - implementations MAY restrict the XML accepted in anyxml >>>>>>> - MAY ignore processing instructions >>>>>>> - MAY reject mixed mode input >>>>>>> - document in YANG 1.1 that anyxml is not considered = interoperable >>>>>>> if PIs and mixed mode XML are used >>>>>>=20 >>>>>> This is essenially "be aware that server implementations might = not >>>>>> implement all of YANG". >>>>>>=20 >>>>=20 >>>> Isn't this already the case? >>>> Why is it that not all servers fully support anyxml? >>>>=20 >>>>=20 >>>>>>> - The guidelines document should say that YANG Doctors will = review >>>>>>> each use of anyxml in IETF modules >>>>>>=20 >>>>>> This part I completely agree with. >>>>>>=20 >>>>>> Here's my proposal: >>>>>>=20 >>>>>> Solution Y34-07 >>>>>> - do not change YANG >>>>>> - Change the JSON encoding rules to encode anyxml nodes as = strings >>>>>> - The guidelines document should say that YANG Doctors will = review >>>>>> each use of anyxml in IETF modules (lifted from Y34-06) >>>>>=20 >>>>> This is fine (*) as one part of the solution, but by itself it = isn't >>>>> sufficient. >>>>>=20 >>>>> The problem is illustrated in YANG PATCH, which is supposed to = work >>>>> for both XML and JSON. If YANG PATCH uses anyxml, it means that = the >>>>> JSON encoding of a YANG PATCH is pretty much useless (since the = edit >>>>> would be expressed as XML, but the reast in JSON). >>>>>=20 >>>>> This is why we have suggested to add anydata, which YANG PATCH = then >>>>> should use instead of anyxml. >>>>>=20 >>>>=20 >>>>=20 >>>> I strongly object to making YANG Patch YANG 1.1 only. >>>> I would rather drop JSON support. >>>=20 >>> I think you can continue using anyxml in YANG PATCH, IMO there is >>> nothing wrong with it. If the module gets upgraded to YANG 1.1, the >>> descriptions could perhaps be made shorter, and that=E2=80=99s all. >>=20 >> I think you're missing the context. Phil suggested that anyxml = should >> be encoded as a string in json, and we're discussing the implications >> of that. In this context, I do not think that anyxml can be used in >> YANG PATCH - or we do what Andy suggests, drop json support. >>=20 >=20 > It would be a shame to drop JSON support, because implementations will > ignore the standard and continue to support JSON in proprietary ways. +1 >=20 > The frustrating part for me is that there is not 1 single = implementation > that is actually using anyxml as configuration storage for HTML. > If this is such a great use-case, then why isn't anybody doing it? It not only about HTML - there are many existing XML and JSON formats = around and I think it would be good for YANG if it can offer means for = passing them in anyxml/anydata, even if processing such data is outside = the scope for YANG. In fact, there are other peculiar features in XML that most likely = won=E2=80=99t be needed, such as entities. I think it should be OK for a = server to implement only a subset of XML with the caveat that it can = only use data models that don=E2=80=99t permit the unimplemented = features. Lada >=20 > OTOH, using anyxml as free-form YANG data nodes is implemented > by many vendors, in many forms, and has been working fine for years. > I don't know why we would design for the 0% use-case instead of the > 100% use-cases. The IETF seems to get wrapped around the axle > far too easily. >=20 >>=20 >> /martin >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 9 15:39:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDF11A1A32 for ; Mon, 9 Feb 2015 07:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adV2bkNzD0Tg for ; Mon, 9 Feb 2015 07:28:07 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 432A51A1AB6 for ; Mon, 9 Feb 2015 07:25:08 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id b6so7817786lbj.12 for ; Mon, 09 Feb 2015 07:25:06 -0800 (PST) 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:content-type :content-transfer-encoding; bh=xhAT8DnuePgWZ+EpJxvhLigZTQX2QBmxyQCBXYV4J8s=; b=V5Stwvz5U9PvXU8jVlHPVLDzMTLlyBbdE29E0OWZ2gg8Xp2XVb76lwNVFUeOql4asy ab+viFX9Jcfo1oEPg82Quz7WjJxQpnJe0jdw5sAaBl7rvggLXowd/vYUz9Sy1oZvp5os wPoPOUvbKk42y4OlX8gvcla75hvTtKU4vPa3Iz48Qd50QjCKNeB7xe8dDsrCDHnaUoBl HC+ocH9mUwpjX1lTli1MVYr6nQLKDL0f5U/8S/FdhzaCRam7pEVVufRuaCNyMU1qXHII GCJGd7znBn8uBwfsihCvF0un7vof8DC9Ecr074EkBmV4PXDEtg2Tw8qxetgQN8vYne4w HMIw== X-Gm-Message-State: ALoCoQnfDG87sdWIdp/XaFVDQDzfdN37okxcharafzntUMvL8tbBj3O6ctEsFEFHckxBCaQZOYJl MIME-Version: 1.0 X-Received: by 10.152.216.132 with SMTP id oq4mr10095879lac.123.1423495506383; Mon, 09 Feb 2015 07:25:06 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 9 Feb 2015 07:25:06 -0800 (PST) In-Reply-To: <20150209.135651.1017394851894918029.mbj@tail-f.com> References: <20150209.091838.2239188145158636181.mbj@tail-f.com> <20150209.135651.1017394851894918029.mbj@tail-f.com> Date: Mon, 9 Feb 2015 07:25:06 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:28:09 -0000 On Mon, Feb 9, 2015 at 4:56 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> > On 09 Feb 2015, at 09:59, Andy Bierman wrote: >> > >> > On Mon, Feb 9, 2015 at 12:18 AM, Martin Bjorklund >> > wrote: >> >> Phil Shafer wrote: >> >>> Andy Bierman writes: >> >>>> Solution Y34-06 >> >>>> - do not deprecate anyxml >> >>>> - do not add anydata (no agreement on rules) >> >>>> - implementations MAY restrict the XML accepted in anyxml >> >>>> - MAY ignore processing instructions >> >>>> - MAY reject mixed mode input >> >>>> - document in YANG 1.1 that anyxml is not considered interoperabl= e >> >>>> if PIs and mixed mode XML are used >> >>> >> >>> This is essenially "be aware that server implementations might not >> >>> implement all of YANG". >> >>> >> > >> > Isn't this already the case? >> > Why is it that not all servers fully support anyxml? >> > >> > >> >>>> - The guidelines document should say that YANG Doctors will revie= w >> >>>> each use of anyxml in IETF modules >> >>> >> >>> This part I completely agree with. >> >>> >> >>> Here's my proposal: >> >>> >> >>> Solution Y34-07 >> >>> - do not change YANG >> >>> - Change the JSON encoding rules to encode anyxml nodes as strings >> >>> - The guidelines document should say that YANG Doctors will review >> >>> each use of anyxml in IETF modules (lifted from Y34-06) >> >> >> >> This is fine (*) as one part of the solution, but by itself it isn't >> >> sufficient. >> >> >> >> The problem is illustrated in YANG PATCH, which is supposed to work >> >> for both XML and JSON. If YANG PATCH uses anyxml, it means that the >> >> JSON encoding of a YANG PATCH is pretty much useless (since the edit >> >> would be expressed as XML, but the reast in JSON). >> >> >> >> This is why we have suggested to add anydata, which YANG PATCH then >> >> should use instead of anyxml. >> >> >> > >> > >> > I strongly object to making YANG Patch YANG 1.1 only. >> > I would rather drop JSON support. >> >> I think you can continue using anyxml in YANG PATCH, IMO there is >> nothing wrong with it. If the module gets upgraded to YANG 1.1, the >> descriptions could perhaps be made shorter, and that=E2=80=99s all. > > I think you're missing the context. Phil suggested that anyxml should > be encoded as a string in json, and we're discussing the implications > of that. In this context, I do not think that anyxml can be used in > YANG PATCH - or we do what Andy suggests, drop json support. > It would be a shame to drop JSON support, because implementations will ignore the standard and continue to support JSON in proprietary ways. The frustrating part for me is that there is not 1 single implementation that is actually using anyxml as configuration storage for HTML. If this is such a great use-case, then why isn't anybody doing it? OTOH, using anyxml as free-form YANG data nodes is implemented by many vendors, in many forms, and has been working fine for years. I don't know why we would design for the 0% use-case instead of the 100% use-cases. The IETF seems to get wrapped around the axle far too easily. > > /martin Andy From nobody Mon Feb 9 15:49:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BB01A1A31 for ; Mon, 9 Feb 2015 07:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwwuG_-N67qt for ; Mon, 9 Feb 2015 07:33:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id D2A011A0AF7 for ; Mon, 9 Feb 2015 07:33:04 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id D47711280B72; Mon, 9 Feb 2015 16:33:03 +0100 (CET) Date: Mon, 09 Feb 2015 16:33:04 +0100 (CET) Message-Id: <20150209.163304.1056665518440015232.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150209.135651.1017394851894918029.mbj@tail-f.com> 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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 15:33:22 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBNb24sIEZlYiA5 LCAyMDE1IGF0IDQ6NTYgQU0sIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90 ZToNCj4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+Pg0KPiA+ PiA+IE9uIDA5IEZlYiAyMDE1LCBhdCAwOTo1OSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jr cy5jb20+IHdyb3RlOg0KPiA+PiA+DQo+ID4+ID4gT24gTW9uLCBGZWIgOSwgMjAxNSBhdCAxMjox OCBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+DQo+ID4+ID4gd3JvdGU6DQo+ ID4+ID4+IFBoaWwgU2hhZmVyIDxwaGlsQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPj4gPj4+IEFu ZHkgQmllcm1hbiB3cml0ZXM6DQo+ID4+ID4+Pj4gU29sdXRpb24gWTM0LTA2DQo+ID4+ID4+Pj4g ICAtIGRvIG5vdCBkZXByZWNhdGUgYW55eG1sDQo+ID4+ID4+Pj4gICAtIGRvIG5vdCBhZGQgYW55 ZGF0YSAobm8gYWdyZWVtZW50IG9uIHJ1bGVzKQ0KPiA+PiA+Pj4+ICAgLSBpbXBsZW1lbnRhdGlv bnMgTUFZIHJlc3RyaWN0IHRoZSBYTUwgYWNjZXB0ZWQgaW4gYW55eG1sDQo+ID4+ID4+Pj4gICAg ICAtIE1BWSBpZ25vcmUgcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnMNCj4gPj4gPj4+PiAgICAgIC0g TUFZIHJlamVjdCBtaXhlZCBtb2RlIGlucHV0DQo+ID4+ID4+Pj4gICAtIGRvY3VtZW50IGluIFlB TkcgMS4xIHRoYXQgYW55eG1sIGlzIG5vdCBjb25zaWRlcmVkIGludGVyb3BlcmFibGUNCj4gPj4g Pj4+PiAgICAgaWYgUElzIGFuZCBtaXhlZCBtb2RlIFhNTCBhcmUgdXNlZA0KPiA+PiA+Pj4NCj4g Pj4gPj4+IFRoaXMgaXMgZXNzZW5pYWxseSAiYmUgYXdhcmUgdGhhdCBzZXJ2ZXIgaW1wbGVtZW50 YXRpb25zIG1pZ2h0IG5vdA0KPiA+PiA+Pj4gaW1wbGVtZW50IGFsbCBvZiBZQU5HIi4NCj4gPj4g Pj4+DQo+ID4+ID4NCj4gPj4gPiBJc24ndCB0aGlzIGFscmVhZHkgdGhlIGNhc2U/DQo+ID4+ID4g V2h5IGlzIGl0IHRoYXQgbm90IGFsbCBzZXJ2ZXJzIGZ1bGx5IHN1cHBvcnQgYW55eG1sPw0KPiA+ PiA+DQo+ID4+ID4NCj4gPj4gPj4+PiAgIC0gVGhlIGd1aWRlbGluZXMgZG9jdW1lbnQgc2hvdWxk IHNheSB0aGF0IFlBTkcgRG9jdG9ycyB3aWxsIHJldmlldw0KPiA+PiA+Pj4+ICAgICBlYWNoIHVz ZSBvZiBhbnl4bWwgaW4gSUVURiBtb2R1bGVzDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gVGhpcyBwYXJ0 IEkgY29tcGxldGVseSBhZ3JlZSB3aXRoLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IEhlcmUncyBteSBw cm9wb3NhbDoNCj4gPj4gPj4+DQo+ID4+ID4+PiBTb2x1dGlvbiBZMzQtMDcNCj4gPj4gPj4+ICAt IGRvIG5vdCBjaGFuZ2UgWUFORw0KPiA+PiA+Pj4gIC0gQ2hhbmdlIHRoZSBKU09OIGVuY29kaW5n IHJ1bGVzIHRvIGVuY29kZSBhbnl4bWwgbm9kZXMgYXMgc3RyaW5ncw0KPiA+PiA+Pj4gIC0gVGhl IGd1aWRlbGluZXMgZG9jdW1lbnQgc2hvdWxkIHNheSB0aGF0IFlBTkcgRG9jdG9ycyB3aWxsIHJl dmlldw0KPiA+PiA+Pj4gICAgZWFjaCB1c2Ugb2YgYW55eG1sIGluIElFVEYgbW9kdWxlcyAobGlm dGVkIGZyb20gWTM0LTA2KQ0KPiA+PiA+Pg0KPiA+PiA+PiBUaGlzIGlzIGZpbmUgKCopIGFzIG9u ZSBwYXJ0IG9mIHRoZSBzb2x1dGlvbiwgYnV0IGJ5IGl0c2VsZiBpdCBpc24ndA0KPiA+PiA+PiBz dWZmaWNpZW50Lg0KPiA+PiA+Pg0KPiA+PiA+PiBUaGUgcHJvYmxlbSBpcyBpbGx1c3RyYXRlZCBp biBZQU5HIFBBVENILCB3aGljaCBpcyBzdXBwb3NlZCB0byB3b3JrDQo+ID4+ID4+IGZvciBib3Ro IFhNTCBhbmQgSlNPTi4gIElmIFlBTkcgUEFUQ0ggdXNlcyBhbnl4bWwsIGl0IG1lYW5zIHRoYXQg dGhlDQo+ID4+ID4+IEpTT04gZW5jb2Rpbmcgb2YgYSBZQU5HIFBBVENIIGlzIHByZXR0eSBtdWNo IHVzZWxlc3MgKHNpbmNlIHRoZSBlZGl0DQo+ID4+ID4+IHdvdWxkIGJlIGV4cHJlc3NlZCBhcyBY TUwsIGJ1dCB0aGUgcmVhc3QgaW4gSlNPTikuDQo+ID4+ID4+DQo+ID4+ID4+IFRoaXMgaXMgd2h5 IHdlIGhhdmUgc3VnZ2VzdGVkIHRvIGFkZCBhbnlkYXRhLCB3aGljaCBZQU5HIFBBVENIIHRoZW4N Cj4gPj4gPj4gc2hvdWxkIHVzZSBpbnN0ZWFkIG9mIGFueXhtbC4NCj4gPj4gPj4NCj4gPj4gPg0K PiA+PiA+DQo+ID4+ID4gSSBzdHJvbmdseSBvYmplY3QgdG8gbWFraW5nIFlBTkcgUGF0Y2ggWUFO RyAxLjEgb25seS4NCj4gPj4gPiBJIHdvdWxkIHJhdGhlciBkcm9wIEpTT04gc3VwcG9ydC4NCj4g Pj4NCj4gPj4gSSB0aGluayB5b3UgY2FuIGNvbnRpbnVlIHVzaW5nIGFueXhtbCBpbiBZQU5HIFBB VENILCBJTU8gdGhlcmUgaXMNCj4gPj4gbm90aGluZyB3cm9uZyB3aXRoIGl0LiBJZiB0aGUgbW9k dWxlIGdldHMgdXBncmFkZWQgdG8gWUFORyAxLjEsIHRoZQ0KPiA+PiBkZXNjcmlwdGlvbnMgY291 bGQgcGVyaGFwcyBiZSBtYWRlIHNob3J0ZXIsIGFuZCB0aGF04oCZcyBhbGwuDQo+ID4NCj4gPiBJ IHRoaW5rIHlvdSdyZSBtaXNzaW5nIHRoZSBjb250ZXh0LiAgUGhpbCBzdWdnZXN0ZWQgdGhhdCBh bnl4bWwgc2hvdWxkDQo+ID4gYmUgZW5jb2RlZCBhcyBhIHN0cmluZyBpbiBqc29uLCBhbmQgd2Un cmUgZGlzY3Vzc2luZyB0aGUgaW1wbGljYXRpb25zDQo+ID4gb2YgdGhhdC4gIEluIHRoaXMgY29u dGV4dCwgSSBkbyBub3QgdGhpbmsgdGhhdCBhbnl4bWwgY2FuIGJlIHVzZWQgaW4NCj4gPiBZQU5H IFBBVENIIC0gb3Igd2UgZG8gd2hhdCBBbmR5IHN1Z2dlc3RzLCBkcm9wIGpzb24gc3VwcG9ydC4N Cj4gPg0KPiANCj4gSXQgd291bGQgYmUgYSBzaGFtZSB0byBkcm9wIEpTT04gc3VwcG9ydCwgYmVj YXVzZSBpbXBsZW1lbnRhdGlvbnMgd2lsbA0KPiBpZ25vcmUgdGhlIHN0YW5kYXJkIGFuZCBjb250 aW51ZSB0byBzdXBwb3J0IEpTT04gaW4gcHJvcHJpZXRhcnkgd2F5cy4NCj4gDQo+IFRoZSBmcnVz dHJhdGluZyBwYXJ0IGZvciBtZSBpcyB0aGF0IHRoZXJlIGlzIG5vdCAxIHNpbmdsZSBpbXBsZW1l bnRhdGlvbg0KPiB0aGF0IGlzIGFjdHVhbGx5IHVzaW5nIGFueXhtbCBhcyBjb25maWd1cmF0aW9u IHN0b3JhZ2UgZm9yIEhUTUwuDQo+IElmIHRoaXMgaXMgc3VjaCBhIGdyZWF0IHVzZS1jYXNlLCB0 aGVuIHdoeSBpc24ndCBhbnlib2R5IGRvaW5nIGl0Pw0KPiANCj4gT1RPSCwgdXNpbmcgYW55eG1s IGFzIGZyZWUtZm9ybSBZQU5HIGRhdGEgbm9kZXMgaXMgaW1wbGVtZW50ZWQNCj4gYnkgbWFueSB2 ZW5kb3JzLCBpbiBtYW55IGZvcm1zLCBhbmQgaGFzIGJlZW4gd29ya2luZyBmaW5lIGZvciB5ZWFy cy4NCg0KQWdyZWVkLiAgQnV0IHRoaXMgaXMgbm90IGFueXhtbCwgaXQgaXMgYW55ZGF0YS4gIFNv IGlmIHdlIGludHJvZHVjZQ0KYW55ZGF0YSwgd2UncmUgc3RhbmRhcmRpemluZyB3aGF0IHBlb3Bs ZSBhcmUgZG9pbmcgYWxyZWFkeS4NCg0KYW55eG1sIGlzIHN0aWxsIG5lZWRlZCBpbiBvcmRlciB0 byBjb3JyZWN0bHkgZGVmaW5lIHRoZSBORVRDT05GDQpwcm90b2NvbC4gIFRoZXJlIGFyZSBhY3R1 YWxseSBxdWl0ZSBhIGZldyBORVRDT05GIGltcGxlbWVudGF0aW9ucyB0aGF0DQpzdGlsbCB1c2Ug c29tZSBwcm9wcmlldGFyeSBsYW5ndWFnZTsgaS5lLiwgZXZlbiBpZiB3ZSBoYWQgYW55ZGF0YSBp dA0Kd291bGQgYmUgaW5hcHByb3ByYWl0ZSB0byB1c2UgaXQgaW4gdGhlIGlldGYtbmV0Y29uZi55 YW5nIG1vZGVsLg0KDQo+IEkgZG9uJ3Qga25vdyB3aHkgd2Ugd291bGQgZGVzaWduIGZvciB0aGUg MCUgdXNlLWNhc2UgaW5zdGVhZCBvZiB0aGUNCj4gMTAwJSB1c2UtY2FzZXMuICBUaGUgSUVURiBz ZWVtcyB0byBnZXQgd3JhcHBlZCBhcm91bmQgdGhlIGF4bGUNCj4gZmFyIHRvbyBlYXNpbHkuDQoN ClRvIG1lIGl0IHNlZW1zIHRoZSBvbmx5IGlzc3VlIGlzIHRpbWluZy4gIElmIHdlIGhhZCBZQU5H IDEuMS4gdy8NCmFueWRhdGEgdG9kYXksIFlBTkcgUEFUQ0ggd291bGQgdXNlIGl0LCBhbmQgZXZl cnlvbmUgd291bGQgYmUgaGFwcHkuDQoNCmFueWRhdGEgd291bGQgaGF2ZSBhIGNsZWFyIGVuY29k aW5nIGFuZCBtYXBwaW5nIGluIEpTT04sIGFuZCBhbnl4bWwNCndvdWxkIG5vdC4NCg0KDQovbWFy dGluDQo= From nobody Mon Feb 9 21:46:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542C81A8BBD for ; Mon, 9 Feb 2015 21:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3mKBqQITv5A for ; Mon, 9 Feb 2015 21:46:51 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 EB3931A011B for ; Mon, 9 Feb 2015 21:46:50 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n10so29764549lbv.6 for ; Mon, 09 Feb 2015 21:46:49 -0800 (PST) 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:content-type; bh=eGtBk3UWsbeZlqEMXnh49YYI05dyXEj76rGi7OR4GJA=; b=K7tIYHmza+CY6//7mnBkI4uUXiw6J8xb21pEZgaXAid+MD/0gyguuFmWi6JGCzPmKZ Q717kCUCtE7jPHK+uuBVWGqEXRg9vuqG+4OTKKowvC+ztOpsUrJ7uf/F8NokvbjSvKT4 0ozorbwQWPFjsrYIdCGrKIqnyKIdRMhUfU/TnWVIEUPdEbFQiWEn52qrxRm6W+HGvMWQ Tp9qE5PxNJCMVa/97CUoPB6J0biwGymRqSbBAiMGs2puDLq6wLqsEIb2Y/QRX1UvrAJA aEUtCcO9qRg+QswWkpCJG0myFB7qvR7tr3a3sTfoCXEPQYInuw5WYAlLo1nK48emWUvT OXDw== X-Gm-Message-State: ALoCoQn5e8/AcoPg+KDMY8sr/tFYITFqKuU+O8V4hLc0lX/NM1l+VNeDXeDYOQ0L+jOAs9bUhxT9 MIME-Version: 1.0 X-Received: by 10.112.138.66 with SMTP id qo2mr21350294lbb.123.1423547209246; Mon, 09 Feb 2015 21:46:49 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 9 Feb 2015 21:46:49 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Feb 2015 21:46:49 -0800 Message-ID: From: Andy Bierman To: Anees Shaikh Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Clarification re system mgmnt module (RFC 7317) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 05:46:53 -0000 Hi, The github YANG repo has been updated to fix this iana-crypt-hash.yang problem, and update some other modules as well. https://github.com/YangModels/yang Andy On Thu, Feb 5, 2015 at 1:05 PM, Anees Shaikh wrote: > The current system management YANG module depends on an associated > iana-crypt-hash module (also defined in the RFC). > > My question is whether the iana-crypt-hash module should be considered part > of the standard model (I has assumed it was). > > This confusion came about because in the YangModels github repo, ietf-system > is in the ietf/RFC directory, while the iana-crypt-hash module is in > ietf/DRAFT. This presumes that the github repo reflects the intended > status of ietf modules, which may not be the case. > > thanks. > -- Anees > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Feb 10 02:30:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FD81A1B71 for ; Tue, 10 Feb 2015 02:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x64e0ViFDJvV for ; Tue, 10 Feb 2015 02:30:47 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 81F501A020B for ; Tue, 10 Feb 2015 02:30:47 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 1B0061CC039A for ; Tue, 10 Feb 2015 11:30:47 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 10 Feb 2015 11:30:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 10:30:52 -0000 Hi, I'll try to summarize this long thread. Please comment. Ladislav Lhotka writes: > Hi, > > $SUBJ is already several months late, so I think we should proceed > towards delivering it. I checked my mail archive since the -02 revision, > and it seems two issues need to be resolved: > > 1. Andy objected to making redundant namespace prefixes illegal. I > propose the following change to 4th paragraph in sec.=C2=A04 (SHOULD N= OT > instead of MUST NOT): It seems Andy is now the only supporter of this change, and I think there are strong technical reasons for keeping namespace rules strict, stable and deterministic. I am therefore inclined to keep "MUST NOT", or reformulate the text in the same sense without using 2119 keywords. > > OLD > > Names with namespace identifiers in the form shown in Figure 1 MUST > be used for all top-level YANG data nodes, and also for all nodes > whose parent node belongs to a different namespace. Otherwise, names > with namespace identifiers MUST NOT be used. > > NEW > > Names with namespace identifiers in the form shown in Figure 1 MUST > be used for all top-level YANG data nodes, and also for all nodes > whose parent node belongs to a different namespace. Otherwise, names > with namespace identifiers SHOULD NOT be used. > > 2. anyxml encoding: although it is a misnomer, I propose to keep the > current definition (sec. 5.5), i.e. allow any valid JSON value in > JSON-encoded anyxml instances. I also think the text makes it > sufficiently clear that no standard mapping between XML- and > JSON-encoded instances is defined. Phil proposed to define a universal JSON encoding for anyxml values: a string containing the serialised XML text. However, there are several problems with this solution: - an XML chunk may be well-formed in the XML encoding but not in JSON, because in XML it may receive namespaces and entity definitions from the outer context. - "anyxml" cannot be used for defining contents of YANG-PATCH, configlets etc. - it is asymmetric because no equivalent means exist for non-XML encodings. I am therefore proposing a new solution for both YANG 1.1 and YANG-JSON document that could IMO be a reasonable compromise (I also committed it to SVN): ** Solution Y34-05 (LL: [2015-02-10 Tue]) - Define a new data node "anydata". Its value is an arbitrary chunk of well-formed data in the current encoding. YANG 1.1 spec will also say: #+BEGIN_QUOTE This document defines no universal mapping between "anydata" values in different encodings. However, each definition of an "anydata" node MAY specify, in the "description" statement, syntactic, semantic and mapping rules for the values of that "anydata" node. #+END_QUOTE - For backward compatibility, allow "anyxml" to be used but make it a synonym to "anydata" and label as deprecated. - Align the specification for JSON encoding (or any other future encoding that will be defined for YANG 1.0) with the first item above. - Define a new data node "root" as in Y34-04. - Include guidelines in 6087bis for the use of "anydata/anyxml" and "root". Lada > > Objections, comments, other issues? > > Thanks, Lada > > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 10 09:28:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5A11A1A12; Tue, 10 Feb 2015 08:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.511 X-Spam-Level: X-Spam-Status: No, score=-16.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKglbwDda2Ro; Tue, 10 Feb 2015 08:03:26 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F9F1A19E9; Tue, 10 Feb 2015 08:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1440; q=dns/txt; s=iport; t=1423584206; x=1424793806; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bzO8NwTHpA4VZ8I6QTmXa2FR6pyhXRp3F8tdJ71Jwp0=; b=VHaWc5g86GoAMLR5zvge2ik3qcbeeX5mAWA4OsdAV4ZK3d7dGtRH6CEJ 5ETofIPq9rouXagWO7PWXNux5XR1b3GgFgLl17SLIStsjAi+f5Q9AgJnh hDc8ZPgsICBxwoTwqkLeSOtYSoKp8uHaox3U6WMS1b25mhMmkhpgSSner I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAEsr2lStJV2b/2dsb2JhbABcgmQiUlrDCQqFJ0oCgSBDAQEBAQEBfIQMAQEBAwEBAQE3NAsFBwQCAQgRBAEBAR4FBAcnCxQIAQgCBA4FiCUIAQzQbgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjEcBgnwzBwaDEIEUBY8giS6SdiKCDyOBPG+CQgEBAQ X-IronPort-AV: E=Sophos;i="5.09,551,1418083200"; d="scan'208";a="394963466" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 10 Feb 2015 16:03:26 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1AG3P68008628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Feb 2015 16:03:25 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 10:03:25 -0600 From: "Ken Gray (kegray)" To: "Bert Wijnen (IETF)" Thread-Topic: [Rtg-yang-coord] [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules Thread-Index: AQHQQuUmr547mvx02kSiTTavp01geJzlxQ0AgAKezACAAayQIA== Date: Tue, 10 Feb 2015 16:03:25 +0000 Message-ID: References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> <54D5D041.5070307@bwijnen.net> <003001d042f3$22c77ed0$68567c70$@ndzh.com>,<54D86FEC.6030004@bwijnen.net> In-Reply-To: <54D86FEC.6030004@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 10 Feb 2015 09:28:10 -0800 Cc: "Rtg-yang-coord@ietf.org" , idr wg , "netmod@ietf.org" , NETCONF , Susan Hares Subject: Re: [netmod] [Rtg-yang-coord] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 16:03:31 -0000 Recorded by chance? Sent from my iPhone > On Feb 9, 2015, at 1:03 PM, "Bert Wijnen (IETF)" wro= te: >=20 >> On 07/02/15 17:28, Susan Hares wrote: >> Bert: >>=20 >> 10 - 11:30 am ET. My apologies for missing it. >=20 > No problem. That time is probably difficult or impossible for me. >=20 > Bert >> Sue >>=20 >> -----Original Message----- >> From: Acee Lindem (acee) [mailto:acee@cisco.com] >> Sent: Saturday, February 07, 2015 9:48 AM >> To: Bert Wijnen (IETF); Susan Hares; idr wg >> Cc: Rtg-yang-coord@ietf.org; NETCONF; netmod@ietf.org >> Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interi= m >> 2/9 - BGP Yang Modules >>=20 >> Hi Bert, >>=20 >> If you look at the WebEx, it is 10 AM EST (GMT - 5). >>=20 >> Acee >>=20 >>> On 2/7/15, 2:43 AM, "Bert Wijnen (IETF)" wrote: >>>=20 >>>> On 06/02/15 23:42, Susan Hares wrote: >>>> Agenda: (75 minutes 10:00 - 11:15am) >>> any specifics on time zone? >>>=20 >>> we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we no= t? >>>=20 >>> Bert >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Tue Feb 10 10:07:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732941A02F1; Tue, 10 Feb 2015 10:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w95Lo9od8gYo; Tue, 10 Feb 2015 10:07:26 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F651A06FD; Tue, 10 Feb 2015 10:07:26 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.75.20; Tue, 10 Feb 2015 18:07:08 +0000 Message-ID: <032701d0455c$27b622a0$4001a8c0@gateway.2wire.net> From: t.petch To: "Ken Gray (kegray)" References: <1129100539.40053.1423259295222.JavaMail.nobody@jva2tc102.webex.com> <01d101d0425e$2d271740$877545c0$@ndzh.com> <54D5D041.5070307@bwijnen.net> <003001d042f3$22c77ed0$68567c70$@ndzh.com>, <54D86FEC.6030004@bwijnen.net> Date: Tue, 10 Feb 2015 18:03:19 +0000 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.167.59] X-ClientProxiedBy: DB4PR03CA0014.eurprd03.prod.outlook.com (25.160.39.152) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB063; X-Forefront-PRVS: 048396AFA0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(13464003)(24454002)(497574002)(377424004)(39224004)(479174004)(377454003)(44736004)(50466002)(66066001)(50226001)(122386002)(81686999)(19580405001)(86362001)(92566002)(40100003)(76176999)(47776003)(50986999)(23756003)(14496001)(81816999)(42186005)(33646002)(46102003)(77096005)(110136001)(87976001)(15975445007)(1720100001)(62236002)(44716002)(19580395003)(77156002)(230783001)(93886004)(116806002)(62966003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2015 18:07:08.2079 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB063 Archived-At: Cc: Rtg-yang-coord@ietf.org, idr wg , NETCONF , netmod@ietf.org, Susan Hares Subject: Re: [netmod] [Rtg-yang-coord] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:07:29 -0000 You could try http://www.ietf.org/proceedings/interim/2015/02/09/idr/minutes/minutes-i nterim-2015-idr-3 On the other hand, nothing has yet appeared for the meeting scheduled for 2015-1-12:-( Tom Petch ----- Original Message ----- From: "Ken Gray (kegray)" To: "Bert Wijnen (IETF)" Cc: ; "idr wg" ; ; "NETCONF" ; "Acee Lindem (acee)" ; "Susan Hares" Sent: Tuesday, February 10, 2015 4:03 PM Subject: Re: [Rtg-yang-coord] [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim 2/9 - BGP Yang Modules > Recorded by chance? > > Sent from my iPhone > > > On Feb 9, 2015, at 1:03 PM, "Bert Wijnen (IETF)" wrote: > > > >> On 07/02/15 17:28, Susan Hares wrote: > >> Bert: > >> > >> 10 - 11:30 am ET. My apologies for missing it. > > > > No problem. That time is probably difficult or impossible for me. > > > > Bert > >> Sue > >> > >> -----Original Message----- > >> From: Acee Lindem (acee) [mailto:acee@cisco.com] > >> Sent: Saturday, February 07, 2015 9:48 AM > >> To: Bert Wijnen (IETF); Susan Hares; idr wg > >> Cc: Rtg-yang-coord@ietf.org; NETCONF; netmod@ietf.org > >> Subject: Re: [netmod] [Netconf] FW: WebEx meeting invitation: IDR Interim > >> 2/9 - BGP Yang Modules > >> > >> Hi Bert, > >> > >> If you look at the WebEx, it is 10 AM EST (GMT - 5). > >> > >> Acee > >> > >>> On 2/7/15, 2:43 AM, "Bert Wijnen (IETF)" wrote: > >>> > >>>> On 06/02/15 23:42, Susan Hares wrote: > >>>> Agenda: (75 minutes 10:00 - 11:15am) > >>> any specifics on time zone? > >>> > >>> we are operating in an INTERNATIONAL/AROUND-THE-GLOB setting, are we not? > >>> > >>> Bert > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Tue Feb 10 10:22:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21D21A1B59 for ; Tue, 10 Feb 2015 10:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4IgEFBljObY for ; Tue, 10 Feb 2015 10:22:23 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 0F9301A1B47 for ; Tue, 10 Feb 2015 10:22:23 -0800 (PST) Received: by labge10 with SMTP id ge10so21995111lab.12 for ; Tue, 10 Feb 2015 10:22:21 -0800 (PST) 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:content-type; bh=Xkt3tXWePy+gXnJkMUe8fscxpCkViYImpDs47JOjImA=; b=RiilspzNrpsvmtf2bmvue53xPQ2tDPZkrutnBMU25/UfSyfGObRQ+BPsOy1WgX8/O4 ii921ZlmqOO4UgpKtPlD/Af6GIgBVar69yeE4gWeOBzqM/y8Pli+p1lAarY8bSpQZdGL JJYYpyRq+1BJrUxYcXerYoq0tGXKwVV62qVIcLG3KzXJd+EnetyAPPxcSdYG3cTaIsPA FcsrDeWkCptQRekH8iTbcSmSco2YnKmcAkpyOiBFAUcjSZiGqyrwMeiRNg3gNtHZumg6 Di02vZmP20/IiFwejIpw7JQgUrnyoWtL0kDMLCnts1Qy2XUIN6xOAx/jTocLZ1RvudDw TcUA== X-Gm-Message-State: ALoCoQnYa1V+g+/ExaeZQmV9Q2lp1PvN2HH+Q1NSkcpk3Nxrm1awnu9nKYiKEjDrulx7YLwBf874 MIME-Version: 1.0 X-Received: by 10.112.167.231 with SMTP id zr7mr2483421lbb.123.1423592541402; Tue, 10 Feb 2015 10:22:21 -0800 (PST) Received: by 10.112.78.3 with HTTP; Tue, 10 Feb 2015 10:22:21 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Feb 2015 10:22:21 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 18:22:26 -0000 On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: > Hi, > > I'll try to summarize this long thread. Please comment. > > Ladislav Lhotka writes: > >> Hi, >> >> $SUBJ is already several months late, so I think we should proceed >> towards delivering it. I checked my mail archive since the -02 revision, >> and it seems two issues need to be resolved: >> >> 1. Andy objected to making redundant namespace prefixes illegal. I >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> instead of MUST NOT): > > It seems Andy is now the only supporter of this change, and I think > there are strong technical reasons for keeping namespace rules strict, > stable and deterministic. I am therefore inclined to keep "MUST NOT", or > reformulate the text in the same sense without using 2119 keywords. > >> >> OLD >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> be used for all top-level YANG data nodes, and also for all nodes >> whose parent node belongs to a different namespace. Otherwise, names >> with namespace identifiers MUST NOT be used. >> >> NEW >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> be used for all top-level YANG data nodes, and also for all nodes >> whose parent node belongs to a different namespace. Otherwise, names >> with namespace identifiers SHOULD NOT be used. >> I strongly object to changing the text above back to OLD. The debate has been over top-level nodes missing the prefix, not nested nodes that redundantly declare the same module as the parent node. We already agreed that the receiver has to parse the module name every time in case it is different. It has to remember the parent module name in case it is missing in the child nodes. So it is not an interoperability issue but rather a style issue. This is not the same as MUST use on the top-level. >> 2. anyxml encoding: although it is a misnomer, I propose to keep the >> current definition (sec. 5.5), i.e. allow any valid JSON value in >> JSON-encoded anyxml instances. I also think the text makes it >> sufficiently clear that no standard mapping between XML- and >> JSON-encoded instances is defined. > > Phil proposed to define a universal JSON encoding for anyxml values: a > string containing the serialised XML text. However, there are several > problems with this solution: > > - an XML chunk may be well-formed in the XML encoding but not in JSON, > because in XML it may receive namespaces and entity definitions from > the outer context. > > - "anyxml" cannot be used for defining contents of YANG-PATCH, > configlets etc. > > - it is asymmetric because no equivalent means exist for non-XML > encodings. > > I am therefore proposing a new solution for both YANG 1.1 and YANG-JSON > document that could IMO be a reasonable compromise (I also committed it > to SVN): > > ** Solution Y34-05 (LL: [2015-02-10 Tue]) > > - Define a new data node "anydata". Its value is an arbitrary chunk > of well-formed data in the current encoding. YANG 1.1 spec will > also say: What is "well-formed data"? E.g., the sender and receiver do not know lists from containers, so encoding the key leafs first is not possible. Will servers generate the same results if retrieval/editing produces round-trip conversions: JSON --> XML --> JSON and XML --> JSON --> XML > > #+BEGIN_QUOTE > This document defines no universal mapping between "anydata" > values in different encodings. However, each definition of an > "anydata" node MAY specify, in the "description" statement, > syntactic, semantic and mapping rules for the values of that > "anydata" node. > #+END_QUOTE > > - For backward compatibility, allow "anyxml" to be used but make it > a synonym to "anydata" and label as deprecated. > > - Align the specification for JSON encoding (or any other future > encoding that will be defined for YANG 1.0) with the first item > above. > > - Define a new data node "root" as in Y34-04. This can only be uses in rpc or notification. It cannot be nested within another 'root'. > > - Include guidelines in 6087bis for the use of "anydata/anyxml" and > "root". > I am still unclear on the consensus and details for those guidelines. > Lada Andy > >> >> Objections, comments, other issues? >> >> Thanks, Lada >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> 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 Feb 10 11:56:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7541A1BDA for ; Tue, 10 Feb 2015 11:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4otyB0c-JHL0 for ; Tue, 10 Feb 2015 11:56:40 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7D01A1B60 for ; Tue, 10 Feb 2015 11:56:40 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id C6C1A1280A55; Tue, 10 Feb 2015 20:56:38 +0100 (CET) Date: Tue, 10 Feb 2015 20:56:48 +0100 (CET) Message-Id: <20150210.205648.1440461296722529685.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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 19:56:43 -0000 Andy Bierman wrote: > On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: > > Hi, > > > > I'll try to summarize this long thread. Please comment. > > > > Ladislav Lhotka writes: > > > >> Hi, > >> > >> $SUBJ is already several months late, so I think we should proceed > >> towards delivering it. I checked my mail archive since the -02 revision, > >> and it seems two issues need to be resolved: > >> > >> 1. Andy objected to making redundant namespace prefixes illegal. I > >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT > >> instead of MUST NOT): > > > > It seems Andy is now the only supporter of this change, and I think > > there are strong technical reasons for keeping namespace rules strict, > > stable and deterministic. I am therefore inclined to keep "MUST NOT", or > > reformulate the text in the same sense without using 2119 keywords. I think it would be wise to rewrite the text to explain how the different nodes (top-level in module, top-level in remote augment and other) are encoded. The current 2119 language seems to indicate that there is some kind of choice involved. > >> OLD > >> > >> Names with namespace identifiers in the form shown in Figure 1 MUST > >> be used for all top-level YANG data nodes, and also for all nodes > >> whose parent node belongs to a different namespace. Otherwise, names > >> with namespace identifiers MUST NOT be used. > >> > >> NEW > >> > >> Names with namespace identifiers in the form shown in Figure 1 MUST > >> be used for all top-level YANG data nodes, and also for all nodes > >> whose parent node belongs to a different namespace. Otherwise, names > >> with namespace identifiers SHOULD NOT be used. > >> > > > I strongly object to changing the text above back to OLD. > The debate has been over top-level nodes missing the prefix, > not nested nodes that redundantly declare the same module > as the parent node. No, the debate has been for all nodes. > We already agreed that the receiver has to parse the module name > every time in case it is different. It has to remember the parent > module name in case it is missing in the child nodes. No, the point is that with deterministic rules, the receiver doesn't have to do any special parsing at all. The top-level node "interfaces" in "ietf-interfaces" is *always* send as "ietf-interfaces:interfaces", and its child node "interface" is *always* sent as "interface" and the node "ipv4" that augments the interface list is *always* sent as "ietf-ip:ipv4". /martin From nobody Tue Feb 10 12:09:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1EF1A1BB9 for ; Tue, 10 Feb 2015 12:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRBcIlEBQgXO for ; Tue, 10 Feb 2015 12:09:36 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 35A351A1BA4 for ; Tue, 10 Feb 2015 12:09:36 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id z12so17358010lbi.11 for ; Tue, 10 Feb 2015 12:09:34 -0800 (PST) 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:content-type; bh=RIh5pg9Muc1MLhreU64gSkQYt+HLm08vwlZILjYQ8ys=; b=aiomQMYpo+RjuXEZ+WICUo0EM+sdRO89tN+fUyOmkfoKMdd9sJ0L260kkP/Y48Qmro 942UDaySHmj6DOSQppF+xgA3qK8R1rKs1DyHkUe//A9NW9HMmwJWU+XOAj7f6ylHIOO8 t9gMQqq/4h+ZlMzr/cAPr/lKlDj6PIarhpxsfa4+TuxMwTY4rq5ZIk9HOBomYrDrsR+D EZTJjHK5D71UMVB95cd+/KiGJWbCAunrRFIew21LHPHKXNZlbaWNGl6/PXGAe1NHzn9x cu2DPTn9/HMp00nrRoH1zjRVM9CnGKKCcisoy0DShY7rlT7ZVxbyk553c/0fcb217Lsj 2ong== X-Gm-Message-State: ALoCoQlWtQVWJV+lbqyFqyFe3mEpUd9vPg4itZ0P68XmitLD9c+7VN7tCLt3iPYnZ9p456I+VwGY MIME-Version: 1.0 X-Received: by 10.112.142.168 with SMTP id rx8mr24224436lbb.37.1423598974565; Tue, 10 Feb 2015 12:09:34 -0800 (PST) Received: by 10.112.78.3 with HTTP; Tue, 10 Feb 2015 12:09:34 -0800 (PST) In-Reply-To: <20150210.205648.1440461296722529685.mbj@tail-f.com> References: <20150210.205648.1440461296722529685.mbj@tail-f.com> Date: Tue, 10 Feb 2015 12:09:34 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 20:09:39 -0000 On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: >> > Hi, >> > >> > I'll try to summarize this long thread. Please comment. >> > >> > Ladislav Lhotka writes: >> > >> >> Hi, >> >> >> >> $SUBJ is already several months late, so I think we should proceed >> >> towards delivering it. I checked my mail archive since the -02 revision, >> >> and it seems two issues need to be resolved: >> >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> >> instead of MUST NOT): >> > >> > It seems Andy is now the only supporter of this change, and I think >> > there are strong technical reasons for keeping namespace rules strict, >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or >> > reformulate the text in the same sense without using 2119 keywords. > > I think it would be wise to rewrite the text to explain how the > different nodes (top-level in module, top-level in remote augment and > other) are encoded. The current 2119 language seems to indicate that > there is some kind of choice involved. > >> >> OLD >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> with namespace identifiers MUST NOT be used. >> >> >> >> NEW >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> with namespace identifiers SHOULD NOT be used. >> >> >> >> >> I strongly object to changing the text above back to OLD. >> The debate has been over top-level nodes missing the prefix, >> not nested nodes that redundantly declare the same module >> as the parent node. > > No, the debate has been for all nodes. > >> We already agreed that the receiver has to parse the module name >> every time in case it is different. It has to remember the parent >> module name in case it is missing in the child nodes. > > No, the point is that with deterministic rules, the receiver doesn't > have to do any special parsing at all. The top-level node > "interfaces" in "ietf-interfaces" is *always* send as > "ietf-interfaces:interfaces", and its child node "interface" is > *always* sent as "interface" and the node "ipv4" that augments the > interface list is *always* sent as "ietf-ip:ipv4". > > But what if there is an "acme:interface" that augments "ietf-interfaces:interfaces"? Then the child node will not always be "interface". It might be "acme:interface" instead. The server better check, right? Not checking for a module name means the server might assume that "junk:interface" is a valid node and child of ietf-interfaces:interfaces. Seems like the server has to check every node. > > /martin Andy From nobody Tue Feb 10 12:29:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726A51A1F01 for ; Tue, 10 Feb 2015 12:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: 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_kPftRuB7eK for ; Tue, 10 Feb 2015 12:29:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DB5E11A1BDE for ; Tue, 10 Feb 2015 12:29:32 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id A3FA112809A3; Tue, 10 Feb 2015 21:29:31 +0100 (CET) Date: Tue, 10 Feb 2015 21:29:41 +0100 (CET) Message-Id: <20150210.212941.898317079077270679.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150210.205648.1440461296722529685.mbj@tail-f.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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 20:29:37 -0000 Andy Bierman wrote: > On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: > >> > Hi, > >> > > >> > I'll try to summarize this long thread. Please comment. > >> > > >> > Ladislav Lhotka writes: > >> > > >> >> Hi, > >> >> > >> >> $SUBJ is already several months late, so I think we should proceed > >> >> towards delivering it. I checked my mail archive since the -02 revision, > >> >> and it seems two issues need to be resolved: > >> >> > >> >> 1. Andy objected to making redundant namespace prefixes illegal. I > >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT > >> >> instead of MUST NOT): > >> > > >> > It seems Andy is now the only supporter of this change, and I think > >> > there are strong technical reasons for keeping namespace rules strict, > >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or > >> > reformulate the text in the same sense without using 2119 keywords. > > > > I think it would be wise to rewrite the text to explain how the > > different nodes (top-level in module, top-level in remote augment and > > other) are encoded. The current 2119 language seems to indicate that > > there is some kind of choice involved. > > > >> >> OLD > >> >> > >> >> Names with namespace identifiers in the form shown in Figure 1 MUST > >> >> be used for all top-level YANG data nodes, and also for all nodes > >> >> whose parent node belongs to a different namespace. Otherwise, names > >> >> with namespace identifiers MUST NOT be used. > >> >> > >> >> NEW > >> >> > >> >> Names with namespace identifiers in the form shown in Figure 1 MUST > >> >> be used for all top-level YANG data nodes, and also for all nodes > >> >> whose parent node belongs to a different namespace. Otherwise, names > >> >> with namespace identifiers SHOULD NOT be used. > >> >> > >> > >> > >> I strongly object to changing the text above back to OLD. > >> The debate has been over top-level nodes missing the prefix, > >> not nested nodes that redundantly declare the same module > >> as the parent node. > > > > No, the debate has been for all nodes. > > > >> We already agreed that the receiver has to parse the module name > >> every time in case it is different. It has to remember the parent > >> module name in case it is missing in the child nodes. > > > > No, the point is that with deterministic rules, the receiver doesn't > > have to do any special parsing at all. The top-level node > > "interfaces" in "ietf-interfaces" is *always* send as > > "ietf-interfaces:interfaces", and its child node "interface" is > > *always* sent as "interface" and the node "ipv4" that augments the > > interface list is *always* sent as "ietf-ip:ipv4". > > > > > > But what if there is an "acme:interface" that augments > "ietf-interfaces:interfaces"? > Then the child node will not always be "interface". It might be > "acme:interface" > instead. No, in that case there are two separate nodes, one always encoded as "interface" and one always encoded as "acme:interface", regardless of how many other augments there are. > The server better check, right? > > Not checking for a module name means the server might assume > that "junk:interface" is a valid node and child of ietf-interfaces:interfaces. > Seems like the server has to check every node. No, since with this scheme there is no flexibility, everything is 100% predictable and stable. /martin From nobody Tue Feb 10 12:40:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331741A1BF5 for ; Tue, 10 Feb 2015 12:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bV-JDggLnyh for ; Tue, 10 Feb 2015 12:40:35 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 1DAB31A1BEA for ; Tue, 10 Feb 2015 12:40:35 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id w7so17575207lbi.9 for ; Tue, 10 Feb 2015 12:40:33 -0800 (PST) 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:content-type; bh=eHTQIPTv841Rz4WdyvnRP5+16b7RB4LnSjk7J2Z2pT8=; b=SggsV5/hr4r9rBYF/e3hzYI+UrdP1bX4rzLhBUdmkFMMw+NuHUSz8piTemNJtjhw// aAN9N3Fw25SHElFmubp9RAObO8bkK4hyE3ekCqo8DOScb/kB45XB3TfjmHmEAHnXOAiF hGWXKTWd0AHvLNct1yzgihV79Umhj6vQUV+epIhtx+G1PpiAgK4Zsp4kIOMLi5Y2I9nW BgY0l7FT5qA5n8Znq3reUHJNdcsSHijOThatqh4wiS6I1UUevGjFef+L2B5rTFDw4bCE h6KZKu/st43TU7jSyqRQpQuskF7SNzp8s0YEWus/oMRVA+OJNJ87CfRBMziHSFOI+yUE JuQg== X-Gm-Message-State: ALoCoQnV4oqAdMgHkb2kdxRxTPwEUkHRLpk2I6PvvjWC7icARYX90jwm5zzvBHlyaOD6nJiC7H/M MIME-Version: 1.0 X-Received: by 10.112.164.101 with SMTP id yp5mr24757957lbb.82.1423600833442; Tue, 10 Feb 2015 12:40:33 -0800 (PST) Received: by 10.112.78.3 with HTTP; Tue, 10 Feb 2015 12:40:33 -0800 (PST) In-Reply-To: <20150210.212941.898317079077270679.mbj@tail-f.com> References: <20150210.205648.1440461296722529685.mbj@tail-f.com> <20150210.212941.898317079077270679.mbj@tail-f.com> Date: Tue, 10 Feb 2015 12:40:33 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 20:40:38 -0000 On Tue, Feb 10, 2015 at 12:29 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund wrote: >> > Andy Bierman wrote: >> >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: >> >> > Hi, >> >> > >> >> > I'll try to summarize this long thread. Please comment. >> >> > >> >> > Ladislav Lhotka writes: >> >> > >> >> >> Hi, >> >> >> >> >> >> $SUBJ is already several months late, so I think we should proceed >> >> >> towards delivering it. I checked my mail archive since the -02 revision, >> >> >> and it seems two issues need to be resolved: >> >> >> >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I >> >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> >> >> instead of MUST NOT): >> >> > >> >> > It seems Andy is now the only supporter of this change, and I think >> >> > there are strong technical reasons for keeping namespace rules strict, >> >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or >> >> > reformulate the text in the same sense without using 2119 keywords. >> > >> > I think it would be wise to rewrite the text to explain how the >> > different nodes (top-level in module, top-level in remote augment and >> > other) are encoded. The current 2119 language seems to indicate that >> > there is some kind of choice involved. >> > >> >> >> OLD >> >> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> >> with namespace identifiers MUST NOT be used. >> >> >> >> >> >> NEW >> >> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> >> with namespace identifiers SHOULD NOT be used. >> >> >> >> >> >> >> >> >> I strongly object to changing the text above back to OLD. >> >> The debate has been over top-level nodes missing the prefix, >> >> not nested nodes that redundantly declare the same module >> >> as the parent node. >> > >> > No, the debate has been for all nodes. >> > >> >> We already agreed that the receiver has to parse the module name >> >> every time in case it is different. It has to remember the parent >> >> module name in case it is missing in the child nodes. >> > >> > No, the point is that with deterministic rules, the receiver doesn't >> > have to do any special parsing at all. The top-level node >> > "interfaces" in "ietf-interfaces" is *always* send as >> > "ietf-interfaces:interfaces", and its child node "interface" is >> > *always* sent as "interface" and the node "ipv4" that augments the >> > interface list is *always* sent as "ietf-ip:ipv4". >> > >> > >> >> But what if there is an "acme:interface" that augments >> "ietf-interfaces:interfaces"? >> Then the child node will not always be "interface". It might be >> "acme:interface" >> instead. > > No, in that case there are two separate nodes, one always encoded as > "interface" and one always encoded as "acme:interface", regardless of > how many other augments there are. > >> The server better check, right? >> >> Not checking for a module name means the server might assume >> that "junk:interface" is a valid node and child of ietf-interfaces:interfaces. >> Seems like the server has to check every node. > > No, since with this scheme there is no flexibility, everything is 100% > predictable and stable. > You really think it's a good idea to assume the data from the sender is always valid and doesn't need to be checked? I don't see how interoperability is increased if the server is forced to reject input it understands. I doubt customers will see this as a feature instead of a bug. > > /martin Andy From nobody Tue Feb 10 12:55:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F1C1A1EF7 for ; Tue, 10 Feb 2015 12:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z44at97Xpac1 for ; Tue, 10 Feb 2015 12:55:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id E598A1A6D3F for ; Tue, 10 Feb 2015 12:55:41 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 39B5012809A3; Tue, 10 Feb 2015 21:55:41 +0100 (CET) Date: Tue, 10 Feb 2015 21:55:50 +0100 (CET) Message-Id: <20150210.215550.1438604762585678944.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150210.212941.898317079077270679.mbj@tail-f.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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 20:55:48 -0000 Andy Bierman wrote: > On Tue, Feb 10, 2015 at 12:29 PM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund wrote: > >> > Andy Bierman wrote: > >> >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: > >> >> > Hi, > >> >> > > >> >> > I'll try to summarize this long thread. Please comment. > >> >> > > >> >> > Ladislav Lhotka writes: > >> >> > > >> >> >> Hi, > >> >> >> > >> >> >> $SUBJ is already several months late, so I think we should proceed > >> >> >> towards delivering it. I checked my mail archive since the -02 revision, > >> >> >> and it seems two issues need to be resolved: > >> >> >> > >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I > >> >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT > >> >> >> instead of MUST NOT): > >> >> > > >> >> > It seems Andy is now the only supporter of this change, and I think > >> >> > there are strong technical reasons for keeping namespace rules strict, > >> >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or > >> >> > reformulate the text in the same sense without using 2119 keywords. > >> > > >> > I think it would be wise to rewrite the text to explain how the > >> > different nodes (top-level in module, top-level in remote augment and > >> > other) are encoded. The current 2119 language seems to indicate that > >> > there is some kind of choice involved. > >> > > >> >> >> OLD > >> >> >> > >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST > >> >> >> be used for all top-level YANG data nodes, and also for all nodes > >> >> >> whose parent node belongs to a different namespace. Otherwise, names > >> >> >> with namespace identifiers MUST NOT be used. > >> >> >> > >> >> >> NEW > >> >> >> > >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST > >> >> >> be used for all top-level YANG data nodes, and also for all nodes > >> >> >> whose parent node belongs to a different namespace. Otherwise, names > >> >> >> with namespace identifiers SHOULD NOT be used. > >> >> >> > >> >> > >> >> > >> >> I strongly object to changing the text above back to OLD. > >> >> The debate has been over top-level nodes missing the prefix, > >> >> not nested nodes that redundantly declare the same module > >> >> as the parent node. > >> > > >> > No, the debate has been for all nodes. > >> > > >> >> We already agreed that the receiver has to parse the module name > >> >> every time in case it is different. It has to remember the parent > >> >> module name in case it is missing in the child nodes. > >> > > >> > No, the point is that with deterministic rules, the receiver doesn't > >> > have to do any special parsing at all. The top-level node > >> > "interfaces" in "ietf-interfaces" is *always* send as > >> > "ietf-interfaces:interfaces", and its child node "interface" is > >> > *always* sent as "interface" and the node "ipv4" that augments the > >> > interface list is *always* sent as "ietf-ip:ipv4". > >> > > >> > > >> > >> But what if there is an "acme:interface" that augments > >> "ietf-interfaces:interfaces"? > >> Then the child node will not always be "interface". It might be > >> "acme:interface" > >> instead. > > > > No, in that case there are two separate nodes, one always encoded as > > "interface" and one always encoded as "acme:interface", regardless of > > how many other augments there are. > > > >> The server better check, right? > >> > >> Not checking for a module name means the server might assume > >> that "junk:interface" is a valid node and child of ietf-interfaces:interfaces. > >> Seems like the server has to check every node. > > > > No, since with this scheme there is no flexibility, everything is 100% > > predictable and stable. > > > > You really think it's a good idea to assume the data from the sender > is always valid and doesn't need to be checked? That is a completely separate question. We're discussing the best way to encode YANG node names in json. It is up to us to specify this. There is no given answer. With clear and simple rules, chances are higher that implementations are correct. > I don't see how interoperability is increased if the server is > forced to reject input it understands. I doubt customers will > see this as a feature instead of a bug. I think you are missing the point. If the rule is that a top-level node is encoded as :, why would a server "understand" just "interfaces"? Surely a server would also understand - or ? Your code can be as liberal as you program it to be, but the specification needs to be clear and specify what is *valid*. /martin From nobody Tue Feb 10 13:11:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0641A1BF5 for ; Tue, 10 Feb 2015 13:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4klRFojg4p4 for ; Tue, 10 Feb 2015 13:11:09 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (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 29ECC1A01F4 for ; Tue, 10 Feb 2015 13:11:08 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id z11so5130459lbi.5 for ; Tue, 10 Feb 2015 13:11:07 -0800 (PST) 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:content-type; bh=XvQ4zaBwr6w/xWbewxcAOaP/xKb6iZwj+u+Rpud8uwE=; b=lnK1w3vExOfKu7P9QphJ6AJPr9Q4O3nv5Ns74Sd+vUKXvhepgVsOysdk/tWmOyG9T8 Nz9qFhi7R8Ci9/60siYU3d1Hwc7FhefWhLYtVJP23oxhnWElkFLFSlUJlddiQaGrZu3x sW+HIiOxxICMWu8Ze4h3KCzgivQh1UWGg/M/i76iGjoctcH7cZAyWRql3rinFvjbGrBh 8R0ssMDL6I3nd1aJr5bKO6MA0psGJeFh0haeIMK1qdAM7yPozNz6AisYXAFMAFwJ6JkQ t8yQ1ofl2UEeHvxt9nWleClIzEGmojafZ1vyeBVz3TmnNice8DzluRkf2VaS1aZIuXPd /22Q== X-Gm-Message-State: ALoCoQmZyWh4qGLokopQTrXui6Tu5yfgu4fcNLQYCVKlxYIIk4XIjxathjnQRAYNNY9QRngcbamT MIME-Version: 1.0 X-Received: by 10.112.155.229 with SMTP id vz5mr17247039lbb.38.1423602667472; Tue, 10 Feb 2015 13:11:07 -0800 (PST) Received: by 10.112.78.3 with HTTP; Tue, 10 Feb 2015 13:11:07 -0800 (PST) In-Reply-To: <20150210.215550.1438604762585678944.mbj@tail-f.com> References: <20150210.212941.898317079077270679.mbj@tail-f.com> <20150210.215550.1438604762585678944.mbj@tail-f.com> Date: Tue, 10 Feb 2015 13:11:07 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 21:11:15 -0000 On Tue, Feb 10, 2015 at 12:55 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Tue, Feb 10, 2015 at 12:29 PM, Martin Bjorklund wrote: >> > Andy Bierman wrote: >> >> On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund wrote: >> >> > Andy Bierman wrote: >> >> >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: >> >> >> > Hi, >> >> >> > >> >> >> > I'll try to summarize this long thread. Please comment. >> >> >> > >> >> >> > Ladislav Lhotka writes: >> >> >> > >> >> >> >> Hi, >> >> >> >> >> >> >> >> $SUBJ is already several months late, so I think we should proceed >> >> >> >> towards delivering it. I checked my mail archive since the -02 revision, >> >> >> >> and it seems two issues need to be resolved: >> >> >> >> >> >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I >> >> >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> >> >> >> instead of MUST NOT): >> >> >> > >> >> >> > It seems Andy is now the only supporter of this change, and I think >> >> >> > there are strong technical reasons for keeping namespace rules strict, >> >> >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or >> >> >> > reformulate the text in the same sense without using 2119 keywords. >> >> > >> >> > I think it would be wise to rewrite the text to explain how the >> >> > different nodes (top-level in module, top-level in remote augment and >> >> > other) are encoded. The current 2119 language seems to indicate that >> >> > there is some kind of choice involved. >> >> > >> >> >> >> OLD >> >> >> >> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> >> >> with namespace identifiers MUST NOT be used. >> >> >> >> >> >> >> >> NEW >> >> >> >> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> >> >> with namespace identifiers SHOULD NOT be used. >> >> >> >> >> >> >> >> >> >> >> >> >> I strongly object to changing the text above back to OLD. >> >> >> The debate has been over top-level nodes missing the prefix, >> >> >> not nested nodes that redundantly declare the same module >> >> >> as the parent node. >> >> > >> >> > No, the debate has been for all nodes. >> >> > >> >> >> We already agreed that the receiver has to parse the module name >> >> >> every time in case it is different. It has to remember the parent >> >> >> module name in case it is missing in the child nodes. >> >> > >> >> > No, the point is that with deterministic rules, the receiver doesn't >> >> > have to do any special parsing at all. The top-level node >> >> > "interfaces" in "ietf-interfaces" is *always* send as >> >> > "ietf-interfaces:interfaces", and its child node "interface" is >> >> > *always* sent as "interface" and the node "ipv4" that augments the >> >> > interface list is *always* sent as "ietf-ip:ipv4". >> >> > >> >> > >> >> >> >> But what if there is an "acme:interface" that augments >> >> "ietf-interfaces:interfaces"? >> >> Then the child node will not always be "interface". It might be >> >> "acme:interface" >> >> instead. >> > >> > No, in that case there are two separate nodes, one always encoded as >> > "interface" and one always encoded as "acme:interface", regardless of >> > how many other augments there are. >> > >> >> The server better check, right? >> >> >> >> Not checking for a module name means the server might assume >> >> that "junk:interface" is a valid node and child of ietf-interfaces:interfaces. >> >> Seems like the server has to check every node. >> > >> > No, since with this scheme there is no flexibility, everything is 100% >> > predictable and stable. >> > >> >> You really think it's a good idea to assume the data from the sender >> is always valid and doesn't need to be checked? > > That is a completely separate question. We're discussing the best way > to encode YANG node names in json. It is up to us to specify this. > There is no given answer. With clear and simple rules, chances are > higher that implementations are correct. > >> I don't see how interoperability is increased if the server is >> forced to reject input it understands. I doubt customers will >> see this as a feature instead of a bug. > > I think you are missing the point. If the rule is that a top-level > node is encoded as :, why would a server > "understand" just "interfaces"? Surely a server would also understand > - or ? > > Your code can be as liberal as you program it to be, but the > specification needs to be clear and specify what is *valid*. > The pattern is : so why would one change the delimiter to a character that is invalid within a YANG identifier? Or to whitespace? That doesn't make sense. Since everything is 100% predictable as you say, the server knows that "foo" matches the only node with a a local-name of "foo". It seems to violate the Postel Principle to reject this input. > > /martin Andy From nobody Tue Feb 10 13:20:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0901A19EF for ; Tue, 10 Feb 2015 13:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ycHGYyBMvSg for ; Tue, 10 Feb 2015 13:20:14 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDA91A6FEF for ; Tue, 10 Feb 2015 13:19:27 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id EA3E31280A55; Tue, 10 Feb 2015 22:19:25 +0100 (CET) Date: Tue, 10 Feb 2015 22:19:35 +0100 (CET) Message-Id: <20150210.221935.1416907161721598337.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150210.215550.1438604762585678944.mbj@tail-f.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] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 21:20:18 -0000 Andy Bierman wrote: > On Tue, Feb 10, 2015 at 12:55 PM, Martin Bjorklund wrote: > > Andy Bierman wrote: > >> On Tue, Feb 10, 2015 at 12:29 PM, Martin Bjorklund wrote: > >> > Andy Bierman wrote: > >> >> On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund wrote: > >> >> > Andy Bierman wrote: > >> >> >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: > >> >> >> > Hi, > >> >> >> > > >> >> >> > I'll try to summarize this long thread. Please comment. > >> >> >> > > >> >> >> > Ladislav Lhotka writes: > >> >> >> > > >> >> >> >> Hi, > >> >> >> >> > >> >> >> >> $SUBJ is already several months late, so I think we should proceed > >> >> >> >> towards delivering it. I checked my mail archive since the -02 revision, > >> >> >> >> and it seems two issues need to be resolved: > >> >> >> >> > >> >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I > >> >> >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT > >> >> >> >> instead of MUST NOT): > >> >> >> > > >> >> >> > It seems Andy is now the only supporter of this change, and I think > >> >> >> > there are strong technical reasons for keeping namespace rules strict, > >> >> >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or > >> >> >> > reformulate the text in the same sense without using 2119 keywords. > >> >> > > >> >> > I think it would be wise to rewrite the text to explain how the > >> >> > different nodes (top-level in module, top-level in remote augment and > >> >> > other) are encoded. The current 2119 language seems to indicate that > >> >> > there is some kind of choice involved. > >> >> > > >> >> >> >> OLD > >> >> >> >> > >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST > >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes > >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names > >> >> >> >> with namespace identifiers MUST NOT be used. > >> >> >> >> > >> >> >> >> NEW > >> >> >> >> > >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST > >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes > >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names > >> >> >> >> with namespace identifiers SHOULD NOT be used. > >> >> >> >> > >> >> >> > >> >> >> > >> >> >> I strongly object to changing the text above back to OLD. > >> >> >> The debate has been over top-level nodes missing the prefix, > >> >> >> not nested nodes that redundantly declare the same module > >> >> >> as the parent node. > >> >> > > >> >> > No, the debate has been for all nodes. > >> >> > > >> >> >> We already agreed that the receiver has to parse the module name > >> >> >> every time in case it is different. It has to remember the parent > >> >> >> module name in case it is missing in the child nodes. > >> >> > > >> >> > No, the point is that with deterministic rules, the receiver doesn't > >> >> > have to do any special parsing at all. The top-level node > >> >> > "interfaces" in "ietf-interfaces" is *always* send as > >> >> > "ietf-interfaces:interfaces", and its child node "interface" is > >> >> > *always* sent as "interface" and the node "ipv4" that augments the > >> >> > interface list is *always* sent as "ietf-ip:ipv4". > >> >> > > >> >> > > >> >> > >> >> But what if there is an "acme:interface" that augments > >> >> "ietf-interfaces:interfaces"? > >> >> Then the child node will not always be "interface". It might be > >> >> "acme:interface" > >> >> instead. > >> > > >> > No, in that case there are two separate nodes, one always encoded as > >> > "interface" and one always encoded as "acme:interface", regardless of > >> > how many other augments there are. > >> > > >> >> The server better check, right? > >> >> > >> >> Not checking for a module name means the server might assume > >> >> that "junk:interface" is a valid node and child of ietf-interfaces:interfaces. > >> >> Seems like the server has to check every node. > >> > > >> > No, since with this scheme there is no flexibility, everything is 100% > >> > predictable and stable. > >> > > >> > >> You really think it's a good idea to assume the data from the sender > >> is always valid and doesn't need to be checked? > > > > That is a completely separate question. We're discussing the best way > > to encode YANG node names in json. It is up to us to specify this. > > There is no given answer. With clear and simple rules, chances are > > higher that implementations are correct. > > > >> I don't see how interoperability is increased if the server is > >> forced to reject input it understands. I doubt customers will > >> see this as a feature instead of a bug. > > > > I think you are missing the point. If the rule is that a top-level > > node is encoded as :, why would a server > > "understand" just "interfaces"? Surely a server would also understand > > - or ? > > > > Your code can be as liberal as you program it to be, but the > > specification needs to be clear and specify what is *valid*. > > > > The pattern is : so why would one > change the delimiter to a character that is invalid within a YANG > identifier? Or to whitespace? That doesn't make sense. Exactly - the encoding is :, why would anyone send ? If there is just one node, why would your server care about the name at all? > Since everything is 100% predictable as you say, the server > knows that "foo" matches the only node with a a local-name of "foo". > It seems to violate the Postel Principle to reject this input. The Postel Principle says that an implementation should be liberal in what it accepts, i.e., accept things that do not follow the specification. We are talking about what the *specification* should be. If the spec says that two forms are legal, the Postel Principle doesn't apply to these two forms, since it is not liberal to accept something that is legal! /martin From nobody Tue Feb 10 17:34:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD841A1AB1 for ; Tue, 10 Feb 2015 17:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJx-9wGLLP1Z for ; Tue, 10 Feb 2015 17:34:37 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.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 174B71A1A20 for ; Tue, 10 Feb 2015 17:34:37 -0800 (PST) Received: from CO2PR05CA018.namprd05.prod.outlook.com (10.141.241.146) by DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 11 Feb 2015 01:34:30 +0000 Received: from BN1BFFO11FD049.protection.gbl (2a01:111:f400:7c10::1:105) by CO2PR05CA018.outlook.office365.com (2a01:111:e400:1429::18) with Microsoft SMTP Server (TLS) id 15.1.81.19 via Frontend Transport; Wed, 11 Feb 2015 01:34:30 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD049.mail.protection.outlook.com (10.58.145.4) with Microsoft SMTP Server (TLS) id 15.1.87.10 via Frontend Transport; Wed, 11 Feb 2015 01:34:29 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 10 Feb 2015 17:34:28 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1B1YPW50834; Tue, 10 Feb 2015 17:34:25 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t1B1Y9Zl094658; Tue, 10 Feb 2015 20:34:10 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502110134.t1B1Y9Zl094658@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: Date: Tue, 10 Feb 2015 20:34:09 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; yumaworks.com; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(87936001)(47776003)(19580395003)(54356999)(86362001)(50986999)(46102003)(105596002)(92566002)(50466002)(77096005)(6806004)(110136001)(53416004)(77156002)(2950100001)(48376002)(76506005)(106466001)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB445; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR05MB445; X-Forefront-PRVS: 0484063412 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB445; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2015 01:34:29.3308 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB445 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Ladislav Lhotka] Re: yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 01:34:39 -0000 Ladislav Lhotka writes: >BTW, my (technical) colleagues are now designing a new YAML-based >configuration format for the Knot DNS server, and a special remote >configuration protocol - despite the fact that I've been harassing them >with NETCONF and YANG for several years. And they refused NETCONF >specifically because of the fact it is limited to XML. There's always a newer flavor-of-the-month. The funny bit is when the FOTM is celebrated because it's free of all the "cruft" of the previous FOTM, but then the crowd starts immediately rebuilding that cruft for the new FOTM. See json-schema, json-pointer, etc. It would be interesting to ask them with version of YAML they are using, given that 1.2 is five years only, but yaml.org lists only two implementations of it. ;^) And yes, xml definitely needs better libraries. There's no reason I can't parse XML into modern structures. Take a look at pyez Thanks, Phil From nobody Wed Feb 11 00:01:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8441A8035 for ; Wed, 11 Feb 2015 00:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny8VtyKwH5WJ for ; Wed, 11 Feb 2015 00:01:09 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 24D601A7034 for ; Wed, 11 Feb 2015 00:01:09 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 082691CC01D9; Wed, 11 Feb 2015 09:01:06 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer In-Reply-To: <201502110134.t1B1Y9Zl094658@idle.juniper.net> References: <201502110134.t1B1Y9Zl094658@idle.juniper.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 11 Feb 2015 09:01:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] [Ladislav Lhotka] Re: yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 08:01:11 -0000 Phil Shafer writes: > Ladislav Lhotka writes: >>BTW, my (technical) colleagues are now designing a new YAML-based >>configuration format for the Knot DNS server, and a special remote >>configuration protocol - despite the fact that I've been harassing them >>with NETCONF and YANG for several years. And they refused NETCONF >>specifically because of the fact it is limited to XML. > > There's always a newer flavor-of-the-month. The funny bit is when > the FOTM is celebrated because it's free of all the "cruft" of the > previous FOTM, but then the crowd starts immediately rebuilding > that cruft for the new FOTM. See json-schema, json-pointer, etc. We know that schemas and pointers are useful, right? :-) However, a programmer with no knowledge of JSON whatsoever can start using it effectively after maybe 20 minutes. It takes *much* longer with XML, and you can run into surprises even after having used it for a long time. One thing that makes XML really complex is the mixed content - it is good for documents with markup but useless for hierarchical data. > > It would be interesting to ask them with version of YAML they are > using, given that 1.2 is five years only, but yaml.org lists only > two implementations of it. ;^) I hope I will be able to convince them to go for JSON, that way we could at least use YANG. > > And yes, xml definitely needs better libraries. There's no reason > I can't parse XML into modern structures. Take a look at pyez > Actually, XML needed better libraries 15 or 20 years ago, and the situation hasn't improved that much since then. I think XML will continue to be used in areas like HTML where it makes sense, but in the area of data storage and interchange it will be outcompeted by simpler formats - it is already happening. That's why I also think making XML the mandatory encoding for RESTCONF is, well, unwise. Lada > Thanks, > Phil -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Feb 11 00:12:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DF71A86EE for ; Wed, 11 Feb 2015 00:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1OG7LCGhcu0 for ; Wed, 11 Feb 2015 00:12:44 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7551A7034 for ; Wed, 11 Feb 2015 00:12:44 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 11C8F1CC01D9; Wed, 11 Feb 2015 09:12:44 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150210.205648.1440461296722529685.mbj@tail-f.com> References: <20150210.205648.1440461296722529685.mbj@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Wed, 11 Feb 2015 09:12:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 08:12:46 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: >> > Hi, >> > >> > I'll try to summarize this long thread. Please comment. >> > >> > Ladislav Lhotka writes: >> > >> >> Hi, >> >> >> >> $SUBJ is already several months late, so I think we should proceed >> >> towards delivering it. I checked my mail archive since the -02 revision, >> >> and it seems two issues need to be resolved: >> >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> >> instead of MUST NOT): >> > >> > It seems Andy is now the only supporter of this change, and I think >> > there are strong technical reasons for keeping namespace rules strict, >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or >> > reformulate the text in the same sense without using 2119 keywords. > > I think it would be wise to rewrite the text to explain how the > different nodes (top-level in module, top-level in remote augment and > other) are encoded. The current 2119 language seems to indicate that > there is some kind of choice involved. Right. RFC 6020 also doesn't say that the decimal point MUST NOT be present after an integer value. > >> >> OLD >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> with namespace identifiers MUST NOT be used. >> >> >> >> NEW >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> with namespace identifiers SHOULD NOT be used. >> >> >> >> >> I strongly object to changing the text above back to OLD. >> The debate has been over top-level nodes missing the prefix, >> not nested nodes that redundantly declare the same module >> as the parent node. > > No, the debate has been for all nodes. Yes, and the difference between OLD and NEW in my original mail is clearly *only* about redundant namespace IDs. > >> We already agreed that the receiver has to parse the module name >> every time in case it is different. It has to remember the parent >> module name in case it is missing in the child nodes. > > No, the point is that with deterministic rules, the receiver doesn't > have to do any special parsing at all. The top-level node > "interfaces" in "ietf-interfaces" is *always* send as > "ietf-interfaces:interfaces", and its child node "interface" is > *always* sent as "interface" and the node "ipv4" that augments the > interface list is *always* sent as "ietf-ip:ipv4". +1 Lada > > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Feb 11 05:33:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B561A88E6 for ; Wed, 11 Feb 2015 05:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1vDhQRJ7xyh for ; Wed, 11 Feb 2015 05:33:25 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04FB1A88B3 for ; Wed, 11 Feb 2015 05:33:24 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-51-54db5a229c36 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 85.01.24955.22A5BD45; Wed, 11 Feb 2015 14:33:22 +0100 (CET) Received: from [159.107.197.247] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.210.2; Wed, 11 Feb 2015 14:33:21 +0100 Message-ID: <54DB5A20.1030707@ericsson.com> Date: Wed, 11 Feb 2015 14:33:20 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/mixed; boundary="------------010000040505030305080901" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUyM+Jvja5S1O0Qg//dfBZXN/5ktJh/sZHV gcljyZKfTB4bDngGMEVx2aSk5mSWpRbp2yVwZczrms1eMMezont3cQPjDZcuRnYOCQETiUUF XYycQJaYxIV769m6GLk4hASOMErM2fuYCcJZyyjR824+I0gVr4C2xO1rN1i7GDk4WARUJRY/ VwcJswkYSUztP88CYosKREnMPv+AFaJcUOLkzCdgcRGBdImmedfYQWxhASWJTwsWgtUwCwRI LGn4ygxiCwloSDy88Jd1AiPvLCTts5CUQdgaEq1z5rJD2PIS29/OAYpzANkeEls+mEGEFSWm dD+EKrGWWLx+KdsCRvZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIFBenDLb9UdjJffOB5i FOBgVOLh3XD0VogQa2JZcWXuIUZpDhYlcV4740MhQgLpiSWp2ampBalF8UWlOanFhxiZODil Ghh5+WvYHZ8+O75jxSze+YYXHQUOr/wp1Kg4ZZaW5ik9vV09u+tUehd0XPvc8O3EoiBjO53I By3Tfvpfb7jxL+65VppDZOF3V9va20ePb0q9F/Zn1tyVrD8U8jj/HNJVOuW0JEjetsrB6b0Q d9nJ8h6+CR8W78y49XSKon9j9XH3dnWZ5YlS04yVWIozEg21mIuKEwFX/+7HMwIAAA== Archived-At: Subject: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 13:33:29 -0000 --------------010000040505030305080901 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Hello Juergen,
I still have an outstanding action point to update the current proposal for non-unique-list.
The only comment I have received was that for replace/merge we should have similar behavior as we have for lists:

For merge and replace if the insert attribute is not present an existing leaf-list value shall not be moved.

Here are my modifications to what can be found on the issue-list http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58.

I merged the two solutions, as they were not real alternatives; the second part about addressing by position, just built on the main part.

regards Balazs



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
--------------010000040505030305080901 Content-Type: text/plain; charset="windows-1252"; name="webModified.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="webModified.txt" DQpEZXNjcmlwdGlvbg0KLS0tLS0tLS0tLS0tLS0tDQoNCkluIFlBTkcgMS4wIGFsbCB2YWx1 ZXMgaW4gYSBsZWFmLWxpc3QgTVVTVCBiZSB1bmlxdWUuIFRoZSBwcm9wb3NhbCBpcyB0byBy ZWxheCB0aGlzIGluIFlBTkcgMS4xLg0KDQpJZiB0aGUgbGVhZi1saXN0IGlzIHVuaXF1ZSB0 aGUgaGFuZGxpbmcgZG9lcyBub3QgY2hhbmdlIGNvbXBhcmVkIHRvIFlBTkcgMS4wDQoNCkEg bm9uVW5pcXVlIGxlYWYtbGlzdCBpcyBzdGlsbCBoYW5kbGVkIGFzIGEgc2V0IG9mIHNlcGFy YXRlIGxlYWZzIGFzIGluIFlBTkcgMS4wDQpOZXcgbWVjaGFuaXNtIHRvIGhhbmRsZSBhbGwg dmFsdWVzIG9mIGEgbGVhZi1saXN0IHRvZ2hldGhlciBhcmUgTk9UIGludHJvZHVjZWQuDQoN CklmIHdlIGhhdmUgYSBsZWFmLWxpc3Qgd2l0aCBub25VbmlxdWUgdmFsdWVzIGluIHRoZSBk YXRhc3RvcmUgYSB2YWx1ZSBpbiB0aGUgDQplZGl0LWNvbmZpZyBhZGRyZXNzZXMgdGhlIGZp cnN0IHN1Y2ggdmFsdWUgaW4gdGhlIGRhdGFzdG9yZS4gDQpUaGlzIGFsdGVybmF0aXZlIGlz IHNlbGVjdGVkIGZvciBzaW1wbGljaXR5Lg0KKE5vdGU6IEFsdGVybmF0aXZlbHkgaXQgY291 bGQgYWRkcmVzcyBhbGwgc3VjaCB2YWx1ZXMgaW4gdGhlIGRhdGFzdG9yZSB3aGljaCANCndv dWxkIGJlIHNpbXBsZSBmb3IgZGVsZXRlL3JlbW92ZSwgYnV0IHN0cmFuZ2UgZm9yIHJlcGxh Y2UgYW5kIG1lcmdlLiBNZXJnZSBzaG91bGQgDQpiZSBhZGRpdGl2ZSBidXQgbWVyZ2luZyBb YSxhLGFdIHdpdGggW2FdIHdvdWxkIHJlc3VsdCBpbiBbYV0gd2hpY2ggaXMgbm90IA0KYWRk aXRpdmUuIEl0IHdvdWxkIGJlIHZlcnkgc3RyYW5nZSBmb3IgaW5zZXJ0LWFmdGVyOyB3ZSB3 YW50IHRvIGluc2VydCBvbmUgdmFsdWUsIGJ1dCBzdWRkZW5seSANCml0IGNhbiBiZWNvbWUg bXVsdGlwbGUgdmFsdWVzLikNCg0KDQpTb2x1dGlvbiBZNTctMDENCg0KICAgIENoYW5nZSB0 byBzZWN0aW9uIDM6DQoNCmxlYWYtbGlzdDogTGlrZSB0aGUgbGVhZiBub2RlIGJ1dCBkZWZp bmVzIGEgc2V0IG9mIHVuaXF1ZWx5IGlkZW50aWZpYWJsZSANCm5vZGVzIHJhdGhlciB0aGFu IGEgc2luZ2xlIG5vZGUuIEVhY2ggbm9kZSBoYXMgYSB2YWx1ZSBidXQgbm8gY2hpbGQgbm9k ZXMuDQoNCmNoYW5nZSB0bw0KDQpsZWFmLWxpc3Q6IExpa2UgdGhlIGxlYWYgbm9kZSBidXQg ZGVmaW5lcyBhIHNldCBvZiBub2RlcyByYXRoZXIgdGhhbiBhIA0Kc2luZ2xlIG5vZGUuIEVh Y2ggbm9kZSBoYXMgYSB2YWx1ZSBidXQgbm8gY2hpbGQgbm9kZXMuDQoNCiAgICBDaGFuZ2Ug dG8gc2VjdGlvbiA0LjIuMi4yOg0KDQogICAgQSBsZWFmLWxpc3QgaXMgYSBzZXF1ZW5jZSBv ZiBsZWFmIG5vZGVzIHdpdGggZXhhY3RseSBvbmUgdmFsdWUgb2YgYSBwYXJ0aWN1bGFyIHR5 cGUgcGVyIGxlYWYuDQoNCldoYXQgZG9lcyB0aGlzIG1lYW4/IERvZXMgaXQgbWVhbiB0aGF0 IGxlYWYtbGlzdHMgbmVlZCB0byBoYXZlIHVuaXF1ZSBsZWFmcz8gQ2hhbmdlIHRvOg0KDQpB IGxlYWYtbGlzdCBpcyBhIHNlcXVlbmNlIG9mIGxlYWYgbm9kZXMuDQoNCiAgICBSZW1vdmUg ZnJvbSBzZWN0aW9uIDcuNzoNCg0KICAgIFRoZSB2YWx1ZXMgaW4gYSBsZWFmLWxpc3QgTVVT VCBiZSB1bmlxdWUuDQogICAgDQogICAgQWRkIHRvIHNlY3Rpb24gNy43LjI6DQoNCiAgICB1 bmlxdWUtbGVhZi1saXN0IGNhcmRpbmFsaXR5IDAuLjENCiAgICANCiAgICBBZGQgYSBsZXZl bCAzIHNlY3Rpb24gYmVmb3JlIDcuNy42Og0KDQogICAgNy43LjViIFRoZSB1bmlxdWUtbGVh Zi1saXN0IFN0YXRlbWVudA0KDQogICAgVGhlICJ1bmlxdWUtbGVhZi1saXN0IiBzdGF0ZW1l bnQgdGFrZXMgYXMgYW4gYXJndW1lbnQgdGhlIHN0cmluZyAidHJ1ZSIgb3IgImZhbHNlIi4g DQogICAgSWYgInVuaXF1ZS1sZWFmLWxpc3QiIGlzICJ0cnVlIiwgdmFsdWVzIHdpdGhpbiB0 aGUgbGVhZi1saXN0cyBtdXN0IGJlIHVuaXF1ZS4gDQogICAgSWYgInVuaXF1ZS1sZWFmLWxp c3QiIGlzICJmYWxzZSIsIHZhbHVlcyB3aXRoaW4gdGhlIGxlYWYtbGlzdHMgbWF5IGJlIHJl cGVhdGVkLiANCiAgICBJZiAidW5pcXVlLWxlYWYtbGlzdCIgaXMgbm90IHNwZWNpZmllZCwg dGhlIGRlZmF1bHQgaXMgdHJ1ZS4NCiAgICANCiAgICBDaGFuZ2Ugc2VjdGlvbiA3LjcuNw0K DQogICAgVGhlIG9wZXJhdGlvbnMgd2F5IG9mIHdvcmtpbmcgaXMgZGVwZW5kZW50IG9uIHRo ZSB2YWx1ZSBvZiB1bmlxdWUtbGVhZi1saXN0LiANCiAgICBJZiB1bmlxdWUtbGVhZi1saXN0 IGlzIHRydWUgdGhlIGN1cnJlbnQgaGFuZGxpbmcgaXMgdW5jaGFuZ2VkLiANCiAgICBJZiB1 bmlxdWUtbGVhZi1saXN0IGlzIGZhbHNlIHRoZSBmb2xsb3dpbmcgYXBwbGllczoNCg0KICAg IGRlbGV0ZS9yZW1vdmU6IGRlbGV0ZS9yZW1vdmUgdGhlIGFkZHJlc3NlZCB2YWx1ZSAoZmly c3Qgb2NjdXJlbmNlKSBmcm9tIHRoZSANCiAgICBsZWFmLWxpc3QuIElmIGEgdmFsdWUgZXhp c3RzIG11bHRpcGxlIHRpbWVzIGluIGVkaXQtY29uZmlnIHRyeSB0byANCiAgICBkZWxldGUg Mi8zLy4uIGluc3RhbmNlcyBvZiB0aGUgdmFsdWUuIEZvciBkZWxldGUgaXQgaXMgYW4gZXJy b3IgaWYgDQogICAgaW5zdWZmaWNpZW50IHZhbHVlIGluc3RhbmNlcyBleGlzdCBpbiBkYXRh c3RvcmUuDQoNCiAgICBjcmVhdGU6IGNyZWF0ZSB2YWx1ZS4gSXQgc3VjY2VlZHMgZXZlbiBp ZiB2YWx1ZSBhbHJlYWR5IGV4aXN0cywganVzdCBhZGRzIHRoZSANCiAgICB2YWx1ZSBvbmNl IG1vcmUuIElmIG5vICJpbnNlcnQiIGF0dHJpYnV0ZSBpcyBwcmVzZW50IGluIHRoZSAiY3Jl YXRlIiBvcGVyYXRpb24sIA0KICAgIGl0IGRlZmF1bHRzIHRvICJsYXN0Ii4gSWYgYSB2YWx1 ZSBleGlzdHMgbXVsdGlwbGUgdGltZXMgaW4gZWRpdC1jb25maWcgcmVwZWF0IA0KICAgIHRo ZSBzdGVwcy4NCg0KICAgIHJlcGxhY2UsIG1lcmdlOiBGb3IgZWFjaCBzcGVjaWZpYyB2YWx1 ZSwgdGhlIG51bWJlciBvZiBpbnN0YW5jZXMgb2YgdGhlIHZhbHVlIA0KICAgIGluIGVkaXQt Y29uZmlnIGFuZCB0aGUgZGF0YXN0b3JlIGFyZSBtYXRjaGVkIGFnYWluc3QgZWFjaCBvdGhl ci4gDQogICAgDQogICAgRm9yIGVhY2ggc3VjaCB2YWx1ZSBpbnN0YW5jZSBpZiBpbnNlcnQg aXMgbm90IHNwZWNpZmllZCB0aGUgdmFsdWUgaW4gdGhlIGRhdGFzdG9yZSBpcyBsZWZ0IHVu Y2hhbmdlZC4gDQoNCiAgICBJZiB0aGUgaW5zZXJ0IGlzIHNwZWNpZmllZCwgZGVsZXRlIHRo ZSAoZmlyc3QvbWF0Y2hpbmcpIHZhbHVlIGluIHRoZSBkYXRhc3RvcmUsIGlmIA0KICAgIGl0 IGV4aXN0cywgYW5kIHJlLWNyZWF0ZSBpdCBhcyBzcGVjaWZpZWQgYnkgDQogICAgaW5zZXJ0 LiBJZiB0aGUgaW5zZXJ0IGF0dHJpYnV0ZSByZWZlcnMgdG8gYSB2YWx1ZSwgaXQgaXMgdGhl IGZpcnN0IG9jY3VycmVuY2UgDQogICAgb2YgdGhlIHZhbHVlIHRoYXQgaXMgaW5kaWNhdGVk LiBJZiBhIHZhbHVlIGV4aXN0cyBtdWx0aXBsZSB0aW1lcyBpbiBlZGl0LWNvbmZpZyANCiAg ICByZXBlYXQgdGhlIHN0ZXBzLg0KICAgIA0KICAgIElmIGVkaXQtY29uZmlnIGNvbnRhaW5z IG1vcmUgaW5zdGFuY2VzLCB0aGUgYWRkaXRpb25hbCBvbmVzIGFyZSBjcmVhdGVkIGFzIA0K ICAgIGluIGEgY3JlYXRlIG9wZXJhdGlvbi4gSWYgdGhlIGRhdGFzdG9yZSBjb250YWlucyBt b3JlIGluc3RhbmNlcywgdGhleSBhcmUgbm90IG1vZGlmaWVkLg0KICAgIA0KICAgID09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiAgICANCg0KDQoNClBv c2l0aW9uIGNhbiBiZSB1c2VkIHRvIHNlbGVjdCBhIGxlYWYgaW4gYSBsZWFmLWxpc3QsIGJ1 dCBvbmx5IGlmIGl0IGlzICJvcmRlcmVkLWJ5IHVzZXIiLiANCkZvciBzeXN0ZW0tb3JkZXJl ZCBsaXN0cyB0aGlzIGxlYWRzIHRvIGVycm9yLiAoU2FtZSBhcyBpbnNlcnQpDQoNClBvc2l0 aW9uIG11c3QgYmUgYmV0d2VlbiAxIGFuZCB0aGUgbGVuZ3RoIG9mIHRoZSBsZWFmLWxpc3Qs IGlmIGl0IGlzIG5vdCwgc2VuZCBhbiBlcnJvciBtZXNzYWdlLiANCkluZGV4aW5nIHN0YXJ0 cyBhdCAxIG5vdCAwLCBmb2xsb3dpbmcgWFBBVEggY29udmVudGlvbnMuDQoNCkluIGEgZGVs ZXRlL3JlbW92ZSBvcGVyYXRpb24gaWYgcG9zaXRpb24gaXMgc3BlY2lmaWVkLCB0aGUgdmFs dWUgb2YgdGhlIGxlYWYtaW5zdGFuY2UsIGhhcyBubyBlZmZlY3QsIA0KaXQgbWF5IGJlIG9t aXR0ZWQgYnkgdGhlIGNsaWVudC4gKEFkZHJlc3NpbmcgYnkgcG9zaXRpb24gdGFrZXMgcHJl Y2VkZW5jZSBvdmVyIGFkZHJlc3NpbmcgYnkgdmFsdWUuKQ0KDQpJZiBib3RoIHRoZSBwb3Np dGlvbiBhbmQgdGhlIHZhbHVlIGF0dHJpYnV0ZXMgYXJlIHNwZWNpZmllZCBpbiBlZGl0LWNv bmZpZyBmb3IgdGhlIHNhbWUgZGF0YSBub2RlLCANCnRoZSB2YWx1ZSBhdHRyaWJ1dGUgaGFz IG5vIGVmZmVjdCBhbmQgbWF5IGJlIChzaG91bGQgYmUpIG9tbWl0dGVkIGJ5IHRoZSBjbGll bnQuDQoNCklmIHBvc2l0aW9uIGlzIHNwZWNpZmllZCwgdGhlIGluc2VydCBhdHRyaWJ1dGUg Y2FuIG9ubHkgdGFrZSB0aGUgdmFsdWVzIGFmdGVyIGFuZCBiZWZvcmUuIEZpcnN0IA0KYW5k IGxhc3QgYXJlIGVycm9yLiAoVGhlcmUgaXMgbm8gc2Vuc2UgaW4gc3BlY2lmeWluZyBwb3Np dGlvbiBvbmNlIHRoZSBpbnNlcnQ9Zmlyc3QvbGFzdCBpcyBzcGVjaWZpZWQsIA0KaXQgd291 bGQganVzdCBhZGQgb25lIG1vcmUgdXNlbGVzcyBhbmQgY29tcGxpY2F0ZWQgY2FzZS4pDQoN CiAgICBGdXJ0aGVyIGNoYW5nZXMgdG8gc2VjdGlvbiA3LjcuOToNCg0KICAgIEluIGFuICJv cmRlcmVkLWJ5IHVzZXIiIGxlYWYtbGlzdCwgdGhlIGF0dHJpYnV0ZSAicG9zaXRpb24iIGlu IHRoZSBZQU5HIFhNTCBuYW1lc3BhY2UgKFNlY3Rpb24gNS4zLjEpIA0KICAgIGNhbiBiZSB1 c2VkIHRvIGFkZHJlc3Mgc3BlY2lmaWMgdmFsdWVzIGluIHRoZSBsZWFmLWxpc3QuDQoNCiAg ICBjcmVhdGU6IGFkZDogSWYgcG9zaXRpb24gaXMgc3BlY2lmaWVkIGJ1dCBpbnNlcnQgaXMg bm90IHNwZWNpZmllZCBpbnNlcnQ9YWZ0ZXIgaXMgaW1wbGllZC4NCg0KICAgIHJlcGxhY2Uv bWVyZ2U6IGlmIHBvc2l0aW9uIGlzIHNwZWNpZmllZCBidXQgaW5zZXJ0IGlzIG5vdCwgcmVw bGFjZSB0aGUgdmFsdWUgc3BlY2lmaWVkIGJ5IHBvc2l0aW9uLiANCiAgICBJZiBib3RoIHBv c2l0aW9uIGFuZCBpbnNlcnQ9YWZ0ZXIvYmVmb3JlIGlzIHNwZWNpZmllZCwgaW5zZXJ0IGEg bmV3IGxlYWYgd2l0aCB0aGUgdmFsdWUgYXQgdGhlIHNwZWNpZmllZCBwb3NpdGlvbi4gKHJl cGxhY2UvbWVyZ2Ugd29ya3MgZGlmZmVybnRseSB3aXRoIGFuZCB3aXRob3V0IHBvc2l0aW9u LikNCg0K --------------010000040505030305080901-- From nobody Wed Feb 11 07:27:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37581A0389 for ; Wed, 11 Feb 2015 07:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QzJ-n0QWEx7 for ; Wed, 11 Feb 2015 07:27:28 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 069B01A0398 for ; Wed, 11 Feb 2015 07:27:28 -0800 (PST) Received: by labpn19 with SMTP id pn19so4045873lab.4 for ; Wed, 11 Feb 2015 07:27:26 -0800 (PST) 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:content-type; bh=XeP4g78ufbPIxT/BKYS5MD8+MJEM8UXU+OVNDTEUpn4=; b=Vx/5AO0PIiLN36MGb5maQ+EBLDvgsReSqdZ/7uCd5XD3QfY6F5W+qcYeLo5//kPKl3 85Gfqmc/ZoRUVqpvKbg+y7XZucaQ3pss6xJThL5IRsotqHeRNPAJrVgR2caHHhRJyDJN zrUIngyCaRU4voBNXSdsYER38JEA3orSjUBKWdQsIlDflr3M7EGJHg68tUSF/YtPaEir VV50VvcqtFS2fSLmJxNGo+5DQEA/kzWPZJYOLBFuiZuRxdZyELR50VZScO2QBA7MTKN6 u0Z5XmW8tlUcj2Prx1rlkzn7YtBULbhggcMySlQTP7RxfGWMu8TNyj266BjUjQmBGAxS wgRA== X-Gm-Message-State: ALoCoQlLXoEyTfKAZeLKRSup0OPij8DxiQ6HLKaW9mXLmpcifzMbaDhEiU4iLczBNPZXdw3pNISL MIME-Version: 1.0 X-Received: by 10.112.171.168 with SMTP id av8mr8305382lbc.88.1423668446308; Wed, 11 Feb 2015 07:27:26 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 11 Feb 2015 07:27:26 -0800 (PST) In-Reply-To: <54DB5A20.1030707@ericsson.com> References: <54DB5A20.1030707@ericsson.com> Date: Wed, 11 Feb 2015 07:27:26 -0800 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 15:27:31 -0000 Hi, I cannot tell if delete is supposed to be delete-first or delete-all. It seems to be the latter from the text. The other operations seem to affect only 1 leaf-list instance. It seems that delete and re-create needs to be used to move the 2nd - Nth instance of a leaf-list (with value 'foo'). A merge or replace (w/ insert attr to make it a move) will always move the first instance. But delete affects only the first (or all?) instances. So I don't see how the 2nd to Nth instances can ever be moved. Seems like you would need to delete-all, then add back each instance. It seems the order the edits are applied (from 1 ) would be critical -- not something that is supported by NETCONF, so N edits would be needed, not 1. Andy On Wed, Feb 11, 2015 at 5:33 AM, Balazs Lengyel wrote: > Hello Juergen, > I still have an outstanding action point to update the current proposal for > non-unique-list. > The only comment I have received was that for replace/merge we should have > similar behavior as we have for lists: > > For merge and replace if the insert attribute is not present an existing > leaf-list value shall not be moved. > > Here are my modifications to what can be found on the issue-list > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58. > > I merged the two solutions, as they were not real alternatives; the second > part about addressing by position, just built on the main part. > > regards Balazs > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Feb 11 08:14:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C811A86DD for ; Wed, 11 Feb 2015 08:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRD_OTFKj_bv for ; Wed, 11 Feb 2015 08:14:05 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 7876F1A0393 for ; Wed, 11 Feb 2015 08:13:59 -0800 (PST) Received: by labpv20 with SMTP id pv20so4346553lab.8 for ; Wed, 11 Feb 2015 08:13:57 -0800 (PST) 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:content-type; bh=+X1clGWiyNuPa4oA9cklT9eYuGzVPQMaQcfV1XvwoTc=; b=Q6Ky/wRJ8p3kf+VtLfU121aJwFhqWTyh6Lrmg3Du4WkylyEob8nfPciNI0VANrdiwd c3LcQfxClBiN6b7tFyeqnoAkHq7HBfpnWPXNpu4DnHpz9R3v8zXJPfKRqytx3IUuk87F qaeDqF8Zqi1k5mGRJj2oJWuCK89eRGDfKwj29y5ACe6gSd0abg69XWS2PBMUJeqnwzbr AV67Q7b2bCZtciKkHFrRxDzUwca6wyQuMzEImLv0O9NL3/tM1hsjI2ocRCCo2kEEQNNr qUAAYf8v/hcKO+dweBPlFejV52zb2x4SGBKihhDFH05NHBnaEhHeJ68GwI0YdcANTOjZ axxQ== X-Gm-Message-State: ALoCoQmB8N/iAneUVcj6NPCjDDsY/aqMXDEz5d8R3j+uYsh0S9YCj2V+WgMHDEiV8Mfr/qArwdOa MIME-Version: 1.0 X-Received: by 10.112.142.168 with SMTP id rx8mr28190170lbb.37.1423671237813; Wed, 11 Feb 2015 08:13:57 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 11 Feb 2015 08:13:57 -0800 (PST) In-Reply-To: <54DB5A20.1030707@ericsson.com> References: <54DB5A20.1030707@ericsson.com> Date: Wed, 11 Feb 2015 08:13:57 -0800 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 16:14:13 -0000 Hi, I don't know if it is such a good idea to add more whistles to a broken construct. IMO leaf-list is incomplete because (unlike list) the individual values are really managed as a group. But there is no create-all, delete-all, get-all support in any protocol. A leaf-list has to be placed in an NP-container by itself, which adds a layer and complexity to the model. I would be in favor of a comprehensive fix that made leaf-list as useful as other YANG data node types. This would require protocol changes. I would really prefer not to continue defining NETCONF protocol behavior in the YANG spec. YANG 1.1 could be obsolete before it is even published, because it is so protocol-specific and new protocols will be using it that are not mentioned. IMO all protocol details need to be moved out of YANG 1.1 into a NETCONF mapping document. RESTCONF and other protocols can be specified in their own mapping documents as well. Andy On Wed, Feb 11, 2015 at 5:33 AM, Balazs Lengyel wrote: > Hello Juergen, > I still have an outstanding action point to update the current proposal for > non-unique-list. > The only comment I have received was that for replace/merge we should have > similar behavior as we have for lists: > > For merge and replace if the insert attribute is not present an existing > leaf-list value shall not be moved. > > Here are my modifications to what can be found on the issue-list > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58. > > I merged the two solutions, as they were not real alternatives; the second > part about addressing by position, just built on the main part. > > regards Balazs > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Feb 11 10:42:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9746D1A1A91 for ; Wed, 11 Feb 2015 10:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl18EJdlBgQK for ; Wed, 11 Feb 2015 10:42:42 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0742.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:742]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696751A1A74 for ; Wed, 11 Feb 2015 10:42:42 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 11 Feb 2015 18:42:13 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.134]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.134]) with mapi id 15.01.0081.018; Wed, 11 Feb 2015 18:42:13 +0000 From: Kent Watsen To: Andy Bierman , Balazs Lengyel Thread-Topic: [netmod] Y57: non-unique leaf-list Thread-Index: AQHQRf9ezl3OKDzQYEaV6p9tnPIPY5zrn3qA///VmAA= Date: Wed, 11 Feb 2015 18:42:12 +0000 Message-ID: References: <54DB5A20.1030707@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.239.10] authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(83506001)(62966003)(86362001)(54356999)(76176999)(66066001)(87936001)(50986999)(2900100001)(2950100001)(77156002)(102836002)(2656002)(92566002)(106116001)(122556002)(40100003)(46102003)(99286002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2015 18:42:12.6531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 18:42:48 -0000 >I would really prefer not to continue defining NETCONF protocol behavior >in the YANG spec. YANG 1.1 could be obsolete before it is even >published, because it is so protocol-specific and new protocols will >be using it that are not mentioned. IMO all protocol details need to be >moved out of YANG 1.1 into a NETCONF mapping document. >RESTCONF and other protocols can be specified in their own >mapping documents as well. I agree with this sentiment. So as to not introduce an immediate need for 6241bis, could YANG 1.1 move all its NETCONF-specific mapping text into an Addendum section? - how much such text is there? Kent From nobody Wed Feb 11 11:33:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0DA1A1B37 for ; Wed, 11 Feb 2015 11:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPacUMqpXJxR for ; Wed, 11 Feb 2015 11:33:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id C8BD91A1A13 for ; Wed, 11 Feb 2015 11:33:21 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 9234A1280A55; Wed, 11 Feb 2015 20:33:20 +0100 (CET) Date: Wed, 11 Feb 2015 20:33:20 +0100 (CET) Message-Id: <20150211.203320.92241038305058998.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <54DB5A20.1030707@ericsson.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] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 19:33:23 -0000 Kent Watsen wrote: > > >I would really prefer not to continue defining NETCONF protocol behavior > >in the YANG spec. YANG 1.1 could be obsolete before it is even > >published, because it is so protocol-specific and new protocols will > >be using it that are not mentioned. IMO all protocol details need to be > >moved out of YANG 1.1 into a NETCONF mapping document. > >RESTCONF and other protocols can be specified in their own > >mapping documents as well. > > > I agree with this sentiment. So as to not introduce an immediate need for > 6241bis, could YANG 1.1 move all its NETCONF-specific mapping text into an > Addendum section? - how much such text is there? It is quite a lot. But my idea is to try to move the NETCONF text to a separate document, but I don't want to do that until all other issues are resolved. It will be a big diff... if it is possible at all. I think we need to keep the examples though. /martin From nobody Wed Feb 11 12:07:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290361A90A4 for ; Wed, 11 Feb 2015 12:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZl7wEIDMWvt for ; Wed, 11 Feb 2015 12:06:49 -0800 (PST) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (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 F31E71A909C for ; Wed, 11 Feb 2015 12:06:25 -0800 (PST) Received: by pdno5 with SMTP id o5so6498639pdn.8 for ; Wed, 11 Feb 2015 12:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=0yJ+CU7F532FMhSfoSlsi+r0d4IU9430RDg6B2y9EdY=; b=Pwwq1DKh+beM8xYlXRDEY+Ppjy+yTsujNrie8y6sqogSX6MFvxB3TDrLYj/3fTkuMD A1Z9Leknbgs8kNaGvYi3wN5yh3x3JHlkuTQqYcdaZz8SsGjx1YXtffL1YIib4fTfLMq0 c9IQBC1xPVIXh0GbrZ0oVCEptoPvVDSBOtKsGWN1Jf2RLUZWFHyv10vRh7mQTa+k33tI iL5EYUxj6KE09DC8zKxkO3fRnXliIBnW9/sBPW7EQJeFEYF7L0zjvyFy1ClKIs5woYsP PBjZWTOjCPSgLVDkBlFIv1f/53iuuyJxUoXjWcP6EdJPWsLUipqCFrj4f8BAGUjM8Eff AMxA== X-Received: by 10.66.146.193 with SMTP id te1mr229010pab.109.1423685185653; Wed, 11 Feb 2015 12:06:25 -0800 (PST) Received: from [10.108.144.125] ([166.170.36.102]) by mx.google.com with ESMTPSA id gk1sm1645254pbb.61.2015.02.11.12.06.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Feb 2015 12:06:24 -0800 (PST) References: <54DB5A20.1030707@ericsson.com> <20150211.203320.92241038305058998.mbj@tail-f.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20150211.203320.92241038305058998.mbj@tail-f.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Nabil Date: Wed, 11 Feb 2015 12:06:03 -0800 To: Martin Bjorklund Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 20:06:59 -0000 Hi, I don't quite understand how YANG is defined as the language to express NETC= ONF operations and the requirement now to make it protocol agnostic. Will th= e original definition change as well? Thanks, Nabil > On Feb 11, 2015, at 11:33 AM, Martin Bjorklund wrote: >=20 > Kent Watsen wrote: >>=20 >>> I would really prefer not to continue defining NETCONF protocol behavior= >>> in the YANG spec. YANG 1.1 could be obsolete before it is even >>> published, because it is so protocol-specific and new protocols will >>> be using it that are not mentioned. IMO all protocol details need to be= >>> moved out of YANG 1.1 into a NETCONF mapping document. >>> RESTCONF and other protocols can be specified in their own >>> mapping documents as well. >>=20 >>=20 >> I agree with this sentiment. So as to not introduce an immediate need fo= r >> 6241bis, could YANG 1.1 move all its NETCONF-specific mapping text into a= n >> Addendum section? - how much such text is there? >=20 > It is quite a lot. But my idea is to try to move the NETCONF text to > a separate document, but I don't want to do that until all other > issues are resolved. It will be a big diff... if it is possible at > all. I think we need to keep the examples though. >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 11 12:28:20 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D561A1BCC for ; Wed, 11 Feb 2015 12:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOFTpGa9gS2v for ; Wed, 11 Feb 2015 12:28:13 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 9F2761A1BC3 for ; Wed, 11 Feb 2015 12:28:10 -0800 (PST) Received: by labgq15 with SMTP id gq15so5901691lab.3 for ; Wed, 11 Feb 2015 12:28:09 -0800 (PST) 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:content-type; bh=XTPCQgbz0XtQq3MD0fyH7Lm1cmKhFzxPR0HmXTaq6BQ=; b=d8eTo/T2JYAJebUj3tG0hxATp7EaAWomOIWO/EMjNPx0SOqgr6EzaaKH2zY4Jj4MYm z9eegLQ/tdKjOrwAOGOJe1uHQn/jfRF+XoA15XDEFMO7nxWLRGG3rtiSfj03MULF0C6z OJLpNDXP3EiaDbdHCzxf9dFc2MjxB4lRXlaR4MVW6bsv5kbJomqNRecUoStk02yCdIio P5MJEZluLSg3cHp9LlI5/qJ30YvH6w/XDsyN+uouvdQR70T9bR4V8c9n75hd9Q9nhH28 au+haKi613UAT1ggvdvkmuVvXpQQLF9+g4zYS9dYeZwjgGeSc7nq0gJTJ6d5C5M4n19T gfsQ== X-Gm-Message-State: ALoCoQk7ZGp+3bYhXu5Ex3PuSiJ0EUyG9GP4L9WI/h1bvtYOEjJL+Ng0Iw4RfBi1Fu2YBgFANZ8a MIME-Version: 1.0 X-Received: by 10.112.171.168 with SMTP id av8mr368114lbc.88.1423686488944; Wed, 11 Feb 2015 12:28:08 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 11 Feb 2015 12:28:08 -0800 (PST) In-Reply-To: References: <54DB5A20.1030707@ericsson.com> <20150211.203320.92241038305058998.mbj@tail-f.com> Date: Wed, 11 Feb 2015 12:28:08 -0800 Message-ID: From: Andy Bierman To: Nabil Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 20:28:17 -0000 On Wed, Feb 11, 2015 at 12:06 PM, Nabil wrote: > Hi, > > I don't quite understand how YANG is defined as the language to express NETCONF operations and the requirement now to make it protocol agnostic. Will the original definition change as well? > You mean the title? I guess so. IMO YANG can be defined so it identifies the inputs, outputs, and behavior of a data model property, and assigns a generic protocol codepoint to it like "leaf-list insert function". Each protocol will define the real mechanism in its mapping document (or indicate it is not supported). > Thanks, > Nabil > Andy > > >> On Feb 11, 2015, at 11:33 AM, Martin Bjorklund wrote: >> >> Kent Watsen wrote: >>> >>>> I would really prefer not to continue defining NETCONF protocol behavior >>>> in the YANG spec. YANG 1.1 could be obsolete before it is even >>>> published, because it is so protocol-specific and new protocols will >>>> be using it that are not mentioned. IMO all protocol details need to be >>>> moved out of YANG 1.1 into a NETCONF mapping document. >>>> RESTCONF and other protocols can be specified in their own >>>> mapping documents as well. >>> >>> >>> I agree with this sentiment. So as to not introduce an immediate need for >>> 6241bis, could YANG 1.1 move all its NETCONF-specific mapping text into an >>> Addendum section? - how much such text is there? >> >> It is quite a lot. But my idea is to try to move the NETCONF text to >> a separate document, but I don't want to do that until all other >> issues are resolved. It will be a big diff... if it is possible at >> all. I think we need to keep the examples though. >> >> >> /martin >> >> _______________________________________________ >> 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 Wed Feb 11 12:29:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1583E1A028A for ; Wed, 11 Feb 2015 12:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjDvPxGiOCFQ for ; Wed, 11 Feb 2015 12:29:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1873B1A1B84 for ; Wed, 11 Feb 2015 12:29:33 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 288331280A44; Wed, 11 Feb 2015 21:29:32 +0100 (CET) Date: Wed, 11 Feb 2015 21:29:32 +0100 (CET) Message-Id: <20150211.212932.1809512817443078851.mbj@tail-f.com> To: nabil.michraf@gmail.com From: Martin Bjorklund In-Reply-To: References: <20150211.203320.92241038305058998.mbj@tail-f.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] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 20:29:53 -0000 Nabil wrote: > Hi, > > I don't quite understand how YANG is defined as the language to > express NETCONF operations and the requirement now to make it protocol > agnostic. Will the original definition change as well? The goal is NOT to make YANG protocol agnostic; we know that will never work. The goal is to separate the protocol-specific parts from the language-definition parts. As has been shown with RESTCONF and JSON, YANG can be used by other protocols than NETCONF and other encodings than XML - if the protocol is designed for YANG models. (There are also proprietary protocols and encodings). /martin From nobody Wed Feb 11 14:55:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DB11A1B9E; Wed, 11 Feb 2015 14:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 OpdzwUz8ud9b; Wed, 11 Feb 2015 14:55:45 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5361A1A1E; Wed, 11 Feb 2015 14:55:44 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "idr wg" References: <1716926046.1975221423694292688.JavaMail.nobody@rva2rmd002.webex.com> In-Reply-To: <1716926046.1975221423694292688.JavaMail.nobody@rva2rmd002.webex.com> Date: Wed, 11 Feb 2015 17:55:35 -0500 Message-ID: <074c01d0464d$d92d11a0$8b8734e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_074D_01D04623.F057F400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHJ57GBwTjsxCJFcI4UebhxZCloJpz4yCiQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, "'Ken Gray \(kegray\)'" , netmod@ietf.org, NETCONF , "John G. Scudder" Subject: [netmod] FW: WebEx recording is available for viewing: IDR Interim 2/9 - BGP Yang Modules-20150209 1500-1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 22:55:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_074D_01D04623.F057F400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IDR Working Group wants to share this WebEx recording with you.=20 IDR Interim 2/9 - BGP Yang Modules-20150209 1500-1=20 Monday, February 9, 2015=20 11:17 am | Eastern Standard Time (New York, GMT-05:00)=20 PLAY RECORDING (1 hr 8 min)=20 https://ietf.webex.com/ietf/ldr.php?RCID=3Ddad5cf872d4469f95ad00b0330f8e9= d8=20 This is the recording of the discussion of the BGP Yang modules. =20 = draft-zhdankin-idr-bgp-cfg-00 = draft-shaikh-idr-bgp-model-00=20 =20 Sue Hares=20 ------=_NextPart_000_074D_01D04623.F057F400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


IDR = Working Group wants to share this WebEx recording with you. =


IDR Interim 2/9 - BGP Yang Modules-20150209 1500-1 =
Monday, February 9, 2015
11:17 am | Eastern Standard Time (New = York, GMT-05:00)


PLAY RECORDING (1 hr 8 min)
https://ietf.webex.com/ietf/ldr.php?RCID=3Ddad5cf872d44= 69f95ad00b0330f8e9d8

This is the recording of the discussion of the BGP Yang = modules.=C2=A0

draft-zhdankin-idr-bgp-cfg-00

draft-shaikh-idr-bgp-model-00

 

Sue Hares

------=_NextPart_000_074D_01D04623.F057F400-- From nobody Wed Feb 11 19:16:48 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DB91A1B77 for ; Wed, 11 Feb 2015 19:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSwQgdl7O3gH for ; Wed, 11 Feb 2015 19:16:39 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 3EE021A1B35 for ; Wed, 11 Feb 2015 19:16:39 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id u10so7078432lbd.7 for ; Wed, 11 Feb 2015 19:16:37 -0800 (PST) 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:content-type; bh=BkVzH6ugkxhFE2uYEG2WGcJsvQY0w5YglYxh17EpuN4=; b=IfeUgP7qbga171r9ctL+AdETxXRVuFA0StEcpXA9V6u2zP9tMUDvHVWvpEgaXJhKrb Kt0z9YKDZZy8k8TUpjKTu1tz6KgXEtcMH4CM0+2slFmsl7d0SIaMFgLdfHpt97hXTRMi awx1tQ/y0CfNxtisuxg8RQQY5d+E9sgeuaEtqH4HlpSpOcEd8ILYv1RKW5tXw5BBnitE y+0boDIRAYAvFNm3QMjTbP6DTWoNOOnu6rVHr4HAChycu5ewsInzC5zRdblAshWmSS2c 0P4FTFIIqyQlOm2B8m0mdXU/00s8N0wj6hAfFQhWdF0AmjPZRXtAE+jNhQex8zicrvxo ih1A== X-Gm-Message-State: ALoCoQmtNKnUQo7TVz83whvPWnNO8oW/1IU3p9C6La3hZM8Zko7ubj/cQKmawQs7qACB0ykFaVuE MIME-Version: 1.0 X-Received: by 10.112.171.168 with SMTP id av8mr1428374lbc.88.1423710997178; Wed, 11 Feb 2015 19:16:37 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 11 Feb 2015 19:16:36 -0800 (PST) In-Reply-To: <20150210.221935.1416907161721598337.mbj@tail-f.com> References: <20150210.215550.1438604762585678944.mbj@tail-f.com> <20150210.221935.1416907161721598337.mbj@tail-f.com> Date: Wed, 11 Feb 2015 19:16:36 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 03:16:45 -0000 On Tue, Feb 10, 2015 at 1:19 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Tue, Feb 10, 2015 at 12:55 PM, Martin Bjorklund wrote: >> > Andy Bierman wrote: >> >> On Tue, Feb 10, 2015 at 12:29 PM, Martin Bjorklund wrote: >> >> > Andy Bierman wrote: >> >> >> On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund wrote: >> >> >> > Andy Bierman wrote: >> >> >> >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: >> >> >> >> > Hi, >> >> >> >> > >> >> >> >> > I'll try to summarize this long thread. Please comment. >> >> >> >> > >> >> >> >> > Ladislav Lhotka writes: >> >> >> >> > >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> $SUBJ is already several months late, so I think we should proceed >> >> >> >> >> towards delivering it. I checked my mail archive since the -02 revision, >> >> >> >> >> and it seems two issues need to be resolved: >> >> >> >> >> >> >> >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I >> >> >> >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> >> >> >> >> instead of MUST NOT): >> >> >> >> > >> >> >> >> > It seems Andy is now the only supporter of this change, and I think >> >> >> >> > there are strong technical reasons for keeping namespace rules strict, >> >> >> >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or >> >> >> >> > reformulate the text in the same sense without using 2119 keywords. >> >> >> > >> >> >> > I think it would be wise to rewrite the text to explain how the >> >> >> > different nodes (top-level in module, top-level in remote augment and >> >> >> > other) are encoded. The current 2119 language seems to indicate that >> >> >> > there is some kind of choice involved. >> >> >> > >> >> >> >> >> OLD >> >> >> >> >> >> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> >> >> >> with namespace identifiers MUST NOT be used. >> >> >> >> >> >> >> >> >> >> NEW >> >> >> >> >> >> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> >> >> >> with namespace identifiers SHOULD NOT be used. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I strongly object to changing the text above back to OLD. >> >> >> >> The debate has been over top-level nodes missing the prefix, >> >> >> >> not nested nodes that redundantly declare the same module >> >> >> >> as the parent node. >> >> >> > >> >> >> > No, the debate has been for all nodes. >> >> >> > >> >> >> >> We already agreed that the receiver has to parse the module name >> >> >> >> every time in case it is different. It has to remember the parent >> >> >> >> module name in case it is missing in the child nodes. >> >> >> > >> >> >> > No, the point is that with deterministic rules, the receiver doesn't >> >> >> > have to do any special parsing at all. The top-level node >> >> >> > "interfaces" in "ietf-interfaces" is *always* send as >> >> >> > "ietf-interfaces:interfaces", and its child node "interface" is >> >> >> > *always* sent as "interface" and the node "ipv4" that augments the >> >> >> > interface list is *always* sent as "ietf-ip:ipv4". >> >> >> > >> >> >> > >> >> >> >> >> >> But what if there is an "acme:interface" that augments >> >> >> "ietf-interfaces:interfaces"? >> >> >> Then the child node will not always be "interface". It might be >> >> >> "acme:interface" >> >> >> instead. >> >> > >> >> > No, in that case there are two separate nodes, one always encoded as >> >> > "interface" and one always encoded as "acme:interface", regardless of >> >> > how many other augments there are. >> >> > >> >> >> The server better check, right? >> >> >> >> >> >> Not checking for a module name means the server might assume >> >> >> that "junk:interface" is a valid node and child of ietf-interfaces:interfaces. >> >> >> Seems like the server has to check every node. >> >> > >> >> > No, since with this scheme there is no flexibility, everything is 100% >> >> > predictable and stable. >> >> > >> >> >> >> You really think it's a good idea to assume the data from the sender >> >> is always valid and doesn't need to be checked? >> > >> > That is a completely separate question. We're discussing the best way >> > to encode YANG node names in json. It is up to us to specify this. >> > There is no given answer. With clear and simple rules, chances are >> > higher that implementations are correct. >> > >> >> I don't see how interoperability is increased if the server is >> >> forced to reject input it understands. I doubt customers will >> >> see this as a feature instead of a bug. >> > >> > I think you are missing the point. If the rule is that a top-level >> > node is encoded as :, why would a server >> > "understand" just "interfaces"? Surely a server would also understand >> > - or ? >> > >> > Your code can be as liberal as you program it to be, but the >> > specification needs to be clear and specify what is *valid*. >> > >> >> The pattern is : so why would one >> change the delimiter to a character that is invalid within a YANG >> identifier? Or to whitespace? That doesn't make sense. > > Exactly - the encoding is :, why would anyone > send ? If there is just one node, why would your server > care about the name at all? > > >> Since everything is 100% predictable as you say, the server >> knows that "foo" matches the only node with a a local-name of "foo". >> It seems to violate the Postel Principle to reject this input. > > The Postel Principle says that an implementation should be liberal in > what it accepts, i.e., accept things that do not follow the > specification. We are talking about what the *specification* should > be. If the spec says that two forms are legal, the Postel Principle > doesn't apply to these two forms, since it is not liberal to accept > something that is legal! > > So the standard will specify what the server MUST do if a client deviates from the mandatory encoding? I guess you can write MUST in the standard and I will add yet another config parameter to our server to allow more lax parsing. > /martin Andy From nobody Thu Feb 12 00:37:02 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33ABE1A1B5A for ; Thu, 12 Feb 2015 00:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBen9-q8FHvF for ; Thu, 12 Feb 2015 00:36:56 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B924C1A003B for ; Thu, 12 Feb 2015 00:36:55 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C28821CC0051; Thu, 12 Feb 2015 09:36:54 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , andy@yumaworks.com In-Reply-To: <20150210.221935.1416907161721598337.mbj@tail-f.com> References: <20150210.215550.1438604762585678944.mbj@tail-f.com> <20150210.221935.1416907161721598337.mbj@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 12 Feb 2015 09:36:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 08:36:59 -0000 Martin Bjorklund writes: > Andy Bierman wrote: >> On Tue, Feb 10, 2015 at 12:55 PM, Martin Bjorklund wrote: >> > Andy Bierman wrote: >> >> On Tue, Feb 10, 2015 at 12:29 PM, Martin Bjorklund wrote: >> >> > Andy Bierman wrote: >> >> >> On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund wrote: >> >> >> > Andy Bierman wrote: >> >> >> >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: >> >> >> >> > Hi, >> >> >> >> > >> >> >> >> > I'll try to summarize this long thread. Please comment. >> >> >> >> > >> >> >> >> > Ladislav Lhotka writes: >> >> >> >> > >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> $SUBJ is already several months late, so I think we should proceed >> >> >> >> >> towards delivering it. I checked my mail archive since the -02 revision, >> >> >> >> >> and it seems two issues need to be resolved: >> >> >> >> >> >> >> >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I >> >> >> >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >> >> >> >> >> instead of MUST NOT): >> >> >> >> > >> >> >> >> > It seems Andy is now the only supporter of this change, and I think >> >> >> >> > there are strong technical reasons for keeping namespace rules strict, >> >> >> >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or >> >> >> >> > reformulate the text in the same sense without using 2119 keywords. >> >> >> > >> >> >> > I think it would be wise to rewrite the text to explain how the >> >> >> > different nodes (top-level in module, top-level in remote augment and >> >> >> > other) are encoded. The current 2119 language seems to indicate that >> >> >> > there is some kind of choice involved. >> >> >> > >> >> >> >> >> OLD >> >> >> >> >> >> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> >> >> >> with namespace identifiers MUST NOT be used. >> >> >> >> >> >> >> >> >> >> NEW >> >> >> >> >> >> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >> >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes >> >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names >> >> >> >> >> with namespace identifiers SHOULD NOT be used. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I strongly object to changing the text above back to OLD. >> >> >> >> The debate has been over top-level nodes missing the prefix, >> >> >> >> not nested nodes that redundantly declare the same module >> >> >> >> as the parent node. >> >> >> > >> >> >> > No, the debate has been for all nodes. >> >> >> > >> >> >> >> We already agreed that the receiver has to parse the module name >> >> >> >> every time in case it is different. It has to remember the parent >> >> >> >> module name in case it is missing in the child nodes. >> >> >> > >> >> >> > No, the point is that with deterministic rules, the receiver doesn't >> >> >> > have to do any special parsing at all. The top-level node >> >> >> > "interfaces" in "ietf-interfaces" is *always* send as >> >> >> > "ietf-interfaces:interfaces", and its child node "interface" is >> >> >> > *always* sent as "interface" and the node "ipv4" that augments the >> >> >> > interface list is *always* sent as "ietf-ip:ipv4". >> >> >> > >> >> >> > >> >> >> >> >> >> But what if there is an "acme:interface" that augments >> >> >> "ietf-interfaces:interfaces"? >> >> >> Then the child node will not always be "interface". It might be >> >> >> "acme:interface" >> >> >> instead. >> >> > >> >> > No, in that case there are two separate nodes, one always encoded as >> >> > "interface" and one always encoded as "acme:interface", regardless of >> >> > how many other augments there are. >> >> > >> >> >> The server better check, right? >> >> >> >> >> >> Not checking for a module name means the server might assume >> >> >> that "junk:interface" is a valid node and child of ietf-interfaces:interfaces. >> >> >> Seems like the server has to check every node. >> >> > >> >> > No, since with this scheme there is no flexibility, everything is 100% >> >> > predictable and stable. >> >> > >> >> >> >> You really think it's a good idea to assume the data from the sender >> >> is always valid and doesn't need to be checked? >> > >> > That is a completely separate question. We're discussing the best way >> > to encode YANG node names in json. It is up to us to specify this. >> > There is no given answer. With clear and simple rules, chances are >> > higher that implementations are correct. >> > >> >> I don't see how interoperability is increased if the server is >> >> forced to reject input it understands. I doubt customers will >> >> see this as a feature instead of a bug. >> > >> > I think you are missing the point. If the rule is that a top-level >> > node is encoded as :, why would a server >> > "understand" just "interfaces"? Surely a server would also understand >> > - or ? >> > >> > Your code can be as liberal as you program it to be, but the >> > specification needs to be clear and specify what is *valid*. >> > >> >> The pattern is : so why would one >> change the delimiter to a character that is invalid within a YANG >> identifier? Or to whitespace? That doesn't make sense. > > Exactly - the encoding is :, why would anyone > send ? If there is just one node, why would your server > care about the name at all? > > >> Since everything is 100% predictable as you say, the server >> knows that "foo" matches the only node with a a local-name of "foo". >> It seems to violate the Postel Principle to reject this input. > > The Postel Principle says that an implementation should be liberal in > what it accepts, i.e., accept things that do not follow the > specification. We are talking about what the *specification* should Exactly. RFC 1122 describes the Robustness (Postel) Principle as the ability "to deal with every conceivable error, no matter how unlikely;". It has thus nothing to do with protocol design. Lada > be. If the spec says that two forms are legal, the Postel Principle > doesn't apply to these two forms, since it is not liberal to accept > something that is legal! > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 12 00:47:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF3C1A0117 for ; Thu, 12 Feb 2015 00:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwXobSJwFKS2 for ; Thu, 12 Feb 2015 00:47:28 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE591A003B for ; Thu, 12 Feb 2015 00:47:27 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id EBB071CC0051; Thu, 12 Feb 2015 09:47:27 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Martin Bjorklund In-Reply-To: References: <20150210.215550.1438604762585678944.mbj@tail-f.com> <20150210.221935.1416907161721598337.mbj@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 12 Feb 2015 09:47:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] yang-json document X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 08:47:30 -0000 Andy Bierman writes: > On Tue, Feb 10, 2015 at 1:19 PM, Martin Bjorklund wrote: >> Andy Bierman wrote: >>> On Tue, Feb 10, 2015 at 12:55 PM, Martin Bjorklund wrote: >>> > Andy Bierman wrote: >>> >> On Tue, Feb 10, 2015 at 12:29 PM, Martin Bjorklund wrote: >>> >> > Andy Bierman wrote: >>> >> >> On Tue, Feb 10, 2015 at 11:56 AM, Martin Bjorklund wrote: >>> >> >> > Andy Bierman wrote: >>> >> >> >> On Tue, Feb 10, 2015 at 2:30 AM, Ladislav Lhotka wrote: >>> >> >> >> > Hi, >>> >> >> >> > >>> >> >> >> > I'll try to summarize this long thread. Please comment. >>> >> >> >> > >>> >> >> >> > Ladislav Lhotka writes: >>> >> >> >> > >>> >> >> >> >> Hi, >>> >> >> >> >> >>> >> >> >> >> $SUBJ is already several months late, so I think we should proceed >>> >> >> >> >> towards delivering it. I checked my mail archive since the -02 revision, >>> >> >> >> >> and it seems two issues need to be resolved: >>> >> >> >> >> >>> >> >> >> >> 1. Andy objected to making redundant namespace prefixes illegal. I >>> >> >> >> >> propose the following change to 4th paragraph in sec. 4 (SHOULD NOT >>> >> >> >> >> instead of MUST NOT): >>> >> >> >> > >>> >> >> >> > It seems Andy is now the only supporter of this change, and I think >>> >> >> >> > there are strong technical reasons for keeping namespace rules strict, >>> >> >> >> > stable and deterministic. I am therefore inclined to keep "MUST NOT", or >>> >> >> >> > reformulate the text in the same sense without using 2119 keywords. >>> >> >> > >>> >> >> > I think it would be wise to rewrite the text to explain how the >>> >> >> > different nodes (top-level in module, top-level in remote augment and >>> >> >> > other) are encoded. The current 2119 language seems to indicate that >>> >> >> > there is some kind of choice involved. >>> >> >> > >>> >> >> >> >> OLD >>> >> >> >> >> >>> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >>> >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes >>> >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names >>> >> >> >> >> with namespace identifiers MUST NOT be used. >>> >> >> >> >> >>> >> >> >> >> NEW >>> >> >> >> >> >>> >> >> >> >> Names with namespace identifiers in the form shown in Figure 1 MUST >>> >> >> >> >> be used for all top-level YANG data nodes, and also for all nodes >>> >> >> >> >> whose parent node belongs to a different namespace. Otherwise, names >>> >> >> >> >> with namespace identifiers SHOULD NOT be used. >>> >> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> I strongly object to changing the text above back to OLD. >>> >> >> >> The debate has been over top-level nodes missing the prefix, >>> >> >> >> not nested nodes that redundantly declare the same module >>> >> >> >> as the parent node. >>> >> >> > >>> >> >> > No, the debate has been for all nodes. >>> >> >> > >>> >> >> >> We already agreed that the receiver has to parse the module name >>> >> >> >> every time in case it is different. It has to remember the parent >>> >> >> >> module name in case it is missing in the child nodes. >>> >> >> > >>> >> >> > No, the point is that with deterministic rules, the receiver doesn't >>> >> >> > have to do any special parsing at all. The top-level node >>> >> >> > "interfaces" in "ietf-interfaces" is *always* send as >>> >> >> > "ietf-interfaces:interfaces", and its child node "interface" is >>> >> >> > *always* sent as "interface" and the node "ipv4" that augments the >>> >> >> > interface list is *always* sent as "ietf-ip:ipv4". >>> >> >> > >>> >> >> > >>> >> >> >>> >> >> But what if there is an "acme:interface" that augments >>> >> >> "ietf-interfaces:interfaces"? >>> >> >> Then the child node will not always be "interface". It might be >>> >> >> "acme:interface" >>> >> >> instead. >>> >> > >>> >> > No, in that case there are two separate nodes, one always encoded as >>> >> > "interface" and one always encoded as "acme:interface", regardless of >>> >> > how many other augments there are. >>> >> > >>> >> >> The server better check, right? >>> >> >> >>> >> >> Not checking for a module name means the server might assume >>> >> >> that "junk:interface" is a valid node and child of ietf-interfaces:interfaces. >>> >> >> Seems like the server has to check every node. >>> >> > >>> >> > No, since with this scheme there is no flexibility, everything is 100% >>> >> > predictable and stable. >>> >> > >>> >> >>> >> You really think it's a good idea to assume the data from the sender >>> >> is always valid and doesn't need to be checked? >>> > >>> > That is a completely separate question. We're discussing the best way >>> > to encode YANG node names in json. It is up to us to specify this. >>> > There is no given answer. With clear and simple rules, chances are >>> > higher that implementations are correct. >>> > >>> >> I don't see how interoperability is increased if the server is >>> >> forced to reject input it understands. I doubt customers will >>> >> see this as a feature instead of a bug. >>> > >>> > I think you are missing the point. If the rule is that a top-level >>> > node is encoded as :, why would a server >>> > "understand" just "interfaces"? Surely a server would also understand >>> > - or ? >>> > >>> > Your code can be as liberal as you program it to be, but the >>> > specification needs to be clear and specify what is *valid*. >>> > >>> >>> The pattern is : so why would one >>> change the delimiter to a character that is invalid within a YANG >>> identifier? Or to whitespace? That doesn't make sense. >> >> Exactly - the encoding is :, why would anyone >> send ? If there is just one node, why would your server >> care about the name at all? >> >> >>> Since everything is 100% predictable as you say, the server >>> knows that "foo" matches the only node with a a local-name of "foo". >>> It seems to violate the Postel Principle to reject this input. >> >> The Postel Principle says that an implementation should be liberal in >> what it accepts, i.e., accept things that do not follow the >> specification. We are talking about what the *specification* should >> be. If the spec says that two forms are legal, the Postel Principle >> doesn't apply to these two forms, since it is not liberal to accept >> something that is legal! >> >> > > So the standard will specify what the server MUST do if a client deviates > from the mandatory encoding? If a client deviates from the spec, it is an error. A server implementor can follow Postel Principle and make the software tolerant to that error, but it is an error nonetheless. Along the same lines, server software can tolerate that a client send an uint8 value as "42." (ending with a dot), which is not permitted by RFC 6020. Lada > > I guess you can write MUST in the standard and I will add yet another > config parameter to our server to allow more lax parsing. > > >> /martin > > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 12 11:56:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D7A1A1B14 for ; Thu, 12 Feb 2015 11:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4el_3tXwrNK for ; Thu, 12 Feb 2015 11:56:29 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C701A1BF6 for ; Thu, 12 Feb 2015 11:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1257; q=dns/txt; s=iport; t=1423770989; x=1424980589; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=cVfpHXlXnQXrNCugWE2H1uiVFOZSOmt/WS++7tte9cU=; b=hQsGU1DVoJdcjemPHwXfvWij+hAlIp5B3lnGUMV+ibfdfYb8IEdr3gFh 9vIsknze8TruzU4lwZZz3SULtqifseLajHJEXJGLkq5vdDJPnlVZUqk+0 U77gpIRQsWD+UoPRzIMxhtmGqYz0U5DCbHRrKThTYzocRaG1RiLeegkF4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAOgE3VStJA2D/2dsb2JhbABbgwZSWgTDGgqFJ0oCgSxDAQEBAQEBfIQNAQEDAQEBATc0BhcBCDY3CyUCBAESiCUIDdVXAQEBAQEBAQEBAQEBAQEBAQEBFgSLDIQLEAIBVoQqBY8piTOBGIMGjmIig25vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,566,1418083200"; d="scan'208";a="395675681" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 12 Feb 2015 19:56:28 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1CJuSh9022686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 19:56:28 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.221]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 13:56:28 -0600 From: "Dana Blair (dblair)" To: "Thomas D. Nadeau" , NETMOD Working Group Thread-Topic: [netmod] IPR Poll for draft-ietf-netmod-acl-model-01.txt Thread-Index: AQHQQj8Xd6TPMz/Vn0OZEw6Xv4jhrpztiDuA Date: Thu, 12 Feb 2015 19:56:27 +0000 Message-ID: In-Reply-To: <9307E060-237C-4AF7-B281-92E2B886F0F9@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.24.65] Content-Type: text/plain; charset="us-ascii" Content-ID: <66F5BA584DC05044A643DC6BCB394663@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] IPR Poll for draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 19:56:36 -0000 I am not aware of any IPR that applies to the draft draft-ietf-netmod-acl-model-01.txt Dana On 2/6/15, 1:59 PM, "Thomas D. Nadeau" wrote: > > Netmod WG: > > This mail starts the IPR poll on draft-ietf-netmod-acl-model-01.txt. > > Are you aware of any IPR that applies to draft-ietf-netmod-snmp-cfg-04? >If so, has this IPR been disclosed in compliance with IETF IPR rules (see >RFCs >3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to >this >email explicitly regardless of whether or not you are aware of any >relevant IPR. >*The response needs to be sent to the NETMOD wg mailing list.* The >document >will not advance to the next stage until a response has been received >from *each >author and contributor*. > > If you are on the NETMOD WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that >has not yet been disclosed in conformance with IETF rules. > > Thank you, > > Tom and Juergen, NETMOD WG Chairs >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Feb 12 12:07:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733181A1DBC for ; Thu, 12 Feb 2015 12:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QntFXqi5_27l for ; Thu, 12 Feb 2015 12:07:21 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7871A026E for ; Thu, 12 Feb 2015 12:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4689; q=dns/txt; s=iport; t=1423771641; x=1424981241; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=zsNRMgz90O+alipdght8m2IixhPNL0326bgFwsyKVeI=; b=l27UdF0aCxqFWYGw85I1B95F8/IwexPWHEig727t4BE9BMUMbFySfftH P8AKPLMzIJYnVR4bwIOCdZsrgQhL0MO84veViGdLTGGVSTz0pc4oZP0yl 9XubmMKU3ihcpXuEWzUQgtsoh6S3onst/W/OzpUCg0Xe3V7Gs6UF6fTRn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFABMH3VStJV2T/2dsb2JhbABSBgODBlJaBMMaCoUnSgKBLEMBAQEBAQF8hA0BAQQBAQEaHTQZBAEIDgIIHisMCyUCBAESiC0N1VMBAQEBAQEEAQEBAQEBAQEaBIsIhBJLFxGEGQWPKYc6gXmBGBCCdoJJjBkig25vgQQkHH8BAQE X-IronPort-AV: E=Sophos;i="5.09,566,1418083200"; d="scan'208";a="392554317" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP; 12 Feb 2015 20:07:20 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1CK7KqD018620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Feb 2015 20:07:20 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.221]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 12 Feb 2015 14:07:20 -0600 From: "Dana Blair (dblair)" To: Juergen Schoenwaelder , "Thomas D. Nadeau" , NETMOD Working Group Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt Thread-Index: AQHQQj8ZBQjsPnuiEUeC8pHyZ5d5Rpzkc3gAgAAQSgCACQd/AA== Date: Thu, 12 Feb 2015 20:07:19 +0000 Message-ID: In-Reply-To: <20150206211404.GA2595@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.24.65] Content-Type: text/plain; charset="us-ascii" Content-ID: <17DFEF91F789464D87C5D2C93BF161D6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 20:07:24 -0000 Great comments. The authors are meeting right now and will get back to the list. thanks, Dana On 2/6/15, 4:14 PM, "Juergen Schoenwaelder" wrote: >On Fri, Feb 06, 2015 at 09:15:46PM +0100, Juergen Schoenwaelder wrote: >> On Fri, Feb 06, 2015 at 01:59:30PM -0500, Thomas D. Nadeau wrote: >> >=20 >> > This commences a NETMOD WG Last call for >>draft-ietf-netmod-acl-model-01.txt. Please send comments to the list by >>20-FEB-2015 by 9AM EST. >> > >>=20 >> Before I read this in detail already a few quick comments: >>=20 >> - The module name 'packet-fields' should follow RFC 6020 guidelines. >>=20 >> - Non-normative example modules should be in an appendix marked as >> non-normative. >>=20 >> - The security considerations include a TBD action item. >>=20 >> - If ietf-route-filter.yang is an example, I would probably give it a >> different name that has less chance to be confused with an official >> module. >> > >More comments: > >- Why do you use the prefix 'ietf' for ietf-yang-types? The default > would have been 'yang'. > >- How is the packet-fields module updated? IETF process? Is this a > candidate for IANA maintenance? > >- Do we need a copyright notice in the module descriptions? > >- The description of the revision does not make much sense, and the > reference even less. I suggest to follow the YANG guidelines, > RFC 6087. > >- Is layer 2 always ethernet or is this > > identity eth-acl { > base "acl:acl-base"; > description "layer 2 ACL type"; > } > > just a misnomer? Perhaps the description of ip-acl also should be > "IP layer ACL type" to be precise. But then, the associated grouping > also includes layer 4 elements (port number ranges). > >- Since access-list/acl-type is optional, what is the meaning if it is > not present? > >- I have no clue what to expect in the targets strings in > acl-oper-data/targets. > >- The description of access-list talks about sequence numbers - I > could not find them. Perhaps the text is outdated? > >- I personally would not inline the operational state nodes but this > may be personal preference. > >- Is 'entry' the same as 'rule'? If so, why do we use two terms if one > would be sufficient? > >- I do not understand this: > > The time range is identified by a name > and then referenced by a function, so that those > time restrictions are imposed on the function itself. > > I was surprised to find this since the introductory text never > mentions time filters, it only talks about about packet filters and > metadata filters. Well, this is filtering on the meta data when a > packet is received but perhaps this deserves to be mentioned > somewhere earlier. > >- You will be asked later on anyway to use the reserved example IP > addresses in the examples, so make the changes now. > >- In the example in section 4.4, I suggest to remove all the > edit-config stuff and to show only the config itself. I am also not > sure the example is correct, has this been validated against the > schema? > >- The explanation given at the beginning of section 4.5 belongs into > the data model definition. What happens if I configure only an > upper-port? What if I leave both ports out? What happens if the > lower-port is larger than the upper-port? > >- I generally suggest to use the prefixed defined in an imported > module unless there is a name clash that makes this impossible. If > we always write inet:ipv4-prefix (where possible), it becomes > simpler for human readers to read modules. > >- reference " "; avoids a warning but is otherwise not useful > >- The biggest thing that is unclear to me is how these generic acls > are used in certain contexts. In the operational state, there is a > list of opaque target strings but I do not know what they contain or > how they are configured. So how do I use these generic acls? > Suppose I want to use these acls to control access to my NC > server. How would I have to extend the NC server config model to do > that? > >- The IANA considerations are incomplete since I think you have two > modules that need registration. > >- Since Section 10 is empty, remove it. > >/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 Fri Feb 13 06:17:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A381A8701 for ; Fri, 13 Feb 2015 06:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VAIoxJ63YbH for ; Fri, 13 Feb 2015 06:17:20 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104261A86FA for ; Fri, 13 Feb 2015 06:17:19 -0800 (PST) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.1.87.18; Fri, 13 Feb 2015 14:17:02 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) with mapi id 15.01.0075.002; Fri, 13 Feb 2015 14:17:02 +0000 From: Dean Bogdanovic To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-bogdanovic-netmod-yang-model-classification-00.txt Thread-Index: AQHQR5blvRGLqqY0dkSFmgcZAsez4w== Date: Fri, 13 Feb 2015 14:17:02 +0000 Message-ID: References: <20150213141052.15875.19737.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.12] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-forefront-prvs: 0486A0CB86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(69234005)(377424004)(377454003)(50986999)(92566002)(2900100001)(122556002)(15975445007)(102836002)(40100003)(2420400003)(2656002)(86362001)(87936001)(82746002)(76176999)(19580405001)(83716003)(19580395003)(62966003)(107886001)(450100001)(106116001)(77156002)(2351001)(33656002)(2501002)(230783001)(66066001)(16236675004)(110136001)(99286002)(19617315012)(46102003)(57306001)(14971765001)(50226001)(36756003)(16601075003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_B6978EB492AA461E9C0DE48848FBB696junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2015 14:17:02.4727 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB421 Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-bogdanovic-netmod-yang-model-classification-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 14:17:22 -0000 --_000_B6978EB492AA461E9C0DE48848FBB696junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI Begin forwarded message: From: > Subject: New Version Notification for draft-bogdanovic-netmod-yang-model-cl= assification-00.txt Date: February 13, 2015 9:10:52 AM EST To: Dean Bogdanovic >, Dean Bog= danovic > A new version of I-D, draft-bogdanovic-netmod-yang-model-classification-00.= txt has been successfully submitted by Dean Bogdanovic and posted to the IETF repository. Name: draft-bogdanovic-netmod-yang-model-classification Revision: 00 Title: YANG model classification Document date: 2015-02-13 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod= -yang-model-classification-00.txt Status: https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-ya= ng-model-classification/ Htmlized: http://tools.ietf.org/html/draft-bogdanovic-netmod-yang-mod= el-classification-00 Abstract: More and more groups are using YANG to create network models, from configuration to service models. Currently there is no good overview of how to classify network models in general. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_B6978EB492AA461E9C0DE48848FBB696junipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable FYI

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: Ne= w Version Notification for draft-bogdanovic-netmod-yang-model-classificatio= n-00.txt
Date: Febru= ary 13, 2015 9:10:52 AM EST
To: Dean = Bogdanovic <deanb@juniper.net&g= t;, Dean Bogdanovic <deanb@juniper.= net>


A new version of I-D, draft-bogdanovic-netmod-yang-model-classification-00.= txt
has been successfully submitted by Dean Bogdanovic and posted to the
IETF repository.

Name: draft-bogdanovic= -netmod-yang-model-classification
Revision: 0= 0
Title: YANG model clas= sification
Document date: 2015-02-13
Group: Individual Subm= ission
Pages: 9
URL:            http://www.ietf.org/internet-drafts/draft-bogdano= vic-netmod-yang-model-classification-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-yang-model-class= ification/
Htmlized:       http://tools= .ietf.org/html/draft-bogdanovic-netmod-yang-model-classification-00


Abstract:
  More and more groups are using YANG to create network models, f= rom
  configuration to service models.  Currently there is no go= od overview
  of how to classify network models in general.




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

The IETF Secretariat


--_000_B6978EB492AA461E9C0DE48848FBB696junipernet_-- From nobody Fri Feb 13 10:20:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0F21A0199 for ; Fri, 13 Feb 2015 10:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 3D7OlCJ98_MB for ; Fri, 13 Feb 2015 10:20:37 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121BC1A0161 for ; Fri, 13 Feb 2015 10:20:37 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id hy10so6646802vcb.8 for ; Fri, 13 Feb 2015 10:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DxRCYydBxQsBXZeYgv7Egt/upQpZIgdJfHJEndEC1Go=; b=FlxZBnpVgupK3Qm2gVflRMGmOrwapQK6h0hUfyGeI+f6uOOu+eq2nVndE+Ru5tEQjY PsOjofAWDM+bOask/+9mtUzxZqd8cPf9goxEvsgElJo5Mn4BajqNZunXUB6N4yPnqd/m 4R8crEhFkLU8npkFGAiEB58bRep5Y6IEOFGfnH2GZ0A21+n05BporH6s/NKs71ITZjEJ 1xu9cNR6ZuhuUD/uEVVHmbOdBlCqdRByHG4fuiW2jzPXvYwXaSRGu7c9QejzpfS5GED5 AH6JSAm/DfncuOlR8Dr38SibpBI1H0R/peuOuREtVPOq+EeS1jYkUGcnawm+J0+K2PDA y4sQ== 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 :content-type; bh=DxRCYydBxQsBXZeYgv7Egt/upQpZIgdJfHJEndEC1Go=; b=X3mp5HxBfEoi+LAsVEhar/d9ktpTWe328pHhhuqc64xBn1Ko+9K7vFVS0LISqZhl3l 8o5DdYm6bThB2nqJb0YCrAQGIgswCnJoFxA7almdhnq3CP+zKfWJtm/1yqD+gLQXE8ox 1715RMQ427KOd5kw07CcVSMRaZJ4HY87zb90KJawzqi3HcEv2PvPuLT2Xp7NIlBTM1N3 pzWscudybgm58ZMQ3EKMkHW7JHnCavF+44Sm8yU2ba5DUgGS2jz38Pqqpgx1unzpi5wR 8K+1LJ7/ZDKAU84T9ZFCvA5lJCQhXcuJC81qoPec8DtQM2b9uFUKHDwrf7fNxGs7LfU7 xhKg== X-Gm-Message-State: ALoCoQkVRTnEbX6LcGMAwxy/vdkjxX/zt5vepNu7IU533+8tU9YM9+4NiVrOiyaw38OtFWqm7Mvx MIME-Version: 1.0 X-Received: by 10.220.13.143 with SMTP id c15mr7501975vca.70.1423851636160; Fri, 13 Feb 2015 10:20:36 -0800 (PST) Received: by 10.52.167.71 with HTTP; Fri, 13 Feb 2015 10:20:36 -0800 (PST) Date: Fri, 13 Feb 2015 10:20:36 -0800 Message-ID: From: Paul Borman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11c32972fc997d050efc4a6a Archived-At: Subject: [netmod] Handling of \ in double quoted strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 18:20:38 -0000 --001a11c32972fc997d050efc4a6a Content-Type: text/plain; charset=UTF-8 RFC6020 is very clear about the meaning of \n, \t, \\, and \" in a double quoted string, but it is silent on what the special character \s means. What should the following 6 lines mean? pattern "\s"; pattern "\\s"; pattern "\\\\s"; description "\s"; description "\\s"; description "\\\\s"; I have noticed that normally a single quote is used for patterns, but at times double quotes have been used. It appears that the assertion by this code is that "\s" and "\\s" are the same thing, meaning the regex pattern to match a backslash followed by an s, using double quotes, must be "\\\\s". The file ietf-ipfix-psamp.yang contains backslashed patterns using double quotes assuming the backslash will (sometimes) pass through the scanner rather than be consumed as part of a special character. Thanks, -Paul --001a11c32972fc997d050efc4a6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC6020 is very clear about the meaning of \n, \t, \\, and= \" in a double quoted string, but it is silent on what the special ch= aracter \s means.=C2=A0 What should the following 6 lines mean?

pattern "\s";
pattern "\\s";
pattern "\\\\s"= ;

description "\s";
description<= font face=3D"monospace, monospace">=C2=A0"\\s";
description=C2=A0"\\\\s";

I have noticed that normally a single quote is used for patterns, bu= t at times double quotes have been used.=C2=A0 It appears that the assertio= n by this code is that "\s" and "\\s" are the same thin= g, meaning the regex pattern to match a backslash followed by an s, using d= ouble quotes, must be "\\\\s".

The file=C2=A0= ietf-ipfix-psamp.yang contains backslashed patterns using double quotes ass= uming the backslash will (sometimes) pass through the scanner rather than b= e consumed as part of a special character.

Thanks,=

=C2=A0 =C2=A0 -Paul
--001a11c32972fc997d050efc4a6a-- From nobody Fri Feb 13 10:27:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5FA1A0162 for ; Fri, 13 Feb 2015 10:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e6mq6i-7b6x for ; Fri, 13 Feb 2015 10:27:08 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D7A1A00BD for ; Fri, 13 Feb 2015 10:27:08 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C720E1A91; Fri, 13 Feb 2015 19:27:06 +0100 (CET) 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 Mv04OkPbV4E8; Fri, 13 Feb 2015 19:26:38 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 13 Feb 2015 19:27:05 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6E9A20037; Fri, 13 Feb 2015 19:27:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JtHf0YnxADsc; Fri, 13 Feb 2015 19:27:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B564020036; Fri, 13 Feb 2015 19:27:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AF1073218718; Fri, 13 Feb 2015 19:27:04 +0100 (CET) Date: Fri, 13 Feb 2015 19:27:04 +0100 From: Juergen Schoenwaelder To: Paul Borman Message-ID: <20150213182704.GA50304@elstar.local> Mail-Followup-To: Paul Borman , 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.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Handling of \ in double quoted strings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2015 18:27:11 -0000 Hi, this problem will be addressed in YANG 1.1, see issue Y06 "escaped characters in double quoted strings". New text is already in Section 6.1.3 of draft-ietf-netmod-rfc6020bis-03. /js On Fri, Feb 13, 2015 at 10:20:36AM -0800, Paul Borman wrote: > RFC6020 is very clear about the meaning of \n, \t, \\, and \" in a double > quoted string, but it is silent on what the special character \s means. > What should the following 6 lines mean? > > > pattern "\s"; > pattern "\\s"; > pattern "\\\\s"; > > description "\s"; > description "\\s"; > description "\\\\s"; > > > I have noticed that normally a single quote is used for patterns, but at > times double quotes have been used. It appears that the assertion by this > code is that "\s" and "\\s" are the same thing, meaning the regex pattern > to match a backslash followed by an s, using double quotes, must be "\\\\s". > > The file ietf-ipfix-psamp.yang contains backslashed patterns using double > quotes assuming the backslash will (sometimes) pass through the scanner > rather than be consumed as part of a special character. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 13 12:42:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F22D1A19F4 for ; Fri, 13 Feb 2015 12:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C16aIO-I8xg for ; Fri, 13 Feb 2015 12:41:58 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A4D1A19E9 for ; Fri, 13 Feb 2015 12:41:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 66FCD1A90 for ; Fri, 13 Feb 2015 21:41:56 +0100 (CET) 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 Si4KpPBDE5mT for ; Fri, 13 Feb 2015 21:41:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 13 Feb 2015 21:41:55 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37EDD20038 for ; Fri, 13 Feb 2015 21:41:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V4CecPGhedIT; Fri, 13 Feb 2015 21:41:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F6B020037; Fri, 13 Feb 2015 21:41:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 96D923219CC6; Fri, 13 Feb 2015 21:41:53 +0100 (CET) Date: Fri, 13 Feb 2015 21:41:53 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150213204153.GA53713@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.4.2.3i Archived-At: Subject: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement (2nd try) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2015 20:42:01 -0000 Hi, there has been quite some discussions around Y34 since the first attempt to close the issue (the first VRFY :Y34: thread on this list). I have read the following discussion and through the recent exchanges in the thread "yang-json document" and while new solution proposals have been made, I do not think they actually address the issue or add anything to what has been discussed before. The discussion often seems to be more centered around JSON encoding issues than Y34 itself, perhaps this is also due to the original description of Y34. I think a more accurate description of Y34 is this: The anyxml construct supports any XML, that is, it supports the whole XML infoset, including mixed content, processing instructions, document type declaration, etc. YANG defined data encoded in XML is much more restricted. This has led to a situation where some implementations only support a certain subset of XML for the anyxml construct. The anyxml construct also complicates alternate native encodings such as JSON. Reviewing the discussion on the mailing list and during the virtual interim meetings, I believe there is actually a rather clear path forward, namely the adoption of Y34-05. To improve clarity, I have rewritten Y34-05 (without changing its semantics, but trying to avoid a chain of references to other solution proposals). Here is the new text: ** Solution Y34-05 Same as Y34-02 plus two guidelines adopted from Y34-04: - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This ensures backward compatibility. - Introduce a new 'anydata' statement that represents an unknown chunk of data that can be modeled with YANG. - Document that implementations MAY have restrictions for anyxml and that anyxml is not necessarily interoperable; data model writers should use anydata whenever possible. - The guidelines document should say that YANG Doctors will review each use of anyxml in IETF modules when YANG 1.1 is adopted to avoid its use whenever possible. The rationale is as follows: - The anyxml statement is defined very clearly in RFC 6020 to cover _any_ XML. Proposals to change the semantics of anyxml are not backwards compatible. - There is evidence that there are use cases where a mechanism similar to anyxml is needed that is restricted to the subset of data that can be defined in YANG. - There is evidence that some implementations of anyxml vary in their support of full XML. - It is desirable to _reduce_ encoding specific constructs in YANG, it is undesirable to add additional encoding specific constructs to YANG. Please speak up by Friday 2015-02-20 if you have _strong_ objections against this proposal. Please refrain from repeating arguments that have been brought up before or discussing JSON encoding details (they should be discussed in a different thread as they concern a seperate document). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 13 12:56:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6451A1A2C for ; Fri, 13 Feb 2015 12:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKf8vkSna6ZQ for ; Fri, 13 Feb 2015 12:56:04 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E552B1A1A4B for ; Fri, 13 Feb 2015 12:55:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A7CA81A91 for ; Fri, 13 Feb 2015 21:55:53 +0100 (CET) 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 nNCR7NX04xYZ for ; Fri, 13 Feb 2015 21:55:25 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 13 Feb 2015 21:55:53 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E62E320037 for ; Fri, 13 Feb 2015 21:55:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gUYBA-Wc_m3r; Fri, 13 Feb 2015 21:55:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2ECBC20036; Fri, 13 Feb 2015 21:55:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 08E543219F5C; Fri, 13 Feb 2015 21:55:52 +0100 (CET) Date: Fri, 13 Feb 2015 21:55:51 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150213205551.GA54046@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.4.2.3i Archived-At: Subject: [netmod] VRFY :Y16: module advertisement optimization X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2015 20:56:06 -0000 Hi, the 2014-12-03 virtual interim meeting proposal is to adopt Y16-03. Please speak up by Friday 2015-02-20 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 13 12:59:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58FA1A1A4B for ; Fri, 13 Feb 2015 12:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJhqeIGBbsug for ; Fri, 13 Feb 2015 12:59:25 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A851A1A48 for ; Fri, 13 Feb 2015 12:59:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 15A551A92 for ; Fri, 13 Feb 2015 21:59:24 +0100 (CET) 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 WBKKoARGoFia for ; Fri, 13 Feb 2015 21:58:55 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 13 Feb 2015 21:59:23 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87F4C20037 for ; Fri, 13 Feb 2015 21:59:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hURQgpl_PBL2; Fri, 13 Feb 2015 21:59:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAB3F20036; Fri, 13 Feb 2015 21:59:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C713D321A00D; Fri, 13 Feb 2015 21:59:22 +0100 (CET) Date: Fri, 13 Feb 2015 21:59:22 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150213205922.GB54046@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.4.2.3i Archived-At: Subject: [netmod] VRFY :Y09: introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2015 20:59:26 -0000 Hi, The 2015-01-21 virtual interim meeting proposal is to declare Y09 dead since the goal (optional keys) results in changes that reach beyond the scope of the YANG 1.1 effort. Please speak up by Friday 2015-02-20 if you disagree with this proposal. For more details, see the issues list and the virtual interim meeting minutes available here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 13 13:20:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089B91A1A58 for ; Fri, 13 Feb 2015 13:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHnRpXielIrR for ; Fri, 13 Feb 2015 13:20:37 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C7F1A1A57 for ; Fri, 13 Feb 2015 13:20:37 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EA3E11A92 for ; Fri, 13 Feb 2015 22:20:35 +0100 (CET) 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 r0ADRddKTOgI for ; Fri, 13 Feb 2015 22:20:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 13 Feb 2015 22:20:35 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7AEE20037 for ; Fri, 13 Feb 2015 22:20:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ut5WuGF417NJ; Fri, 13 Feb 2015 22:20:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E34B220036; Fri, 13 Feb 2015 22:20:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E0340321A38B; Fri, 13 Feb 2015 22:20:33 +0100 (CET) Date: Fri, 13 Feb 2015 22:20:33 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150213212033.GA54556@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.4.2.3i Archived-At: Subject: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2015 21:20:39 -0000 Hi, Y25 (make enum numbering purely informative and optional) has been discussed but no clear concensus has been reached so far. Y25-01 proposes to remove the auto-numbering mechanism. With the appearance of a CBOR encoding proposal [1], the numeric values may actually be used on the wire. An alternative is to keep the auto-numbering mechanism but to clarify the risks, this is what I have written up as solution Y25-02: ** Solution Y25-02 Keep the auto-numbering procedure for enums and bits and add an explicit warning that inserting enum definitions or reordering of enum definitions very likely causes interoperability problem and that explicit value assignments avoid this problem. The guidelines document may add further rules such that enum/bits values must be explicitly defined in IETF modules (to be discussed in the context of the guidelines document). [1] https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 13 13:30:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C951A1A52 for ; Fri, 13 Feb 2015 13:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4XhuhDm4LcH for ; Fri, 13 Feb 2015 13:29:55 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BDAD1A1A14 for ; Fri, 13 Feb 2015 13:29:55 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 394231A92; Fri, 13 Feb 2015 22:29:54 +0100 (CET) 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 UrDffON4mV99; Fri, 13 Feb 2015 22:29:25 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 13 Feb 2015 22:29:53 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C29E20037; Fri, 13 Feb 2015 22:29:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Iu1rVCVPdEtY; Fri, 13 Feb 2015 22:21:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1460A20036; Fri, 13 Feb 2015 22:29:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 10F6D321A51F; Fri, 13 Feb 2015 22:29:52 +0100 (CET) Date: Fri, 13 Feb 2015 22:29:52 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150213212951.GA54827@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20141105141403.GE24310@elstar.local> <20141105.155554.113656028962485180.mbj@tail-f.com> <20141113194005.GB62321@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y58: associate an actions with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2015 21:29:58 -0000 On Thu, Nov 13, 2014 at 12:02:07PM -0800, Andy Bierman wrote: > On Thu, Nov 13, 2014 at 11:40 AM, Juergen Schoenwaelder > wrote: > > Andy, > > > > given Martin's clarification, are you find the proposed resolution of > > Y58? > > I do not see any text proposing how to fix NACM. > Adding actions and notifications to the datastore is an architectural hack. > The ARCH (RFC 6244) needs to support it. NACM (RFC 6536) needs > to support it. > > I strongly object to adding this feature to YANG without proper support in > all protocols that use YANG. The feature is nice-to-have, not required > to fix anything broken. But if the fix is half-baked and incomplete across > all impacted standards, then I cannot support it anymore. > The NETCONF chairs meanwhile confirmed that a corresponding NACM update can be done in NETCONF. And update of the informational document RFC 6244 may be nice to do as well but this is not considered strictly necessary since it is not defining a protocol. Thus I believe we have resolved this objection. I will assume this VRFY has passed by Friday 2015-02-20 unless new objections are raised. I notice that several implementations seem to exist and that data model writers and data model implementers found this feature useful. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Feb 13 13:41:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB7A1A1A57 for ; Fri, 13 Feb 2015 13:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyU_vafxnBB8 for ; Fri, 13 Feb 2015 13:41:08 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 3267B1A1A87 for ; Fri, 13 Feb 2015 13:41:08 -0800 (PST) Received: by lamq1 with SMTP id q1so18915189lam.5 for ; Fri, 13 Feb 2015 13:41:06 -0800 (PST) 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:content-type; bh=curpmJvky/TY5tL3MtvSqDP5jifBc7FHUlMkGQ8vqjc=; b=mMfEMaY4H7Sq8QSQDG3tKfoiROvXCGOtxPmRuADt2hAV64Vw3ShbVQOuaq4Nke2v45 3Q7GGNPi8jHb/PDuazE4bDBoa0gxTCJUy2wLTWPSbNK7oZYEdvYm9dQKqi4OxvsZQgTO IF28480kuIAglE8Z6j4e5FXmMI5Em5XtBaPuLwj+zRhVd7k1KpqmQfrfnOlgdepDoiwn vvSTuqaXNCOSqMCZShProtGng7EaGr5y7avxwe1AVkHw1EsWLenWNWwhRqiC4pMpCva4 OCvGwz0z8bgYPGxOMKwAuM1OcF+wFoRQBus7exH8y6jUwQPZFBIrOQoI/ZWgLRxDvo5Y lpTQ== X-Gm-Message-State: ALoCoQmGglXcY8sOO0IhMDMzWKugfjahgVHVw7Sv33pS5gXtbQauyyQXaQF/SB5SMP1IlQllk36c MIME-Version: 1.0 X-Received: by 10.112.139.136 with SMTP id qy8mr8889915lbb.38.1423863666657; Fri, 13 Feb 2015 13:41:06 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 13 Feb 2015 13:41:06 -0800 (PST) In-Reply-To: <20150213212033.GA54556@elstar.local> References: <20150213212033.GA54556@elstar.local> Date: Fri, 13 Feb 2015 13:41:06 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 21:41:11 -0000 On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder wrote: > Hi, > > Y25 (make enum numbering purely informative and optional) has been > discussed but no clear concensus has been reached so far. Y25-01 > proposes to remove the auto-numbering mechanism. With the appearance > of a CBOR encoding proposal [1], the numeric values may actually be > used on the wire. An alternative is to keep the auto-numbering > mechanism but to clarify the risks, this is what I have written up as > solution Y25-02: > > ** Solution Y25-02 > > Keep the auto-numbering procedure for enums and bits and add an > explicit warning that inserting enum definitions or reordering of > enum definitions very likely causes interoperability problem and > that explicit value assignments avoid this problem. > This is not really keeping the current procedure. Currently, the auto-numbering is mandatory, and sec 10. clearly prohibits changing any value or position statement. IMO Y25 should be declared DEAD and the YANG 1.0 behavior not changed at all. You are proposing that Sec. 10 be changed so renumbering is a warning, not a violation of the standard. Andy > The guidelines document may add further rules such that enum/bits > values must be explicitly defined in IETF modules (to be discussed > in the context of the guidelines document). > > [1] https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ > > -- > 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 Fri Feb 13 13:48:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255BD1A1A57 for ; Fri, 13 Feb 2015 13:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdgRpPjBZ8r3 for ; Fri, 13 Feb 2015 13:48:04 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 0C95D1A1B1D for ; Fri, 13 Feb 2015 13:47:55 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id w7so17993098lbi.10 for ; Fri, 13 Feb 2015 13:47:53 -0800 (PST) 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:content-type; bh=/uNkrS4ds1tspTN3CkjzhBGm4nxkdewBz4PJ8Hqedlg=; b=VfnvCl6Q4p0TD8rBovXFSlXEnES2clZ9FWjhUj0BxZCJjxTLSt7WdT/E9hWM9o8SnN Q4oc35FUsG0dIa7Ut8Z0Qq3w//XDmfmjLUeDxDRGxic60dlciCeljA1NHTcDAMlenVqm 78y53ceTeJOxAJNSLXmJXOhdjIZqNPqWVrMGechYCNEXHhsxyaRBTbAlnYSg77/djQ3T 9+WkrAPUOLCYJ5bHiSqK+YyI4FfIXx5JaqlZL6l5v5Eig1lmhYghddfHHv3egiOpgnES 2meB1yrRKJ9vFCdYPLFhrhEF55drEtEOQ4LEFsLjRDoneub1AU2oU+5TFxD2LiKFHleh QT1A== X-Gm-Message-State: ALoCoQkduNHfXGPiRPH7wBRBOkMtoYSJctbcNnTmjNv9cqoof8NdDVx2aNOrNU29LRzQSIqzC+b3 MIME-Version: 1.0 X-Received: by 10.112.142.168 with SMTP id rx8mr10108142lbb.37.1423864073449; Fri, 13 Feb 2015 13:47:53 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 13 Feb 2015 13:47:53 -0800 (PST) In-Reply-To: <20150213212951.GA54827@elstar.local> References: <20141105141403.GE24310@elstar.local> <20141105.155554.113656028962485180.mbj@tail-f.com> <20141113194005.GB62321@elstar.local> <20150213212951.GA54827@elstar.local> Date: Fri, 13 Feb 2015 13:47:53 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :Y58: associate an actions with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 21:48:06 -0000 On Fri, Feb 13, 2015 at 1:29 PM, Juergen Schoenwaelder wrote: > On Thu, Nov 13, 2014 at 12:02:07PM -0800, Andy Bierman wrote: >> On Thu, Nov 13, 2014 at 11:40 AM, Juergen Schoenwaelder >> wrote: >> > Andy, >> > >> > given Martin's clarification, are you find the proposed resolution of >> > Y58? >> >> I do not see any text proposing how to fix NACM. >> Adding actions and notifications to the datastore is an architectural hack. >> The ARCH (RFC 6244) needs to support it. NACM (RFC 6536) needs >> to support it. >> >> I strongly object to adding this feature to YANG without proper support in >> all protocols that use YANG. The feature is nice-to-have, not required >> to fix anything broken. But if the fix is half-baked and incomplete across >> all impacted standards, then I cannot support it anymore. >> > > The NETCONF chairs meanwhile confirmed that a corresponding NACM > update can be done in NETCONF. And update of the informational > document RFC 6244 may be nice to do as well but this is not considered > strictly necessary since it is not defining a protocol. Thus I believe > we have resolved this objection. > I don't have any objections to adding this new feature. Not all the solution details are worked out, but that's OK. > I will assume this VRFY has passed by Friday 2015-02-20 unless new > objections are raised. I notice that several implementations seem to > exist and that data model writers and data model implementers found > this feature useful. I think Phil strongly objected to this because is is a duplicate of "rpc", and it gives the appearance of OO-design, but YANG 1.1 should not introduce any changes like that. Have these objections been addressed? > > /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 Fri Feb 13 15:11:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBED11A0039 for ; Fri, 13 Feb 2015 15:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8M3AioK5dfj for ; Fri, 13 Feb 2015 15:11:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id F1E2E1A0367 for ; Fri, 13 Feb 2015 15:11:08 -0800 (PST) Received: from pluto.hedeland.org (h194n2-hy-a32.ias.bredband.telia.com [81.228.176.194]) by mail.tail-f.com (Postfix) with ESMTPSA id 8370C12801A5; Sat, 14 Feb 2015 00:11:07 +0100 (CET) Message-ID: <54DE848B.1080701@tail-f.com> Date: Sat, 14 Feb 2015 00:11:07 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andy Bierman , Juergen Schoenwaelder References: <20150213212033.GA54556@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 23:11:14 -0000 On 2015-02-13 22:41, Andy Bierman wrote: > On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder > wrote: >> Hi, >> >> Y25 (make enum numbering purely informative and optional) has been >> discussed but no clear concensus has been reached so far. Y25-01 >> proposes to remove the auto-numbering mechanism. With the appearance >> of a CBOR encoding proposal [1], the numeric values may actually be >> used on the wire. An alternative is to keep the auto-numbering >> mechanism but to clarify the risks, this is what I have written up as >> solution Y25-02: >> >> ** Solution Y25-02 >> >> Keep the auto-numbering procedure for enums and bits and add an >> explicit warning that inserting enum definitions or reordering of >> enum definitions very likely causes interoperability problem and >> that explicit value assignments avoid this problem. >> > > > This is not really keeping the current procedure. > Currently, the auto-numbering is mandatory, and sec 10. > clearly prohibits changing any value or position statement. > > IMO Y25 should be declared DEAD and the YANG 1.0 behavior > not changed at all. +1 > You are proposing that Sec. 10 be changed so renumbering is > a warning, not a violation of the standard. Yes - and this is IMO clearly a non-backwards compatible change. The "backwards compatible" requirement is extremely loosely specified by the charter, i.e. "All compliant YANG 1.0 modules must be accepted as compliant YANG 1.1 modules" - which if taken literally would allow for anything that completely changes the semantics of a 1.0 module, as long as it is still "accepted as compliant" in 1.1. This is clearly not what anyone expects - the semantics should be unchanged, at least as long as the 1.0 semantics are not clearly broken / unimplementable etc. RFC 6020 makes the promise to implementations that enum values are stable as long as section 10 is adhered to. The suggested change breaks this promise, thus it should be considered non-backwards compatible. The motivations for making any change at all are also very dubious: 1. "This rule makes updates of enumerations difficult" Disregarding that "difficult" is a very subjective judgement, what exactly is difficult about it? The only example that I have seen on the mailing list is the infamous time zone case. This case revealed several problems: a) The specification of the auto numbering procedure was unclear. This has been addressed by errata 3871. b) No-one wanted to assume the responsibility of maintaining a standard module specifying the enums, probably in no small part due to c) The maintainers of the time zone data were clearly opposed to having any part of it turned into any kind of standard, due to the (additional) political controversy this could lead to. However no technical or practical difficulty in maintaining a module for these enums that adheres to section 10 has been demonstrated. In fact assuming the obvious, that such a module would be auto-generated from some free-form data, whether the raw timezone data or a simple list (without any requirement on ordering) of identifiers, it is a very trivial problem to solve. Martin already offered to provide a piece of software to do that, I can do the same, but of course this particular case is now moot. In the more typical case of a handful of manually assigned enums, maintaining the numbering can't reasonably be considered difficult. 2. "and/or forces the data modeller to assign the values explicitly even if they have no meaning otherwise." The only case where a data modeller would be *forced* to assign values is that of removing an enum other than the "last" one, without adding another to take its place. As far as I can see, removing enums is already ruled out by section 10, and not a candidate for change. But obviously there are cases where some specific order of the enums is more "natural" than others, and adhering to that order is likely to improve readability, which is an important goal. Even in such a case there is no need to assign values in the original version of the module, but it may be needed on update if it is desired to add an enum "in the middle" - but this is not being *forced*. (And readability can only be an actual concern if the total set of enums is small, and then again it can't reasonably be considered difficult to maintain the values.) 3. "The rule also contradicts the statement in Sec. 9.6.4.2 because the value in fact is used by YANG." I disagree, the statement in 9.6.4.2 is accurate - the values aren't *used* by YANG. YANG mereley puts some restrictions on them and provides them to implementations. But if someone really feels strongly about this, the obvious fix is to the text as s/YANG and// - not changing the semantics. --Per Hedeland > Andy > >> The guidelines document may add further rules such that enum/bits >> values must be explicitly defined in IETF modules (to be discussed >> in the context of the guidelines document). >> >> [1] https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Sat Feb 14 01:08:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264FE1A1B3F for ; Sat, 14 Feb 2015 01:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3TxRo9-pXxZ for ; Sat, 14 Feb 2015 01:07:58 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210F41A1B38 for ; Sat, 14 Feb 2015 01:07:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5E5B319E4; Sat, 14 Feb 2015 10:07:56 +0100 (CET) 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 MgsyQGGg8CfL; Sat, 14 Feb 2015 10:07:24 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 14 Feb 2015 10:07:55 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACD3E20037; Sat, 14 Feb 2015 10:07:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t8beizryIJEz; Sat, 14 Feb 2015 10:07:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19BDA20036; Sat, 14 Feb 2015 10:07:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B080C3220B4F; Sat, 14 Feb 2015 10:07:53 +0100 (CET) Date: Sat, 14 Feb 2015 10:07:53 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150214090753.GA70455@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: <20150213212033.GA54556@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2015 09:08:02 -0000 On Fri, Feb 13, 2015 at 01:41:06PM -0800, Andy Bierman wrote: > On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder > wrote: > > Hi, > > > > Y25 (make enum numbering purely informative and optional) has been > > discussed but no clear concensus has been reached so far. Y25-01 > > proposes to remove the auto-numbering mechanism. With the appearance > > of a CBOR encoding proposal [1], the numeric values may actually be > > used on the wire. An alternative is to keep the auto-numbering > > mechanism but to clarify the risks, this is what I have written up as > > solution Y25-02: > > > > ** Solution Y25-02 > > > > Keep the auto-numbering procedure for enums and bits and add an > > explicit warning that inserting enum definitions or reordering of > > enum definitions very likely causes interoperability problem and > > that explicit value assignments avoid this problem. > > This is not really keeping the current procedure. > Currently, the auto-numbering is mandatory, and sec 10. > clearly prohibits changing any value or position statement. > > IMO Y25 should be declared DEAD and the YANG 1.0 behavior > not changed at all. > > You are proposing that Sec. 10 be changed so renumbering is > a warning, not a violation of the standard. > Have you read the text? I fail to see how the text implies that existing behaviour changes. It is about adding an explicit warning. Please explain. /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 Feb 14 01:25:22 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAB01A1B5E for ; Sat, 14 Feb 2015 01:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4pp5KQ8NYsk for ; Sat, 14 Feb 2015 01:25:18 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B89C1A1B47 for ; Sat, 14 Feb 2015 01:25:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F28781A26; Sat, 14 Feb 2015 10:25:16 +0100 (CET) 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 NoqPWoyaKYiv; Sat, 14 Feb 2015 10:24:45 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 14 Feb 2015 10:25:16 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AA4420036; Sat, 14 Feb 2015 10:25:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1pVc4yb55eZ1; Sat, 14 Feb 2015 10:25:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F03D620037; Sat, 14 Feb 2015 10:25:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EE3053220E1A; Sat, 14 Feb 2015 10:25:14 +0100 (CET) Date: Sat, 14 Feb 2015 10:25:14 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150214092514.GB70455@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" References: <20141105141403.GE24310@elstar.local> <20141105.155554.113656028962485180.mbj@tail-f.com> <20141113194005.GB62321@elstar.local> <20150213212951.GA54827@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y58: associate an actions with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2015 09:25:21 -0000 On Fri, Feb 13, 2015 at 01:47:53PM -0800, Andy Bierman wrote: > > I think Phil strongly objected to this because is is a duplicate of "rpc", > and it gives the appearance of OO-design, but YANG 1.1 should not > introduce any changes like that. > > Have these objections been addressed? > There was a strong objection from you because NACM requires an update to handle this and I have tried to resolve that. Phil has expressed that he things actions are not needed but he did not phrase it as a strong objection - at least I did not read it as such. There are implementations of actions that are being actively used and deployed. I do not think an argument that associating actions (or RPCs) with resources may eventually lead to OO and OO is evil is a strong argument. It seems that implementations actually benefit from this and deployments benefit from simpler access control mechanisms since it is possible to express that all actions associated with a certain resource have certain permissions. We have to find concensus and concensus can be rough. Concensus does not require that everybody will be happy - the concensus process is about making sure the technical arguments have been heard, understood and taken into account while trying to find a resolution. /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 Feb 14 03:57:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143691A1BF1 for ; Sat, 14 Feb 2015 03:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzs6ubSMm9uK for ; Sat, 14 Feb 2015 03:57:33 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC021A1BE7 for ; Sat, 14 Feb 2015 03:57:33 -0800 (PST) Received: from pluto.hedeland.org (h194n2-hy-a32.ias.bredband.telia.com [81.228.176.194]) by mail.tail-f.com (Postfix) with ESMTPSA id BD7AA1280044 for ; Sat, 14 Feb 2015 12:57:30 +0100 (CET) Message-ID: <54DF382A.2030508@tail-f.com> Date: Sat, 14 Feb 2015 12:57:30 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5 MIME-Version: 1.0 To: "netmod@ietf.org" References: <20150213212033.GA54556@elstar.local> <20150214090753.GA70455@elstar.local> In-Reply-To: <20150214090753.GA70455@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 11:57:36 -0000 On 2015-02-14 10:07, Juergen Schoenwaelder wrote: > On Fri, Feb 13, 2015 at 01:41:06PM -0800, Andy Bierman wrote: >> On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder >> wrote: >>> Hi, >>> >>> Y25 (make enum numbering purely informative and optional) has been >>> discussed but no clear concensus has been reached so far. Y25-01 >>> proposes to remove the auto-numbering mechanism. With the appearance >>> of a CBOR encoding proposal [1], the numeric values may actually be >>> used on the wire. An alternative is to keep the auto-numbering >>> mechanism but to clarify the risks, this is what I have written up as >>> solution Y25-02: >>> >>> ** Solution Y25-02 >>> >>> Keep the auto-numbering procedure for enums and bits and add an >>> explicit warning that inserting enum definitions or reordering of >>> enum definitions very likely causes interoperability problem and >>> that explicit value assignments avoid this problem. >> >> This is not really keeping the current procedure. >> Currently, the auto-numbering is mandatory, and sec 10. >> clearly prohibits changing any value or position statement. >> >> IMO Y25 should be declared DEAD and the YANG 1.0 behavior >> not changed at all. >> >> You are proposing that Sec. 10 be changed so renumbering is >> a warning, not a violation of the standard. >> > > Have you read the text? I fail to see how the text implies that > existing behaviour changes. It is about adding an explicit warning. > Please explain. Since I came to the exact same conclusion as Andy (after reading the text, but before reading Andy's message), I'll explain why I did that. 1. The proposal doesn't actually solve any of the alleged problems in Y25 unless the rule in section 10 is removed. 2. The proposal explicitly mentions keeping the auto-numbering scheme, but has no mention of the rule in section 10. 3. Adding a vague warning against something that is explicitly forbidden by another part of the spec doesn't make any sense IMHO, and is likely to result in confusion and risk for the rule to be overlooked. Thus for me, the only reasonable conclusion was that you were (implicitly) proposing that the rule in section 10 should be removed. If this is not the case, i.e. you are proposing that both the auto-numbering and the section 10 rule should be retained, but that warning(s) should be added, I would suggest this text: Keep the auto-numbering procedures and the restrictions in section 10 for enum values and bit positions, but add - followed by one or both of: a) a warning that inserting or reordering enum or bit definitions will cause a violation of the rules in section 10, unless explicit value/position assignments are used b) a motivation (in section 10) of the rules in section 10, saying that changes to the values/positions may cause interoperability problems (perhaps also: and lose or at least significantly reduce the "convenience to implementors", since the values cannot be assumed to be stable) Item a) would be quite useful IMO - actually I believe that this came as a surprise to some of the participants in the "time zone discussion", and the fact that it did so was a major cause of the perception of "difficulty". There's nothing wrong with b), but none of the other "itemized" rules have any motivating text. This sounds like a separate issue, "Add motivation to all the rules in section 10" (I don't personally think it is important to do so though). --Per From nobody Sat Feb 14 09:48:39 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6781A0019 for ; Sat, 14 Feb 2015 09:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdr7hKGadtXm for ; Sat, 14 Feb 2015 09:48:35 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 84DDF1A000D for ; Sat, 14 Feb 2015 09:48:35 -0800 (PST) Received: by labpv20 with SMTP id pv20so21655804lab.8 for ; Sat, 14 Feb 2015 09:48:34 -0800 (PST) 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:content-type; bh=vxGokLgpWjllL4m4c7agtinhroa6nWq02uHl7aDYgb8=; b=RcQWUT9dFWZInhLnjGICo8yUv+b4IlkJdy9BW48bx2CpsKym7Hj5i6AargFoA6UQED TBNsnDV04ix3HgLoo66OuOWHnHYJRApwe/FrYa/1d4Fw+JBumd51GVhLdPrcaFW9NO6z ZACt87jy8qpngBSSc4GoDLlLmZzr8kpSktyJ+i5fTFn9qVBMysT16sutNddDg0MPJ5UO DUZ6xYEuJOkM3fopk2C/s+ZGxQYsES2LA8zscNoTPGPxDUUSXoz1fNB32qIyaHg3bxUv Ww4fqfXC2R9Lg01jf2PH7xvLUuTL7DhuqwjunkhC70QUJgwJkCVut0IL0K+s3H3daMv5 Bi0w== X-Gm-Message-State: ALoCoQmnyOUNdIabD/uNJ5s8ujE9PuZAZJ1ajJfJbzIItdQ0jb9eCMJ1RQMlv9g4q0MAnwKIVaft MIME-Version: 1.0 X-Received: by 10.152.37.138 with SMTP id y10mr13849640laj.88.1423936114058; Sat, 14 Feb 2015 09:48:34 -0800 (PST) Received: by 10.112.78.3 with HTTP; Sat, 14 Feb 2015 09:48:33 -0800 (PST) In-Reply-To: <20150214092514.GB70455@elstar.local> References: <20141105141403.GE24310@elstar.local> <20141105.155554.113656028962485180.mbj@tail-f.com> <20141113194005.GB62321@elstar.local> <20150213212951.GA54827@elstar.local> <20150214092514.GB70455@elstar.local> Date: Sat, 14 Feb 2015 09:48:33 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :Y58: associate an actions with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 17:48:38 -0000 On Sat, Feb 14, 2015 at 1:25 AM, Juergen Schoenwaelder wrote: > On Fri, Feb 13, 2015 at 01:47:53PM -0800, Andy Bierman wrote: >> >> I think Phil strongly objected to this because is is a duplicate of "rpc", >> and it gives the appearance of OO-design, but YANG 1.1 should not >> introduce any changes like that. >> >> Have these objections been addressed? >> > > There was a strong objection from you because NACM requires an update > to handle this and I have tried to resolve that. > My objection was to any attempt at an incomplete solution. Once NACM is open for edits, we need to make sure it doesn't need any other edits for I2RS or anything else. IMO the I2RS "owner-based" access control is not RIB-specific at all. I hope we don't develop a different toolset for every subtree in the server. Nice features like "delete all for owner X" are not RIB-specific either. That doesn't mean I think NACM or I2RS should boil the ocean. Just be mindful of general purpose features that are only protocol-specific because the WG charter says so. > Phil has expressed that he things actions are not needed but he did > not phrase it as a strong objection - at least I did not read it as > such. There are implementations of actions that are being actively > used and deployed. I do not think an argument that associating actions > (or RPCs) with resources may eventually lead to OO and OO is evil is a > strong argument. It seems that implementations actually benefit from > this and deployments benefit from simpler access control mechanisms > since it is possible to express that all actions associated with a > certain resource have certain permissions. > > We have to find concensus and concensus can be rough. Concensus does > not require that everybody will be happy - the concensus process is > about making sure the technical arguments have been heard, understood > and taken into account while trying to find a resolution. > I hope the YANG spec is clear about when to use rpc-stmt vs. action-stmt. I agree with Phil that the functionality between the 2 are quite similar. The name "action" implies that I cannot use it for retrieval or altering the configuration, but this is not the case. There is significant potential for misuse like "edit" (with a different behavior and set of inputs for each occurrence). > /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 Mon Feb 16 09:42:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975B01A6ED9 for ; Mon, 16 Feb 2015 09:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, SPF_HELO_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzVl-DTOj83f for ; Mon, 16 Feb 2015 09:42:09 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A0F1A3B9C for ; Mon, 16 Feb 2015 09:42:09 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.1.87.18; Mon, 16 Feb 2015 17:41:52 +0000 Message-ID: <04c701d04a0f$99f85ce0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Thomas D. Nadeau" Date: Mon, 16 Feb 2015 17:40:00 +0000 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.167.59] X-ClientProxiedBy: DB4PR02CA0049.eurprd02.prod.outlook.com (10.242.174.177) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMXPR07MB054; X-Forefront-PRVS: 0489CFBAC9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(279900001)(51704005)(43784003)(13464003)(377454003)(24454002)(61296003)(40100003)(44736004)(92566002)(46102003)(23756003)(86362001)(77096005)(84392001)(33646002)(87976001)(62236002)(19580395003)(47776003)(81686999)(42186005)(19580405001)(116806002)(77156002)(62966003)(19625305001)(15188555004)(122386002)(15975445007)(44716002)(50986999)(50226001)(50466002)(66066001)(14496001)(74416001)(7059030)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB054; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB054; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2015 17:41:52.6837 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB054 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] minutes for Nov 13 meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 17:42:13 -0000 Did these ever get turned into minutes? I cannot find anything on http://www.ietf.org/proceedings/91/netmod.html (and following the link below generates an error:-(. Tom Petch ----- Original Message ----- From: "Thomas D. Nadeau >" To: "Kent Watsen >" Cc: "NETMOD Working Group >" Sent: Tuesday, November 18, 2014 2:17 PM Subject: Re: [netmod] minutes for Nov 13 meeting > Thanks again for taking "notes" 8) > > On Nov 14, 2014:6:11 PM, at 6:11 PM, Kent Watsen > wrote: > > Etherpad minutes updated with notes from today's meeting Cheers, Kent > Date: Thursday, November 13, 2014 at 7:20 PM > Subject: [netmod] minutes for Nov 13 meeting > > Cheers, Kent From nobody Mon Feb 16 13:21:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123771A8025 for ; Mon, 16 Feb 2015 13:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZKOj0nDdYSA for ; Mon, 16 Feb 2015 13:21:41 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216131A88C0 for ; Mon, 16 Feb 2015 13:21:41 -0800 (PST) Received: from BY2PR05CA047.namprd05.prod.outlook.com (10.141.250.37) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.1.81.19; Mon, 16 Feb 2015 21:20:37 +0000 Received: from BL2FFO11FD040.protection.gbl (2a01:111:f400:7c09::104) by BY2PR05CA047.outlook.office365.com (2a01:111:e400:2c5f::37) with Microsoft SMTP Server (TLS) id 15.1.87.18 via Frontend Transport; Mon, 16 Feb 2015 21:20:36 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD040.mail.protection.outlook.com (10.173.161.136) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Mon, 16 Feb 2015 21:20:35 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 16 Feb 2015 13:20:35 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1GLKWW22949; Mon, 16 Feb 2015 13:20:33 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t1GLKIre050227; Mon, 16 Feb 2015 16:20:18 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502162120.t1GLKIre050227@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20150211.203320.92241038305058998.mbj@tail-f.com> Date: Mon, 16 Feb 2015 16:20:18 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(77096005)(47776003)(76506005)(2950100001)(77156002)(46102003)(92566002)(105596002)(86362001)(62966003)(106466001)(54356999)(48376002)(87936001)(53416004)(50466002)(110136001)(50986999)(6806004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB434; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB434; X-Forefront-PRVS: 0489CFBAC9 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2015 21:20:35.4313 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB434 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 21:21:43 -0000 Martin Bjorklund writes: >It is quite a lot. But my idea is to try to move the NETCONF text to >a separate document, but I don't want to do that until all other >issues are resolved. It will be a big diff... if it is possible at >all. I think we need to keep the examples though. How would examples work without encoding rules? IMHO they should stay together. Having the rules with the concepts makes the document hang together and makes YANG more concrete to the reader. Thanks, Phil From nobody Mon Feb 16 13:28:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13A21A88D0 for ; Mon, 16 Feb 2015 13:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxfMD0DA9rsQ for ; Mon, 16 Feb 2015 13:28:33 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8204B1A88C7 for ; Mon, 16 Feb 2015 13:28:11 -0800 (PST) Received: from BLUPR05CA0053.namprd05.prod.outlook.com (10.141.20.23) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.1.81.19; Mon, 16 Feb 2015 21:22:17 +0000 Received: from BL2FFO11FD011.protection.gbl (2a01:111:f400:7c09::149) by BLUPR05CA0053.outlook.office365.com (2a01:111:e400:855::23) with Microsoft SMTP Server (TLS) id 15.1.87.18 via Frontend Transport; Mon, 16 Feb 2015 21:22:17 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Mon, 16 Feb 2015 21:22:17 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 16 Feb 2015 13:21:46 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1GLLjW23555; Mon, 16 Feb 2015 13:21:45 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t1GLLU4I050245; Mon, 16 Feb 2015 16:21:30 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502162121.t1GLLU4I050245@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20150211.212932.1809512817443078851.mbj@tail-f.com> Date: Mon, 16 Feb 2015 16:21:30 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(77096005)(47776003)(76506005)(2950100001)(77156002)(46102003)(92566002)(105596002)(86362001)(62966003)(106466001)(54356999)(48376002)(87936001)(53416004)(50466002)(110136001)(50986999)(6806004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB434; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB434; X-Forefront-PRVS: 0489CFBAC9 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB434; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2015 21:22:17.3927 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB434 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 21:28:36 -0000 Martin Bjorklund writes: >The goal is NOT to make YANG protocol agnostic; we know that will >never work. The goal is to separate the protocol-specific parts from >the language-definition parts. As has been shown with RESTCONF and >JSON, YANG can be used by other protocols than NETCONF and other >encodings than XML - if the protocol is designed for YANG models. >(There are also proprietary protocols and encodings). We can allow reuse without inflicting separation on the base spec. Thanks, Phil From nobody Mon Feb 16 13:41:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C10F1A1BD4 for ; Mon, 16 Feb 2015 13:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnqTKrTpQlbx for ; Mon, 16 Feb 2015 13:40:54 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B52A1A004A for ; Mon, 16 Feb 2015 13:40:54 -0800 (PST) Received: from CO2PR05CA023.namprd05.prod.outlook.com (10.141.241.151) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.87.18; Mon, 16 Feb 2015 21:40:52 +0000 Received: from BN1AFFO11FD020.protection.gbl (2a01:111:f400:7c10::143) by CO2PR05CA023.outlook.office365.com (2a01:111:e400:1429::23) with Microsoft SMTP Server (TLS) id 15.1.87.18 via Frontend Transport; Mon, 16 Feb 2015 21:40:51 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1AFFO11FD020.mail.protection.outlook.com (10.58.52.80) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Mon, 16 Feb 2015 21:40:50 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 16 Feb 2015 13:40:48 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1GLelW33682; Mon, 16 Feb 2015 13:40:47 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t1GLeW1g050451; Mon, 16 Feb 2015 16:40:33 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502162140.t1GLeW1g050451@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20150213204153.GA53713@elstar.local> Date: Mon, 16 Feb 2015 16:40:32 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(46102003)(50986999)(53416004)(77096005)(77156002)(87936001)(6806004)(54356999)(2950100001)(76506005)(62966003)(92566002)(50466002)(86362001)(110136001)(106466001)(47776003)(48376002)(105596002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB435; X-Forefront-PRVS: 0489CFBAC9 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2015 21:40:50.9616 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB435 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement (2nd try) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 21:40:57 -0000 Juergen Schoenwaelder writes: > - Introduce a new 'anydata' statement that represents an unknown > chunk of data that can be modeled with YANG. I'd be opposed to introducing anydata. It's a bit too much like introducing a hole into the model. Sure, the server assumably knows what's there, but it's still a new feature. The current charter says: - YANG 1.1 is not adding fundamentally new data modeling concepts to the language. Thanks, Phil From nobody Mon Feb 16 16:09:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E8C1A8906 for ; Mon, 16 Feb 2015 16:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_Cke59pk0JG for ; Mon, 16 Feb 2015 16:09:01 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 3C17B1A036F for ; Mon, 16 Feb 2015 16:09:01 -0800 (PST) Received: by labgm9 with SMTP id gm9so32855533lab.2 for ; Mon, 16 Feb 2015 16:08:59 -0800 (PST) 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:content-type; bh=4Zigi7d6owdtUK4eV6pKNn+X4bte4v+7aHYngl4+69c=; b=l/fGx9BXoERBLMICaVFzfM1i4b0G0y08WGmyj8ggDDiqIuV1oa/Gk4G/72xJ9aChvm TdmpNSR8fe0ie9Ls6i41oM/5Nc4fZ2w7PlanGlnO17beedVLpMy+sSBWw2Tl9bhCqMaB H7GjrN/LkiNC2MtVF1oeOu94enXfsL3w4eSxlBOdgsZoUGKrTvZ91kZsmN7R+3+iJIoo fzvcaK0E2x7zRB2uAahVR+0us2jYo0PytSAc5kYzrgHkiyIO6da9ulaVlHdAVL8LlujK xbjvd9bBmBEPh+xTGPfgmcSEtQEfMYCASYMvaCpJ758eLqfPZsMPxTyguGWUOjjM/xQm Se/g== X-Gm-Message-State: ALoCoQntn1eRvvHJEC5J93LJ4d5chzk7Cm2x34tQ2uEUqK6jst5tIWOtjsxxvAizOncn/Z8Vt1Y3 MIME-Version: 1.0 X-Received: by 10.152.87.50 with SMTP id u18mr25905350laz.82.1424131739465; Mon, 16 Feb 2015 16:08:59 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 16 Feb 2015 16:08:59 -0800 (PST) In-Reply-To: <201502162140.t1GLeW1g050451@idle.juniper.net> References: <20150213204153.GA53713@elstar.local> <201502162140.t1GLeW1g050451@idle.juniper.net> Date: Mon, 16 Feb 2015 16:08:59 -0800 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement (2nd try) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 00:09:03 -0000 On Mon, Feb 16, 2015 at 1:40 PM, Phil Shafer wrote: > Juergen Schoenwaelder writes: >> - Introduce a new 'anydata' statement that represents an unknown >> chunk of data that can be modeled with YANG. > > I'd be opposed to introducing anydata. It's a bit too much like > introducing a hole into the model. Sure, the server assumably knows > what's there, but it's still a new feature. The current charter > says: > > - YANG 1.1 is not adding fundamentally new data modeling concepts to the language. > The problem with anydata is that it is a generic attempt to fix all uses of anyxml. Each of the anyxml use-cases in RFCs and I-Ds is really a poor man's substitutionGroup macro (from XSD), or a node acting as the root for top-level YANG data nodes. Using anydata as a free-form hole in the datastore is a bad idea. Introducing anydata seems to require a server to support this, as well as support mixed mode XML (since anyxml is still current, and that seems to be the only difference from anydata). IMO Y34 is in scope because anyxml is not being used as a leaf holding a blob of HTML, as envisioned by the WG when RFC 6020 was written. The solution might make the problem worse, not better. IMO a solution that addresses the 2 actual use-cases for anyxml is needed. > > Thanks, > Phil Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Feb 17 06:27:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB09D1A8957 for ; Tue, 17 Feb 2015 06:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 mKNwvm0m_iaZ for ; Tue, 17 Feb 2015 06:27:36 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 583B71A1B45 for ; Tue, 17 Feb 2015 06:27:36 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 9D1762EB24C1; Tue, 17 Feb 2015 09:27:35 -0500 (EST) From: "Thomas D. Nadeau" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2015 09:27:34 -0500 Message-Id: <1F220953-3AB5-4642-AC0E-4EA11E5C2F0D@lucidvision.com> To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: netmod-chairs@tools.ietf.org Subject: [netmod] Dallas IETF NETMOD Meeting Session Requests X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:27:37 -0000 NETMOD WG: Its about a month to the next IETF meeting, so the co-chairs = wanted to start building=20 the WG agendas for the upcoming IETF92 meetings in Dallas. NETMOD will = be meeting twice in order=20 to accommodate the volume of both Yang 1.1 issues and one for everything = else (i.e.: modeling). The IETF agenda, which is still subject to change, is available = at: https://datatracker.ietf.org/meeting/agenda/ For those wishing to request a slot, please note as Juergen and = I have always=20 required that drafts not be presented cold - they must have been = discussed on the mailing=20 list prior to the meeting, for example. We would like to keep the = meetings for=20 face-to-face and interactive discussions of issues/drafts rather than = presentations per=20 se. If you feel that your draft has met this criteria and you would = like to request=20 an agenda slot, please send email to the chairs indicating the draft = name, speaker name=20 and desired duration sufficient to cover any presentation as well as = Q&A.=20 Thanks, Tom and Juergen From nobody Tue Feb 17 06:57:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5861A89A8 for ; Tue, 17 Feb 2015 06:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIf85Sg8In2b for ; Tue, 17 Feb 2015 06:57:24 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBABB1A8951 for ; Tue, 17 Feb 2015 06:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6841; q=dns/txt; s=iport; t=1424185045; x=1425394645; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=a6h9X4Q5S+dnHO0xZ8LBiiJUWCli0f0oJBe7CWPeI84=; b=aNIJ/mHo6r+u62jW/aLBd1rzHK0Rn50bGJwAJKl7BQjJ/NMwa6zzAvDV zcatxwc8bkcgvJS5+b6Z5MBiT8gA2JffqG63OPIzbdjB/Xa18mcM1lTXK z4vHzSMd98/QyHr5ihrtpwJy1Aiep0jQbKm0PunEt/c8pMxHucxWJ9ee9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BRBQClVeNU/51dJa1SBgODBlJPCwTCPQqFJ0oCgRRDAQEBAQEBfIQMAQEBAwEBAQEaURAJBAEIEAhJDAslAgQBEognCA3QVwEBAQEBAQQBAQEBAQEBARoEiwuEE0sXEYQZBYoMg0CBbIc+gXmBGBCCfYJLhVaGRyKDbm+BBCQcfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208";a="396790826" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 17 Feb 2015 14:57:24 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1HEvMjL028322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 14:57:22 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.221]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 08:57:22 -0600 From: "Dana Blair (dblair)" To: "Dana Blair (dblair)" , Juergen Schoenwaelder , "Thomas D. Nadeau" , NETMOD Working Group Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt Thread-Index: AQHQQj8ZBQjsPnuiEUeC8pHyZ5d5Rpzkc3gAgAAQSgCACQd/AIAHhRIA Date: Tue, 17 Feb 2015 14:57:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.215.181] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7F6F97518977B64EB6BD9F94120D1A53@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:57:26 -0000 We=B9re finalizing updates but have a few clarifying questions and some answers: > >- Since access-list/acl-type is optional, what is the meaning if it is > not present? Not sure what this means. Can you provide more detail on what you are looking for ? >The explanation given at the beginning of section 4.5 belongs into > the data model definition. What happens if I configure only an > upper-port? Not allowed. >What if I leave both ports out? What happens if the Here is the behavior we want: source-port-range is not required. If not present, no port matching. if present, then lower is required. If only lower port is present, then a single port match. If lower and upper is present, then it is a multiple port match. > lower-port is larger than the upper-port? Is there a way in the yang language to enforce upper to be higher than lower ?=20 Otherwise, it will return a run time error. > >- reference " "; avoids a warning but is otherwise not useful We prefer to avoid warnings. >The biggest thing that is unclear to me is how these generic acls > are used in certain contexts. In the operational state, there is a > list of opaque target strings but I do not know what they contain or > how they are configured. So how do I use these generic acls? > Suppose I want to use these acls to control access to my NC > server. How would I have to extend the NC server config model to do > that? Many acls are used for packet filter on interfaces. Should we update the interfaces.yang module to allow applying an acl ? Also could be used in routing-cfg.yang module. Should we update that model too ? >The IANA considerations are incomplete since I think you have two > modules that need registration. packet-fields but what is the other one ? please be specific. - Dana > >- Since Section 10 is empty, remove it. ok. thanks, Dana On 2/12/15, 3:07 PM, "Dana Blair (dblair)" wrote: >Great comments. The authors are meeting right now and will get back to >the list. > >thanks, >Dana > >On 2/6/15, 4:14 PM, "Juergen Schoenwaelder" > wrote: > >>On Fri, Feb 06, 2015 at 09:15:46PM +0100, Juergen Schoenwaelder wrote: >>> On Fri, Feb 06, 2015 at 01:59:30PM -0500, Thomas D. Nadeau wrote: >>> >=20 >>> > This commences a NETMOD WG Last call for >>>draft-ietf-netmod-acl-model-01.txt. Please send comments to the list by >>>20-FEB-2015 by 9AM EST. >>> > >>>=20 >>> Before I read this in detail already a few quick comments: >>>=20 >>> - The module name 'packet-fields' should follow RFC 6020 guidelines. >>>=20 >>> - Non-normative example modules should be in an appendix marked as >>> non-normative. >>>=20 >>> - The security considerations include a TBD action item. >>>=20 >>> - If ietf-route-filter.yang is an example, I would probably give it a >>> different name that has less chance to be confused with an official >>> module. >>> >> >>More comments: >> >>- Why do you use the prefix 'ietf' for ietf-yang-types? The default >> would have been 'yang'. >> >>- How is the packet-fields module updated? IETF process? Is this a >> candidate for IANA maintenance? >> >>- Do we need a copyright notice in the module descriptions? >> >>- The description of the revision does not make much sense, and the >> reference even less. I suggest to follow the YANG guidelines, >> RFC 6087. >> >>- Is layer 2 always ethernet or is this >> >> identity eth-acl { >> base "acl:acl-base"; >> description "layer 2 ACL type"; >> } >> >> just a misnomer? Perhaps the description of ip-acl also should be >> "IP layer ACL type" to be precise. But then, the associated grouping >> also includes layer 4 elements (port number ranges). >> >>- Since access-list/acl-type is optional, what is the meaning if it is >> not present? >> >>- I have no clue what to expect in the targets strings in >> acl-oper-data/targets. >> >>- The description of access-list talks about sequence numbers - I >> could not find them. Perhaps the text is outdated? >> >>- I personally would not inline the operational state nodes but this >> may be personal preference. >> >>- Is 'entry' the same as 'rule'? If so, why do we use two terms if one >> would be sufficient? >> >>- I do not understand this: >> >> The time range is identified by a name >> and then referenced by a function, so that those >> time restrictions are imposed on the function itself. >> >> I was surprised to find this since the introductory text never >> mentions time filters, it only talks about about packet filters and >> metadata filters. Well, this is filtering on the meta data when a >> packet is received but perhaps this deserves to be mentioned >> somewhere earlier. >> >>- You will be asked later on anyway to use the reserved example IP >> addresses in the examples, so make the changes now. >> >>- In the example in section 4.4, I suggest to remove all the >> edit-config stuff and to show only the config itself. I am also not >> sure the example is correct, has this been validated against the >> schema? >> >>- The explanation given at the beginning of section 4.5 belongs into >> the data model definition. What happens if I configure only an >> upper-port? What if I leave both ports out? What happens if the >> lower-port is larger than the upper-port? >> >>- I generally suggest to use the prefixed defined in an imported >> module unless there is a name clash that makes this impossible. If >> we always write inet:ipv4-prefix (where possible), it becomes >> simpler for human readers to read modules. >> >>- reference " "; avoids a warning but is otherwise not useful >> >>- The biggest thing that is unclear to me is how these generic acls >> are used in certain contexts. In the operational state, there is a >> list of opaque target strings but I do not know what they contain or >> how they are configured. So how do I use these generic acls? >> Suppose I want to use these acls to control access to my NC >> server. How would I have to extend the NC server config model to do >> that? >> >>- The IANA considerations are incomplete since I think you have two >> modules that need registration. >> >>- Since Section 10 is empty, remove it. >> >>/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 Tue Feb 17 07:31:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D6B1A89B4 for ; Tue, 17 Feb 2015 07:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snOy39YQCCtQ for ; Tue, 17 Feb 2015 07:31:10 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07CF1A8710 for ; Tue, 17 Feb 2015 07:31:09 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B520CAAB; Tue, 17 Feb 2015 16:31:08 +0100 (CET) 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 hBN7xpJMmcnZ; Tue, 17 Feb 2015 16:31:06 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 17 Feb 2015 16:31:07 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A44552003A; Tue, 17 Feb 2015 16:31:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sWV6AWdN_Ut1; Tue, 17 Feb 2015 16:20:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F24920037; Tue, 17 Feb 2015 16:31:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 749823232018; Tue, 17 Feb 2015 16:31:05 +0100 (CET) Date: Tue, 17 Feb 2015 16:31:05 +0100 From: Juergen Schoenwaelder To: "Dana Blair (dblair)" Message-ID: <20150217153105.GA24550@elstar.local> Mail-Followup-To: "Dana Blair (dblair)" , "Thomas D. Nadeau" , NETMOD Working Group References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2015 15:31:14 -0000 On Tue, Feb 17, 2015 at 02:57:22PM +0000, Dana Blair (dblair) wrote: > We¹re finalizing updates but have a few clarifying questions and some > answers: > > > > >- Since access-list/acl-type is optional, what is the meaning if it is > > not present? > > Not sure what this means. Can you provide more detail on what you are > looking for ? If this leaf is not present, what happens with the rest that depends on the type? Is it useful to have this leaf optional? > >The explanation given at the beginning of section 4.5 belongs into > > the data model definition. What happens if I configure only an > > upper-port? > > Not allowed. > > >What if I leave both ports out? What happens if the > > Here is the behavior we want: > source-port-range is not required. If not present, no port matching. > if present, then lower is required. If only lower port is present, then a > single > port match. If lower and upper is present, then it is a multiple port > match. > > > lower-port is larger than the upper-port? > > Is there a way in the yang language to enforce upper to be higher than > lower ? > > Otherwise, it will return a run time error. > You can use must statements or description clauses. I think a runtime error would be a very bad idea. Invalid config should not be accepted and then lead to runtime errors. > >- reference " "; avoids a warning but is otherwise not useful > > We prefer to avoid warnings. But this is then a useless statement. > >The biggest thing that is unclear to me is how these generic acls > > are used in certain contexts. In the operational state, there is a > > list of opaque target strings but I do not know what they contain or > > how they are configured. So how do I use these generic acls? > > Suppose I want to use these acls to control access to my NC > > server. How would I have to extend the NC server config model to do > > that? > > Many acls are used for packet filter on interfaces. > > Should we update the interfaces.yang module to allow applying an acl ? No, why would you update interfaces.yang? I would have expected an augmentation. > Also could be used in routing-cfg.yang module. Should we update that > model too ? Again, this should be an augmentation. > >The IANA considerations are incomplete since I think you have two > > modules that need registration. > > packet-fields but what is the other one ? please be specific. - Dana > I think this is is at least ietf-acl and packet-fields (which needs to get a better name). /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 Feb 17 08:35:18 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831311A88B8 for ; Tue, 17 Feb 2015 08:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srF2pYHN-uWD for ; Tue, 17 Feb 2015 08:35:15 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C30C1A1EF4 for ; Tue, 17 Feb 2015 08:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4676; q=dns/txt; s=iport; t=1424190915; x=1425400515; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dd2c3ayx2XN+2V4VmZZE18X0gGIUiqyqr4dXUA+KKU0=; b=TP5wq3R6kFqGhK/y/n0CiL5yCiW4qDLRQULovw4NzbwyGUqdvxOjD/B6 MbSqQcUfHPPV2ZL5l2orw6cCnxap3cdQGLoMmfRmG1RDnV/isLZ7uZ76B pMKqh0VocOvTVCksnlugmKQ0b8wQj+Bc6iU5PL92Np5lDsE9cpwZNoynV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B5BQDlbONU/4ENJK1YA4MGUloEgn+/QwqFJ0oCHHlDAQEBAQEBfIQNAQEEAQEBMToLDgICAQgOAggEKAICGQwLJQIEAQ0FiC8NnFCcZAaXcwEBAQEBAQEBAQEBAQEBAQEBAQEBARcEgReJdIQ7GAsQBxGCUYFIBY84iTeBGIMNiCGGRyKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208";a="124336541" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP; 17 Feb 2015 16:35:14 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1HGZEjs000338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Feb 2015 16:35:14 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 10:35:14 -0600 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , "Dana Blair (dblair)" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt Thread-Index: AQHQQj8Z4kDnzQD4V0u6atTEWrDwNJzkc3gAgAAQSgCACVtXgIAHhQ4AgAAJbID//74YAA== Date: Tue, 17 Feb 2015 16:35:13 +0000 Message-ID: References: <20150217153105.GA24550@elstar.local> In-Reply-To: <20150217153105.GA24550@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="euc-kr" Content-ID: <1E78A3293B4B3F4FBCB6580665ED3A1F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 16:35:17 -0000 T25lIGlubGluZSBiZWxvdy4gDQoNCk9uIDIvMTcvMTUsIDEwOjMxIEFNLCAiSnVlcmdlbiBTY2hv ZW53YWVsZGVyIg0KPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6 DQoNCj5PbiBUdWUsIEZlYiAxNywgMjAxNSBhdCAwMjo1NzoyMlBNICswMDAwLCBEYW5hIEJsYWly IChkYmxhaXIpIHdyb3RlOg0KPj4gV2Wp9nJlIGZpbmFsaXppbmcgdXBkYXRlcyBidXQgaGF2ZSBh IGZldyBjbGFyaWZ5aW5nIHF1ZXN0aW9ucyBhbmQgc29tZQ0KPj4gYW5zd2VyczoNCj4+IA0KPj4g Pg0KPj4gPi0gU2luY2UgYWNjZXNzLWxpc3QvYWNsLXR5cGUgaXMgb3B0aW9uYWwsIHdoYXQgaXMg dGhlIG1lYW5pbmcgaWYgaXQgaXMNCj4+ID4gIG5vdCBwcmVzZW50Pw0KPj4gDQo+PiBOb3Qgc3Vy ZSB3aGF0IHRoaXMgbWVhbnMuICBDYW4geW91IHByb3ZpZGUgbW9yZSBkZXRhaWwgb24gd2hhdCB5 b3UgYXJlDQo+PiBsb29raW5nIGZvciA/DQo+DQo+SWYgdGhpcyBsZWFmIGlzIG5vdCBwcmVzZW50 LCB3aGF0IGhhcHBlbnMgd2l0aCB0aGUgcmVzdCB0aGF0IGRlcGVuZHMNCj5vbiB0aGUgdHlwZT8g SXMgaXQgdXNlZnVsIHRvIGhhdmUgdGhpcyBsZWFmIG9wdGlvbmFsPw0KPiANCj4+ID5UaGUgZXhw bGFuYXRpb24gZ2l2ZW4gYXQgdGhlIGJlZ2lubmluZyBvZiBzZWN0aW9uIDQuNSBiZWxvbmdzIGlu dG8NCj4+ID4gIHRoZSBkYXRhIG1vZGVsIGRlZmluaXRpb24uIFdoYXQgaGFwcGVucyBpZiBJIGNv bmZpZ3VyZSBvbmx5IGFuDQo+PiA+ICB1cHBlci1wb3J0Pw0KPj4gDQo+PiBOb3QgYWxsb3dlZC4N Cj4+IA0KPj4gPldoYXQgaWYgSSBsZWF2ZSBib3RoIHBvcnRzIG91dD8gV2hhdCBoYXBwZW5zIGlm IHRoZQ0KPj4gDQo+PiBIZXJlIGlzIHRoZSBiZWhhdmlvciB3ZSB3YW50Og0KPj4gc291cmNlLXBv cnQtcmFuZ2UgaXMgbm90IHJlcXVpcmVkLiAgSWYgbm90IHByZXNlbnQsIG5vIHBvcnQgbWF0Y2hp bmcuDQo+PiBpZiBwcmVzZW50LCB0aGVuIGxvd2VyIGlzIHJlcXVpcmVkLiAgSWYgb25seSBsb3dl ciBwb3J0IGlzIHByZXNlbnQsDQo+PnRoZW4gYQ0KPj4gc2luZ2xlDQo+PiBwb3J0IG1hdGNoLiAg SWYgbG93ZXIgYW5kIHVwcGVyIGlzIHByZXNlbnQsIHRoZW4gaXQgaXMgYSBtdWx0aXBsZSBwb3J0 DQo+PiBtYXRjaC4NCj4+IA0KPj4gPiAgbG93ZXItcG9ydCBpcyBsYXJnZXIgdGhhbiB0aGUgdXBw ZXItcG9ydD8NCj4+IA0KPj4gSXMgdGhlcmUgYSB3YXkgaW4gdGhlIHlhbmcgbGFuZ3VhZ2UgdG8g ZW5mb3JjZSB1cHBlciB0byBiZSBoaWdoZXIgdGhhbg0KPj4gbG93ZXIgPyANCj4+IA0KPj4gT3Ro ZXJ3aXNlLCBpdCB3aWxsIHJldHVybiBhIHJ1biB0aW1lIGVycm9yLg0KPj4NCj4NCj5Zb3UgY2Fu IHVzZSBtdXN0IHN0YXRlbWVudHMgb3IgZGVzY3JpcHRpb24gY2xhdXNlcy4gSSB0aGluayBhIHJ1 bnRpbWUNCj5lcnJvciB3b3VsZCBiZSBhIHZlcnkgYmFkIGlkZWEuIEludmFsaWQgY29uZmlnIHNo b3VsZCBub3QgYmUgYWNjZXB0ZWQNCj5hbmQgdGhlbiBsZWFkIHRvIHJ1bnRpbWUgZXJyb3JzLg0K Pg0KPj4gPi0gcmVmZXJlbmNlICIgIjsgYXZvaWRzIGEgd2FybmluZyBidXQgaXMgb3RoZXJ3aXNl IG5vdCB1c2VmdWwNCj4+IA0KPj4gV2UgcHJlZmVyIHRvIGF2b2lkIHdhcm5pbmdzLg0KPg0KPkJ1 dCB0aGlzIGlzIHRoZW4gYSB1c2VsZXNzIHN0YXRlbWVudC4NCj4NCj4+ID5UaGUgYmlnZ2VzdCB0 aGluZyB0aGF0IGlzIHVuY2xlYXIgdG8gbWUgaXMgaG93IHRoZXNlIGdlbmVyaWMgYWNscw0KPj4g PiAgYXJlIHVzZWQgaW4gY2VydGFpbiBjb250ZXh0cy4gSW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRl LCB0aGVyZSBpcyBhDQo+PiA+ICBsaXN0IG9mIG9wYXF1ZSB0YXJnZXQgc3RyaW5ncyBidXQgSSBk byBub3Qga25vdyB3aGF0IHRoZXkgY29udGFpbiBvcg0KPj4gPiAgaG93IHRoZXkgYXJlIGNvbmZp Z3VyZWQuIFNvIGhvdyBkbyBJIHVzZSB0aGVzZSBnZW5lcmljIGFjbHM/DQo+PiA+ICBTdXBwb3Nl IEkgd2FudCB0byB1c2UgdGhlc2UgYWNscyB0byBjb250cm9sIGFjY2VzcyB0byBteSBOQw0KPj4g PiAgc2VydmVyLiBIb3cgd291bGQgSSBoYXZlIHRvIGV4dGVuZCB0aGUgTkMgc2VydmVyIGNvbmZp ZyBtb2RlbCB0byBkbw0KPj4gPiAgdGhhdD8NCj4+IA0KPj4gTWFueSBhY2xzIGFyZSB1c2VkIGZv ciBwYWNrZXQgZmlsdGVyIG9uIGludGVyZmFjZXMuDQo+PiANCj4+IFNob3VsZCB3ZSB1cGRhdGUg dGhlIGludGVyZmFjZXMueWFuZyBtb2R1bGUgdG8gYWxsb3cgYXBwbHlpbmcgYW4gYWNsID8NCj4N Cj5Obywgd2h5IHdvdWxkIHlvdSB1cGRhdGUgaW50ZXJmYWNlcy55YW5nPyBJIHdvdWxkIGhhdmUg ZXhwZWN0ZWQgYW4NCj5hdWdtZW50YXRpb24uDQo+DQo+PiBBbHNvIGNvdWxkIGJlIHVzZWQgaW4g cm91dGluZy1jZmcueWFuZyBtb2R1bGUuICBTaG91bGQgd2UgdXBkYXRlIHRoYXQNCj4+ICBtb2Rl bCB0b28gPw0KPg0KPkFnYWluLCB0aGlzIHNob3VsZCBiZSBhbiBhdWdtZW50YXRpb24uDQoNClJv dXRpbmcgcG9saWN5IHdpbGwgYmUgZG9uZSBpbiBhIHNlcGFyYXRlIGRyYWZ0LiBEbyBub3QgYXVn bWVudA0Kcm91dGluZy1jZmcgYXMgdGhlIGV4aXN0aW5nIGF0dGFjaG1lbnQgcG9pbnRzIGFyZSBi ZWluZyByZW1vdmVkLiBBbHNvLCBhDQpwcmVmaXgtbGlzdCAocHJlc2VudCBpbiBib3RoIHRoZSBC R1AgZHJhZnRzIGlzIG11Y2ggbW9yZSBzdWl0ZWQgdG8gcm91dGluZw0KcG9saWN5KS4gDQoNClRo YW5rcywNCkFjZWUgDQoNCg0KPiANCj4+ID5UaGUgSUFOQSBjb25zaWRlcmF0aW9ucyBhcmUgaW5j b21wbGV0ZSBzaW5jZSBJIHRoaW5rIHlvdSBoYXZlIHR3bw0KPj4gPiAgbW9kdWxlcyB0aGF0IG5l ZWQgcmVnaXN0cmF0aW9uLg0KPj4gDQo+PiBwYWNrZXQtZmllbGRzIGJ1dCB3aGF0IGlzIHRoZSBv dGhlciBvbmUgPyAgcGxlYXNlIGJlIHNwZWNpZmljLiAtIERhbmENCj4+DQo+DQo+SSB0aGluayB0 aGlzIGlzIGlzIGF0IGxlYXN0IGlldGYtYWNsIGFuZCBwYWNrZXQtZmllbGRzICh3aGljaCBuZWVk cyB0bw0KPmdldCBhIGJldHRlciBuYW1lKS4NCj4NCj4vanMNCj4NCj4tLSANCj5KdWVyZ2VuIFNj aG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPlBo b25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1l biB8IEdlcm1hbnkNCj5GYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3 LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Tue Feb 17 10:54:26 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327E01A8A8D for ; Tue, 17 Feb 2015 10:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FGY5CN0GjfM for ; Tue, 17 Feb 2015 10:54:21 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E301A873D for ; Tue, 17 Feb 2015 10:54:21 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-a6-54e32e401309 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1D.6C.25146.04E23E45; Tue, 17 Feb 2015 13:04:17 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Tue, 17 Feb 2015 13:54:19 -0500 From: Ing-Wher Chen To: "netmod@ietf.org" Thread-Topic: comments Re: WG Last Call: draft-ietf-netmod-acl-model-01.txt Thread-Index: AdBK4gEu62Zdw0D+S1y2LL1d80niPA== Date: Tue, 17 Feb 2015 18:54:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyuXRPoK6j3uMQg1/zeC3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxskDF9kLnvNXTLu6j7GB8TJPFyMnh4SAicTzD9dYIWwxiQv3 1rN1MXJxCAkcYZR4cf4DO4SznFHi86HLzCBVbAIGEhs+bmECsUUE1CVm7gTp4OQQFnCTaJm/ gR0i7i3xa/FUKFtPYuX7Y2C9LAKqEjdunmQEsXmBat4vewNmMwJt/n5qDdhMZgFxiVtP5jNB XCQgsWTPeWYIW1Ti5eN/UJcqSuzrn84OUa8jsWD3JzYIW1ti2cLXzBDzBSVOznzCMoFReBaS sbOQtMxC0jILScsCRpZVjBylxalluelGhpsYgaF8TILNcQfjgk+WhxgFOBiVeHgN7B6FCLEm lhVX5h5ilOZgURLnLbtyMERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo/HDX+zPT3pz2Kmu 0Vft5/LoK37i96nxEYuN+sfivR6P3tdftSuwvOLwlPPaxA2BM0p2XWAN23e/c/LkRu70JR6S l5lkdyx7OmletKrVlcZ4U6+lKxaondesSIpxv2JcZDvR+Y/+wb93r1kbrRFh7V9Tl+L++3d/ c3PWxf//4ma5riu4xH7gqBJLcUaioRZzUXEiANYzd5FGAgAA Archived-At: Subject: [netmod] comments Re: WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:54:25 -0000 - How does acl-type work with ace-type? What does it mean when an ACL has acl-type =3D eth-acl , but with a match rule that has ace-type of ace-ip? Is the intention of the model to allow each match rule to filter for a single layer? If that's not the intention, then what's the reason for an independent layer-2 filter but a consolidated layer-3 and layer-4 filter? If the model intends to allow each match rule to filter for a single layer, and if multiple match rules are allowed, then acl-type as allowed by the identities defined in the model doesn't mean much. Also, if the model intends to allow each match rule to filter for a single layer, then why combine IP and port in acl-ip-header-fields, rather than de-couple IP and port? De-coupling IP and port, and having separate IP filter and layer-4 filter, also makes sense because not all IP protocols use ports. - Regarding the structure and scope of the model: What is the scope of the ACL model? If the intention is for an ACL to be defined as a template or profile, then where can an ACL be applied? Is an ACL to be applied to an interface, to a port, or to a VRF? As a global tree, the model doesn't allow for the use case where a user wishes to make its ACL definitions private within a routing-instance or a VRF (https://svn.tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16). Also, the definition of "acl-oper-data" and "targets" forces each ACL to keep a reference to the application where the ACL is applied, when it arguably should be the other way around, i.e., the application that chooses to utilize an ACL should reference the ACL. In terms of smaller structural details, for container "acl-oper-data", why isn't "match-counter" a leaf-list to parallel "targets", to track counter for each target? A user would want to know how many packets matched an ACL at a particular interface, port, or even VRF, perhaps more so than the total number of packets that matched an ACL. Thanks, Helen From nobody Tue Feb 17 13:56:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C184F1A90E3 for ; Tue, 17 Feb 2015 13:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAxxoohHnkvP for ; Tue, 17 Feb 2015 13:56:04 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C811A90E2 for ; Tue, 17 Feb 2015 13:56:03 -0800 (PST) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.1.87.18; Tue, 17 Feb 2015 21:56:02 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.9]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.9]) with mapi id 15.01.0087.013; Tue, 17 Feb 2015 21:56:02 +0000 From: Dean Bogdanovic To: "Acee Lindem (acee)" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt Thread-Index: AQHQQj8ZsVybpoEkMUG9o+BIyFU/uZzkDuMAgAAQSgCACVtWgIAHhQ8AgAAJbICAABHrgIAAWaAA Date: Tue, 17 Feb 2015 21:56:01 +0000 Message-ID: References: <20150217153105.GA24550@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.14] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(51704005)(164054003)(51444003)(377454003)(24454002)(2950100001)(19580405001)(46102003)(83716003)(36756003)(50226001)(93886004)(87936001)(57306001)(76176999)(92566002)(122556002)(50986999)(40100003)(2656002)(102836002)(86362001)(66066001)(19580395003)(33656002)(2900100001)(77156002)(62966003)(82746002)(230783001)(110136001)(99286002)(106116001)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2015 21:56:01.9572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB421 Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 21:56:05 -0000 c25pcCBmb3IgYmV0dGVyIGNsYXJpdHkNCk9uIEZlYiAxNywgMjAxNSwgYXQgMTE6MzUgQU0sIEFj ZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KDQo+IA0KPiBSb3V0aW5n IHBvbGljeSB3aWxsIGJlIGRvbmUgaW4gYSBzZXBhcmF0ZSBkcmFmdC4gRG8gbm90IGF1Z21lbnQN Cj4gcm91dGluZy1jZmcgYXMgdGhlIGV4aXN0aW5nIGF0dGFjaG1lbnQgcG9pbnRzIGFyZSBiZWlu ZyByZW1vdmVkLiBBbHNvLCBhDQo+IHByZWZpeC1saXN0IChwcmVzZW50IGluIGJvdGggdGhlIEJH UCBkcmFmdHMgaXMgbXVjaCBtb3JlIHN1aXRlZCB0byByb3V0aW5nDQo+IHBvbGljeSkuIA0KPiAN Cj4gVGhhbmtzLA0KPiBBY2VlIA0KPiANCj4gDQpJIHRoaW5rIGhlcmUgaXMgc29tZSBjbGFyaWZp Y2F0aW9uIG5lZWRlZA0KDQpSb3V0aW5nIFBvbGljeSBhbGxvd3MgeW91IHRvIG1vZGlmeSB0aGUg cm91dGVzIHRoYXQgYXJlIGFkdmVydGlzZWQgdG8gb3IgYWNjZXB0ZWQgZnJvbSBhIG5laWdoYm9y IHdoaWxlIHVzaW5nIGFueSBvZiB0aGUgc3VwcG9ydGVkIHJvdXRpbmcgcHJvdG9jb2xzLg0KDQpQ b2xpY3kgQmFzZWQgUm91dGluZyAoUEJSKSAgKG9yIEZpbHRlciBCYXNlZCBGb3J3YXJkaW5nIGlu IEp1bm9zIGxpbmdvKSBpcyBhbiBhcHByb2FjaCB3aGVyZSB5b3Ugb3ZlcnJpZGUgc29tZSBvZiB0 aGUgZnVuZGFtZW50YWwgcnVsZXMgb2YgZGVzdGluYXRpb24gYmFzZWQgcm91dGluZyBhbmQgZm9y d2FyZCBwYWNrZXRzIGJhc2VkIG9uIG90aGVyIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgaW5jb21p bmcgcGFja2V0cy4gIFRoaXMgaXMgYWNoaWV2ZWQgYnkgd3JpdGluZyBmaXJld2FsbCBmaWx0ZXJz IHRoYXQgbWF0Y2ggdGhlIHJlbGV2YW50IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgaW5jb21pbmcg cGFja2V0IChzcmMgaXAsIGRzdCBpcCwgc3JjIHBvcnQsIGRzdCBwb3J0LCBwcm90b2NvbCwgcGFj a2V0IHNpemUsIGV0YykgYW5kIG1vZGlmeSB0aGUgbmV4dC1ob3AgYmFzZWQgb24gdGhhdCBtYXRj aC4gIFRoZSBwYWNrZXQgaXMgdGhlbiBmb3J3YXJkZWQgdG8gdGhhdCBuZXh0LWhvcCByYXRoZXIg dGhhbiB1c2luZyB0aGUgbmV4dC1ob3AgYXNzb2NpYXRlZCB3aXRoIHRoZSBkZXN0aW5hdGlvbiBp cCBhZGRyZXNzIGFsb25lLiANCg0KSSB0aGluayB0aGF0IGN1cnJlbnQgQUNMIG1vZGVsIGlzIHZl cnkgd2VsbCBzdWl0ZWQgZm9yIFBCUi4NCg0KRm9yIHJvdXRpbmcgcG9saWN5LCB5b3UgZGVmaW5l IG1hdGNoIGNvbmRpdGlvbnMgZm9sbG93ZWQgYnkgYWN0aW9uLiBJbiBKdW5vcywgcm91dGluZyBw b2xpY3kgaXMgZGVmaW5lZCBhcyBhIGNvbnRhaW5lciBvZiB0ZXJtcy4gVGVybSBpcyBhbm90aGVy IGNvbnRhaW5lciwgdGhhdCBoYXMgbWF0Y2ggY29uZGl0aW9uIGFuZCBhY3Rpb24uDQpJZiB5b3Ug Y29tcGFyZSBpdCB0byBBQ0wgbW9kZWwsIEFDTCBpcyBjb250YWluZXIgb2YgQUNFcy4gRWFjaCBB Q0UgaXMgYSBjb250YWluZXIgdGhhdCBoYXMgbWF0Y2ggY29uZGl0aW9uIGFuZCBhY3Rpb24uIA0K DQpJIHdvdWxkIGFyZ3VlIHRoYXQgZWFjaCBwb2xpY3kgY291bGQgYmUgbW9kZWxlZCBhcyBzdWNo LCBidXQgdGhhdCBtaWdodCBiZSBsb25nLCBsb25nIHNob3QuIEkgaG9wZSB3ZSBjYW4gYWdyZWUg dG8gdXNlIEFDTCBtb2RlbCBmb3IgUEJSLCB3aGVyZSBmb3Igcm91dGluZyBwb2xpY3kgSSB3b3Vs ZCBiZSBoYXBweSB0byBwcmVzZW50IGl0IGFzIGFuIG9wdGlvbiAuLi4NCg0KRGVhbg0KDQoNCg0K DQoNCg0KDQo= From nobody Wed Feb 18 01:24:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2D11A0360 for ; Wed, 18 Feb 2015 01:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 aZbMX83T4zQO for ; Wed, 18 Feb 2015 01:24:39 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14E51A00A9 for ; Wed, 18 Feb 2015 01:24:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8F2E1751 for ; Wed, 18 Feb 2015 10:24:37 +0100 (CET) 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 fSzNIA1RAHUz for ; Wed, 18 Feb 2015 10:24:36 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 18 Feb 2015 10:24:36 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD32B20036 for ; Wed, 18 Feb 2015 10:24:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NyYbD1jr96kc; Wed, 18 Feb 2015 10:24:36 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DF5A20031; Wed, 18 Feb 2015 10:24:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B6F6323257A; Wed, 18 Feb 2015 10:24:33 +0100 (CET) Date: Wed, 18 Feb 2015 10:24:33 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150218092433.GA26863@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.4.2.3i Archived-At: Subject: [netmod] comments on draft-bjorklund-yang-conformance-problem-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 09:24:43 -0000 Martin, thanks for writing up draft-bjorklund-yang-conformance-problem-00.txt. I think this collection of specific problems we have to solve is very helpful. A few comments: - The text above A1 says something about identities but then A1 does not talk about identities. I guess it will quite common that leafs only support specific subsets of defined identities (and this may also be true for certain enums / bits). - I do not understand the text at the end of 3.2. I also assume that foo2 should have the second enum included, no? - Concerning P3, does 'obsolete' not imply that clients should not assume that these nodes will be implemented? So the interesting case is mostly 'deprecated', no? - Concerning P4, I think the server must implement container x if it wants to implement and advertise mod-i. If the server cannot implement container x anymore, then mod-i can't be implemented. So I think P4-01 is the correct solution. - Concerning P5: Features are module design time partitions, it is likely that not all meaningful partitions will always be known at design time. P5 is just one special case of this. I think the alternative here is to do what SMIv2 did, namely to detach compliance definitions from the module definitions so they can be managed on their own. Note that SMIv2 rules state that conformance groups or compliance statements are never semantically changed. The only way to add something to a conformance group or compliance statement is to create a new one with a new name. - Looking at the netmod-2014-12-17-minutes, we had an axiom that said that it must be possible to determine which version of a typedef or grouping was used to define a leaf. I think this is an important thing to keep. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 18 01:27:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277B21A03E1 for ; Wed, 18 Feb 2015 01:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.61 X-Spam-Level: X-Spam-Status: No, score=-5.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zyti8QunfEfu for ; Wed, 18 Feb 2015 01:27:55 -0800 (PST) Received: from sjmda10.webex.com (sjmda10.webex.com [64.68.124.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156391A0360 for ; Wed, 18 Feb 2015 01:27:55 -0800 (PST) Received: from jva2tc118.webex.com (sjc02-wxp00-lbace03-core-vl120-np10-1.webex.com [64.68.121.245]) by sjmda10.webex.com (Postfix) with ESMTP id C2067530 for ; Wed, 18 Feb 2015 09:27:54 +0000 (GMT) Received: from jva2tc118.webex.com (localhost [127.0.0.1]) by jva2tc118.webex.com (Postfix) with ESMTP id 7715F21EF4F for ; Wed, 18 Feb 2015 09:27:54 +0000 (GMT) Date: Wed, 18 Feb 2015 09:27:54 +0000 (GMT) From: NETMOD Working Group To: netmod@ietf.org Message-ID: <1316542854.13873.1424251674486.JavaMail.nobody@jva2tc118.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_13871_1830814027.1424251674485" X-Priority: 3 Importance: normal Archived-At: Subject: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: netmod-chairs@tools.ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 09:27:57 -0000 ------=_Part_13871_1830814027.1424251674485 Content-Type: multipart/Alternative; boundary="----=_Part_13872_1345657573.1424251674485" ------=_Part_13872_1345657573.1424251674485 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKTkVUTU9EIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdl YkV4IG1lZXRpbmcuCgoKTkVUTU9EIFlBTkcgMS4xCldlZG5lc2RheSwgRmVicnVhcnkgMTgsIDIw MTUKNDowMCBwbSAgfCAgRXVyb3BlIFRpbWUgKEJlcmxpbiwgR01UKzAxOjAwKSAgfCAgMiBocnMK CgpKT0lOIFdFQkVYIE1FRVRJTkcKaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U SUQ9bWQyMjdkMDkzZDVkYTc5ZGE5NTYwMDI2NTAyZTE1MmI1Ck1lZXRpbmcgbnVtYmVyOiA2NDAg OTgzIDU1MwpNZWV0aW5nIHBhc3N3b3JkOiBhZUZhZjFUaQoKDQpKT0lOIEJZIFBIT05FDQoxLTg3 Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkgCjEtNjUwLTQ3 OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKQWNjZXNzIGNvZGU6IDY0MCA5 ODMgNTUzCgpUb2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IApodHRwOi8vd3d3LndlYmV4 LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZg0KDQoKQWRkIHRoaXMgbWVldGluZyB0 byB5b3VyIGNhbGVuZGFyOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1t ZGYwYTViMzA1MGFkZjVkNGFmMDdkM2Q2NDg1OGY2NTINCg0KCkNhbid0IGpvaW4gdGhlIG1lZXRp bmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOgpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMK CgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBh bGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9u IHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0 dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0 byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRl ZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uCg== ------=_Part_13872_1345657573.1424251674485 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBORVRN T0QgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRoaXMgV2ViRXggbWVldGluZy4K ICAgICAgICAgICAgICAgIAkgICAgICAgICAgIDwvdGQ+CiAgICAgIDwvdHI+CjwvdGFibGU+CgoK Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0 OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgIHdpZHRoPSIxMDAl Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjoj NEQ0RDREIj4KCQkJCQkJCQkJPGI+TkVUTU9EIFlBTkcgMS4xPC9iPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+V2Vk bmVzZGF5LCBGZWJydWFyeSAxOCwgMjAxNQoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+NDowMCBwbSZuYnNwOyZuYnNw O3wmbmJzcDsmbmJzcDtFdXJvcGUgVGltZSAoQmVybGluLCBHTVQrMDE6MDApJm5ic3A7Jm5ic3A7 fCZuYnNwOyZuYnNwOzIgaHJzCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFi bGU+Cgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVp Z2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9Indp ZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQg c3R5bGU9ImNvbG9yOiMwMEFGRjk7Zm9udC1zaXplOjE2cHgiPgoJCQkJCQkJCQk8YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZDIyN2QwOTNkNWRhNzlkYTk1 NjAwMjY1MDJlMTUyYjUiCgkJCQkJCQkJCQlzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9u dC1zaXplOjE2cHg7Y29sb3I6IzAwQUZGOSI+CgkJCQkJCQkJCQk8Yj5Kb2luIFdlYkV4IG1lZXRp bmc8L2I+CgkJCQkJCQkJCTwvYT4KCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90 YWJsZT4KCQkJCQkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRvOyB3aWR0aDphdXRvIWltcG9ydGFu dCI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0ZCBzdHlsZT0icGFk ZGluZy1yaWdodDogNXB4OyI+CgkJCQkJCQkJCU1lZXRpbmcgbnVtYmVyOgoJCQkJCQkJCTwvdGQ+ CgkJCQkJCQkJPHRkPjY0MCA5ODMgNTUzCgkJCQkJCQkJPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ CQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij5NZWV0aW5nIHBh c3N3b3JkOjwvdGQ+CgkJCQkJCQkJPHRkPmFlRmFmMVRpPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJ CTwvdGFibGU+CgoKCgkKCgk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQg c3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0 ZCBzdHlsZT0iZm9udC1zaXplOjE2cHgiPjxiPkpvaW4gYnkgcGhvbmU8L2I+PC90ZD48L3RyPjx0 ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEtODc3LTY2OC00NDkzPC9iPiZuYnNwO0NhbGwt aW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdp bjowcHgiPjx0ZD48Yj4xLTY1MC00NzktMzIwODwvYj4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVy IChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPkFjY2VzcyBj b2RlOiZuYnNwOzY0MCA5ODMgNTUzPC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRk PjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMu cGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Y29sb3I6IzAw QUZGOTsiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczwvYT48L3RkPjwvdHI+PC90YWJs ZT4KCgkJCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9 ImZvbnQtc2l6ZToxM3B4Ij48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/TVRJRD1tZGYwYTViMzA1MGFkZjVkNGFmMDdkM2Q2NDg1OGY2NTIiIHN0eWxlPSJ0ZXh0LWRl Y29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5OyBmb250LXNpemU6MTNweCI+QWRkIHRoaXMgbWVl dGluZzwvYT4gdG8geW91ciBjYWxlbmRhci48L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPjx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8 L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAgPHRyPgogICAgICAgPHRkIHN0eWxlPSJmb250 LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiAjNjY2NjY2OyI+CiAgICAgICAg Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KICAgICAJPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4 LmNvbS9pZXRmL21jIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZGOTtmb250LWNvbG9yOiMwMEFGRjk7Ij4KICAg ICAgICAJQ29udGFjdCBzdXBwb3J0LjwvYT4KCQk8L3RkPgogICAgPC90cj4KPC90YWJsZT4KPHRh YmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4 Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJCQkJ CQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjEycHg7Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJCQkJ SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxs b3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0 byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRl ci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8g c3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQs IGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBz ZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJPC90 cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAgPC90cj4KPC90YWJsZT4KCjwvYm9keT4= ------=_Part_13872_1345657573.1424251674485-- ------=_Part_13871_1830814027.1424251674485 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFdXJvcGUgVGltZQpCRUdJTjpTVEFOREFSRApEVFNUQVJUOjIwMTMxMDAxVDAzMDAw MApSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllNT05USD0xMApUWk9G RlNFVEZST006KzAyMDAKVFpPRkZTRVRUTzorMDEwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0tMVNVO0JZTU9OVEg9MwpUWk9GRlNFVEZST006KzAx MDAKVFpPRkZTRVRUTzorMDIwMApUWk5BTUU6RGF5bGlnaHQgU2F2aW5ncyBUaW1lCkVORDpEQVlM SUdIVApFTkQ6VlRJTUVaT05FCkJFR0lOOlZFVkVOVApBVFRFTkRFRTtDTj0iIjtST0xFPVJFUS1Q QVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm5ldG1vZEBpZXRmLm9yZwpPUkdBTklaRVI7Q049 Ik5FVE1PRCBXb3JraW5nIEdyb3VwIjpNQUlMVE86bmV0bW9kLWNoYWlyc0B0b29scy5pZXRmLm9y ZwpEVFNUQVJUO1RaSUQ9IkV1cm9wZSBUaW1lIjoyMDE1MDIxOFQxNjAwMDAKRFRFTkQ7VFpJRD0i RXVyb3BlIFRpbWUiOjIwMTUwMjE4VDE4MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYKVFJBTlNQOk9QQVFVRQpTRVFVRU5DRToxNDI0MjUxNjc0ClVJRDowMDU5M2ViOC04 ODFhLTRkNGMtODg2MC0yNzNkZDNiNzdiN2UKRFRTVEFNUDoyMDE1MDIxOFQxNTAwMDBaCkRFU0NS SVBUSU9OOlxuXG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmL2oucGhwP01USUQ9bWY1Y2IxYTI0MzJlODBiMzMwYTU0ZjRhYmY2OTM5ZTI5XG5NZWV0aW5n IG51bWJlcjogNjQwIDk4MyA1NTNcbk1lZXRpbmcgcGFzc3dvcmQ6IGFlRmFmMVRpXG5cblxuSk9J TiBCWSBQSE9ORVxuMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpIFxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKVxu QWNjZXNzIGNvZGU6IDY0MCA5ODMgNTUzXG5cblRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0aW9u czogXG5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxu XG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRw czovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ug bm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9y bWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkg YmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lv biwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBk byBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdp dGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uXG4KWC1BTFQtREVTQztGTVRU WVBFPXRleHQvaHRtbDoJPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4gPEZP TlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPgkJPGEJCQkJCWhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW1mNWNiMWEyNDMyZTgwYjMzMGE1NGY0YWJmNjkzOWUyOSI+ PEZPTlQgU0laRT0iMyIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Kb2luIFdlYkV4IG1l ZXRpbmc8L0ZPTlQ+PC9hPgkJCTx0YWJsZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJ WkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXI6PC9GT05U PgkJCQkJPC90ZD4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPjY0MCA5ODMgNTUzPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3Rh YmxlPgkJCTx0YWJsZT48dHI+PHRkPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+TWVldGluZyBwYXNzd29yZDo8L0ZPTlQ+PC90ZD48dGQ+PEZPTlQgU0laRT0iMiIg IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+YWVGYWYxVGk8L0ZPTlQ+PC90ZD48L3RyPjwv dGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxCUj4mbmJz cDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5ic3A7IDxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS04 NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0Nh bmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQwIDk4MyA1NTM8L0ZPTlQ+ Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVz dHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9ImFyaWFs Ij5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsgPEJSPjwv Rk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBocmVmPSJo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzAw QUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJzcDs8QlI+ Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlhbCI+SU1Q T1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dz IGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBi ZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4g Qnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3Vj aCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRp c2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNz aW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6TkVUTU9EIFlBTkcgMS4xClBSSU9SSVRZOjUKQ0xB U1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQTEFZCkRFU0NS SVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== ------=_Part_13871_1830814027.1424251674485-- From nobody Wed Feb 18 02:00:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550B41A86FC for ; Wed, 18 Feb 2015 02:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xmHrzwH5Di6 for ; Wed, 18 Feb 2015 02:00:53 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan34.extendcp.co.uk [79.170.42.6]) (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 653E21A86F1 for ; Wed, 18 Feb 2015 02:00:53 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan8.hi.local) by mailscan-g64.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YO1R4-0000mi-7E; Wed, 18 Feb 2015 10:00:50 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=www.outitgoes.com) by mailscan8.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1YO1R2-0000ZL-2v; Wed, 18 Feb 2015 10:00:50 +0000 Received: from localhost ([127.0.0.1]) by webmail6.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1YO1R1-0001NV-KK; Wed, 18 Feb 2015 10:00:47 +0000 Message-Id: <44d3d1dcdfde4ac642d921a693a507fe6596475d@webmail.hansfords.net> From: "Jonathan Hansford" To: "Juergen Schoenwaelder" , netmod@ietf.org X-Mailer: Atmail 6.6.0.11156 X-Originating-IP: 10.0.1.197 in-reply-to: <20150218092433.GA26863@elstar.local> Date: Wed, 18 Feb 2015 10:00:47 +0000 Content-Type: multipart/alternative; boundary="=_8cee2659a3de80c64ff7eccef7324993" MIME-Version: 1.0 X-Authenticated-As: jonathan@hansfords.net Archived-At: Subject: Re: [netmod] comments on draft-bjorklund-yang-conformance-problem-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 10:00:56 -0000 --=_8cee2659a3de80c64ff7eccef7324993 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =0A=0A=09In 3.2.2, for consistency shouldn't the enumeration in typedef= foo2=0Aalso include =C2=A0enum w?=0A=0A=09In 3.3, s/type if leaf/ype of= leafIn 3.3.1 s/modules that=0Auses/modules that use=0AOne general IETF= gripe for those less au fait with the subject matter.=0AIs there any do= cument anywhere that expands on acronyms? One per WG=0Awould help since= they are used not just in documents but even more so=0Ain emails. For e= xample, what is an NP-container? I presume this is to=0Ado with the use= of the presence statement but its meaning is not clear=0Afrom the conte= xt.=0A=0A----- Original Message -----=0AFrom: "Juergen Schoenwaelder"= =0ATo:=0ACc:=0ASent:Wed, 18 Feb 2015 10:24:33 +0100=0ASubject:[netmod]= comments on=0Adraft-bjorklund-yang-conformance-problem-00.txt=0A=0A Mar= tin,=0A=0A thanks for writing up=0Adraft-bjorklund-yang-conformance-prob= lem-00.txt.=0A I think this collection of specific problems we have to s= olve is very=0A helpful. A few comments:=0A=0A - The text above A1 says= something about identities but then A1 does=0A not talk about identitie= s. I guess it will quite common that leafs=0A only support specific subs= ets of defined identities (and this may=0A also be true for certain enum= s / bits).=0A=0A - I do not understand the text at the end of 3.2. I als= o assume that=0A foo2 should have the second enum included, no?=0A=0A -= Concerning P3, does 'obsolete' not imply that clients should not=0A ass= ume that these nodes will be implemented? So the interesting case=0A is= mostly 'deprecated', no?=0A=0A - Concerning P4, I think the server must= implement container x if it=0A wants to implement and advertise mod-i.= If the server cannot=0A implement container x anymore, then mod-i can't= be implemented. So=0A I think P4-01 is the correct solution.=0A=0A - Co= ncerning P5: Features are module design time partitions, it is=0A likely= that not all meaningful partitions will always be known at=0A design ti= me. P5 is just one special case of this.=0A=0A I think the alternative h= ere is to do what SMIv2 did, namely to=0A detach compliance definitions= from the module definitions so they=0A can be managed on their own. Not= e that SMIv2 rules state that=0A conformance groups or compliance statem= ents are never semantically=0A changed. The only way to add something to= a conformance group or=0A compliance statement is to create a new one w= ith a new name.=0A=0A - Looking at the netmod-2014-12-17-minutes, we had= an axiom that said=0A that it must be possible to determine which versi= on of a typedef or=0A grouping was used to define a leaf. I think this i= s an important=0A thing to keep.=0A=0A /js=0A=0A -- =0A Juergen Schoenwa= elder Jacobs University Bremen gGmbH=0A Phone: +49 421 200 3587 Campus R= ing 1 | 28759 Bremen | Germany=0A Fax: +49 421 200 3103 =0A=0A _________= ______________________________________=0A netmod mailing list=0A netmod@= ietf.org=0A https://www.ietf.org/mailman/listinfo/netmod=0A --=_8cee2659a3de80c64ff7eccef7324993 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

In 3.2.2, for consistency shouldn't the enum= eration in typedef foo2 also include =C2=A0enum w?

In 3.3, s/type= if leaf/ype of leaf

In 3.3.1 s/modules that uses/modules that u= se

One general IETF gripe for those less au fait with th= e subject matter. Is there any document anywhere that expands on acronym= s? One per WG would help since they are used not just in documents but e= ven more so in emails. For example, what is an NP-container? I presume t= his is to do with the use of the presence statement but its meaning is n= ot clear from the context.

----- Original Message= -----
From:
"Juergen Schoenwaelder" <j.s= choenwaelder@jacobs-university.de>

To:
<netmod@ietf.org>
Cc:

Sent:
Wed,= 18 Feb 2015 10:24:33 +0100
Subjec= t:
[netmod] comments on draft-bjorklund-yang-conformance-problem-00= txt


=0AMartin,

=0Athanks for writing up dra= ft-bjorklund-yang-conformance-problem-00.txt.
=0AI think this colle= ction of specific problems we have to solve is very
=0Ahelpful. A f= ew comments:

=0A- The text above A1 says something about iden= tities but then A1 does
=0A not talk about identities. I guess it= will quite common that leafs
=0A only support specific subsets of= defined identities (and this may
=0A also be true for certain enu= ms / bits).

=0A- I do not understand the text at the end of 3= 2. I also assume that
=0A foo2 should have the second enum includ= ed, no?

=0A- Concerning P3, does 'obsolete' not imply that cl= ients should not
=0A assume that these nodes will be implemented?= So the interesting case
=0A is mostly 'deprecated', no?
=0A- Concerning P4, I think the server must implement container x if= it
=0A wants to implement and advertise mod-i. If the server cann= ot
=0A implement container x anymore, then mod-i can't be implemen= ted. So
=0A I think P4-01 is the correct solution.

=0A-= Concerning P5: Features are module design time partitions, it is
= =0A likely that not all meaningful partitions will always be known at=0A design time. P5 is just one special case of this.

= =0A I think the alternative here is to do what SMIv2 did, namely to=0A detach compliance definitions from the module definitions so the= y
=0A can be managed on their own. Note that SMIv2 rules state tha= t
=0A conformance groups or compliance statements are never semant= ically
=0A changed. The only way to add something to a conformance= group or
=0A compliance statement is to create a new one with a n= ew name.

=0A- Looking at the netmod-2014-12-17-minutes, we ha= d an axiom that said
=0A that it must be possible to determine whi= ch version of a typedef or
=0A grouping was used to define a leaf.= I think this is an important
=0A thing to keep.

=0A/js=

=0A--
=0AJuergen Schoenwaelder Jacobs Univer= sity Bremen gGmbH
=0APhone: +49 421 200 3587 Campus Ring 1= | 28759 Bremen | Germany
=0AFax: +49 421 200 3103 <ht= tp://www.jacobs-university.de/>

=0A_______________________= ________________________
=0Anetmod mailing list
=0Anetmod@ietf= org
=0Ahttps://www.ietf.org/mailman/listinfo/netmod
--=_8cee2659a3de80c64ff7eccef7324993-- From nobody Wed Feb 18 02:50:33 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8771A9129 for ; Wed, 18 Feb 2015 02:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48h5agk1PtLl for ; Wed, 18 Feb 2015 02:50:30 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6801A9138 for ; Wed, 18 Feb 2015 02:50:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6DC8D6DC for ; Wed, 18 Feb 2015 11:50:28 +0100 (CET) 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 Iy1eWcuKK4qL for ; Wed, 18 Feb 2015 11:50:27 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 18 Feb 2015 11:50:27 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DAA120037 for ; Wed, 18 Feb 2015 11:50:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QvlGYfyxdc42; Wed, 18 Feb 2015 11:50:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38CE520031; Wed, 18 Feb 2015 11:50:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4ADDF32326DC; Wed, 18 Feb 2015 11:50:26 +0100 (CET) Date: Wed, 18 Feb 2015 11:50:26 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150218105026.GA27193@elstar.local> Mail-Followup-To: netmod@ietf.org References: <1316542854.13873.1424251674486.JavaMail.nobody@jva2tc118.webex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1316542854.13873.1424251674486.JavaMail.nobody@jva2tc118.webex.com> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] WebEx meeting invitation: NETMOD YANG 1.1 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 10:50:31 -0000 Hi, today's meeting will focus on YANG 1.1 conformance. It is recommended that people read the following two I-Ds: https://tools.ietf.org/html/draft-bjorklund-yang-conformance-problem-00 https://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-04 We will use this etherpad page today: http://etherpad.tools.ietf.org:9000/p/notes-ietf-netmod-virtual-interim-2015-02-18?useMonospaceFont=true Talk to you later, /js On Wed, Feb 18, 2015 at 09:27:54AM +0000, NETMOD Working Group wrote: > > Hello, > > NETMOD Working Group invites you to join this WebEx meeting. > > > NETMOD YANG 1.1 > Wednesday, February 18, 2015 > 4:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hrs > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=md227d093d5da79da9560026502e152b5 > Meeting number: 640 983 553 > Meeting password: aeFaf1Ti > > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 640 983 553 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=mdf0a5b3050adf5d4af07d3d64858f652 > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 18 03:16:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77B61A9173 for ; Wed, 18 Feb 2015 03:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yULaAh3NCNFs for ; Wed, 18 Feb 2015 03:16:40 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C46A1A911E for ; Wed, 18 Feb 2015 03:16:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3143D947 for ; Wed, 18 Feb 2015 12:16:35 +0100 (CET) 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 ypRca8pyr8sX for ; Wed, 18 Feb 2015 12:16:33 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 18 Feb 2015 12:16:34 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61C2A20036 for ; Wed, 18 Feb 2015 12:16:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Fi7cj3N8eRHM; Wed, 18 Feb 2015 12:16:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57C0C20031; Wed, 18 Feb 2015 12:16:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6B1A23232756; Wed, 18 Feb 2015 12:16:33 +0100 (CET) Date: Wed, 18 Feb 2015 12:16:33 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150218111633.GA27312@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.4.2.3i Archived-At: Subject: [netmod] comments on draft-bierman-netmod-yang-conformance-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 11:16:41 -0000 Hi, this is very valuable input to the conformance issue discussion. There is likely useful terminology in section 1.1.3 as well. - Typedef drift vs. grouping drift: I think typedef drift can be handled partially. A module update can narrow the value space to an earlier version of a meanwhile expanded typedef. For groupings, we do not have a mechanism to do the same. If a grouping got expanded but a module wants to continue to use the unexpanded definition, there does not seem to be a way to do this. Options: (i) do not allow groupings to change, (ii) enhance the uses statement so it can 'subset' a grouping, (iii) enhance the uses statement so that it can refer to a specific version of a grouping (which however we do not do for typedefs). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 18 04:06:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2301A802E for ; Wed, 18 Feb 2015 04:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 7vQu27FLyu_E for ; Wed, 18 Feb 2015 04:06:52 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4FA1A8731 for ; Wed, 18 Feb 2015 04:06:52 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 37227751; Wed, 18 Feb 2015 13:06:51 +0100 (CET) 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 IiXTsKSxnMUp; Wed, 18 Feb 2015 13:06:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Feb 2015 13:06:49 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8AF520036; Wed, 18 Feb 2015 13:06:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Z68V9aZLgAbT; Wed, 18 Feb 2015 13:06:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C62AA20031; Wed, 18 Feb 2015 13:06:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A58EE323283F; Wed, 18 Feb 2015 13:06:46 +0100 (CET) Date: Wed, 18 Feb 2015 13:06:46 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20150218120646.GA27531@elstar.local> Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" References: <54DB5A20.1030707@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DB5A20.1030707@ericsson.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 12:06:55 -0000 Balazs, I added the new writeup as Y57-03 to the issue tracker. /js On Wed, Feb 11, 2015 at 02:33:20PM +0100, Balazs Lengyel wrote: > Hello Juergen, > I still have an outstanding action point to update the current proposal > for non-unique-list. > The only comment I have received was that for replace/merge we should have > similar behavior as we have for lists: > > For merge and replace if the insert attribute is not present an existing > leaf-list value shall not be moved. > > Here are my modifications to what can be found on the issue-list > [1]http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58. > > I merged the two solutions, as they were not real alternatives; the second > part about addressing by position, just built on the main part. > > regards Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: [2]Balazs.Lengyel@ericsson.com > > References > > Visible links > 1. http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58 > 2. mailto:Balazs.Lengyel@ericsson.com > > Description > --------------- > > In YANG 1.0 all values in a leaf-list MUST be unique. The proposal is to relax this in YANG 1.1. > > If the leaf-list is unique the handling does not change compared to YANG 1.0 > > A nonUnique leaf-list is still handled as a set of separate leafs as in YANG 1.0 > New mechanism to handle all values of a leaf-list toghether are NOT introduced. > > If we have a leaf-list with nonUnique values in the datastore a value in the > edit-config addresses the first such value in the datastore. > This alternative is selected for simplicity. > (Note: Alternatively it could address all such values in the datastore which > would be simple for delete/remove, but strange for replace and merge. Merge should > be additive but merging [a,a,a] with [a] would result in [a] which is not > additive. It would be very strange for insert-after; we want to insert one value, but suddenly > it can become multiple values.) > > > Solution Y57-01 > > Change to section 3: > > leaf-list: Like the leaf node but defines a set of uniquely identifiable > nodes rather than a single node. Each node has a value but no child nodes. > > change to > > leaf-list: Like the leaf node but defines a set of nodes rather than a > single node. Each node has a value but no child nodes. > > Change to section 4.2.2.2: > > A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf. > > What does this mean? Does it mean that leaf-lists need to have unique leafs? Change to: > > A leaf-list is a sequence of leaf nodes. > > Remove from section 7.7: > > The values in a leaf-list MUST be unique. > > Add to section 7.7.2: > > unique-leaf-list cardinality 0..1 > > Add a level 3 section before 7.7.6: > > 7.7.5b The unique-leaf-list Statement > > The "unique-leaf-list" statement takes as an argument the string "true" or "false". > If "unique-leaf-list" is "true", values within the leaf-lists must be unique. > If "unique-leaf-list" is "false", values within the leaf-lists may be repeated. > If "unique-leaf-list" is not specified, the default is true. > > Change section 7.7.7 > > The operations way of working is dependent on the value of unique-leaf-list. > If unique-leaf-list is true the current handling is unchanged. > If unique-leaf-list is false the following applies: > > delete/remove: delete/remove the addressed value (first occurence) from the > leaf-list. If a value exists multiple times in edit-config try to > delete 2/3/.. instances of the value. For delete it is an error if > insufficient value instances exist in datastore. > > create: create value. It succeeds even if value already exists, just adds the > value once more. If no "insert" attribute is present in the "create" operation, > it defaults to "last". If a value exists multiple times in edit-config repeat > the steps. > > replace, merge: For each specific value, the number of instances of the value > in edit-config and the datastore are matched against each other. > > For each such value instance if insert is not specified the value in the datastore is left unchanged. > > If the insert is specified, delete the (first/matching) value in the datastore, if > it exists, and re-create it as specified by > insert. If the insert attribute refers to a value, it is the first occurrence > of the value that is indicated. If a value exists multiple times in edit-config > repeat the steps. > > If edit-config contains more instances, the additional ones are created as > in a create operation. If the datastore contains more instances, they are not modified. > > ================================================================================================= > > > > > Position can be used to select a leaf in a leaf-list, but only if it is "ordered-by user". > For system-ordered lists this leads to error. (Same as insert) > > Position must be between 1 and the length of the leaf-list, if it is not, send an error message. > Indexing starts at 1 not 0, following XPATH conventions. > > In a delete/remove operation if position is specified, the value of the leaf-instance, has no effect, > it may be omitted by the client. (Addressing by position takes precedence over addressing by value.) > > If both the position and the value attributes are specified in edit-config for the same data node, > the value attribute has no effect and may be (should be) ommitted by the client. > > If position is specified, the insert attribute can only take the values after and before. First > and last are error. (There is no sense in specifying position once the insert=first/last is specified, > it would just add one more useless and complicated case.) > > Further changes to section 7.7.9: > > In an "ordered-by user" leaf-list, the attribute "position" in the YANG XML namespace (Section 5.3.1) > can be used to address specific values in the leaf-list. > > create: add: If position is specified but insert is not specified insert=after is implied. > > replace/merge: if position is specified but insert is not, replace the value specified by position. > If both position and insert=after/before is specified, insert a new leaf with the value at the specified position. (replace/merge works differntly with and without position.) > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 18 05:59:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C85B1A8871 for ; Wed, 18 Feb 2015 05:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlc4aVmrQDov for ; Wed, 18 Feb 2015 05:59:33 -0800 (PST) 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 120981A87E6 for ; Wed, 18 Feb 2015 05:59:32 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-88-54e49ac20d00 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 65.05.04076.2CA94E45; Wed, 18 Feb 2015 14:59:31 +0100 (CET) Received: from [159.107.197.216] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.210.2; Wed, 18 Feb 2015 14:59:30 +0100 Message-ID: <54E49AC2.9070101@ericsson.com> Date: Wed, 18 Feb 2015 14:59:30 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andy Bierman References: <54DB5A20.1030707@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvje7hWU9CDB68YbZ4cGQWu8XVjT8Z LeZfbGR1YPZYsuQnk8eGA54eLf0XWQKYo7hsUlJzMstSi/TtErgylp/4wF5wUbhi03TDBsYO /i5GTg4JAROJ3ienWSBsMYkL99azdTFycQgJHGGUODftCDuEs5ZR4tiRTnaQKl4BbYnzKyBs FgFViUeLDzOB2GwCRhJT+8+DTRIViJKYff4BK0S9oMTJmU/A4iJA9RfmTmQGsZkF0iXuXNsG ViMsoC/x9P1fRhBbSKBA4uGco2A2p0CgxLX7bVD1FhIz559nhLDlJba/ncMMUa8h8fDCX9YJ jIKzkKybhaRlFpKWBYzMqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECA/jglt9WOxgPPnc8 xCjAwajEw2vA8CREiDWxrLgy9xCjNAeLkjivnfGhECGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MDhZtjknh/AvKfKNspUXLHm9tuPPA8fcNdW+fdR+XNHVG3HMqP+TydPKjbbuNJovXPFtU fydXd+GxlPMfj6V8+p/IH1i47MLks4f3/JLYbpX476Sk4LoHQSdDZj9Ut8vbtGim9+//Szt9 krauPbROLtT99PnNZ3+eqtgXdnPT3RVJJy8zJXrldSuxFGckGmoxFxUnAgD2VvZhQQIAAA== Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 13:59:38 -0000 Hello, "delete/remove: delete/remove the addressed value (first occurrence)" so delete should only change one value, unless you have multiple values in the edit-config as well. If you want to move the nth same value use position for addressing. Balazs On 2015-02-11 16:27, Andy Bierman wrote: > Hi, > > I cannot tell if delete is supposed to be delete-first or delete-all. > It seems to be the latter from the text. > The other operations seem to affect only 1 leaf-list instance. > > It seems that delete and re-create needs to be used > to move the 2nd - Nth instance of a leaf-list (with value 'foo'). > A merge or replace (w/ insert attr to make it a move) will always > move the first instance. But delete affects only the first (or all?) > instances. So I don't see how the 2nd to Nth instances can ever > be moved. Seems like you would need to delete-all, then add back > each instance. It seems the order the edits are applied (from 1 ) > would be critical -- not something that is supported by NETCONF, > so N edits would be needed, not 1. > > > Andy > > > > > On Wed, Feb 11, 2015 at 5:33 AM, Balazs Lengyel > wrote: >> Hello Juergen, >> I still have an outstanding action point to update the current proposal for >> non-unique-list. >> The only comment I have received was that for replace/merge we should have >> similar behavior as we have for lists: >> >> For merge and replace if the insert attribute is not present an existing >> leaf-list value shall not be moved. >> >> Here are my modifications to what can be found on the issue-list >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58. >> >> I merged the two solutions, as they were not real alternatives; the second >> part about addressing by position, just built on the main part. >> >> regards Balazs >> >> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 Tel: +36-1-437-7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Feb 18 06:01:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E897E1A87BF for ; Wed, 18 Feb 2015 06:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7p4rIYeRMkk for ; Wed, 18 Feb 2015 06:01:01 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1233B1A1AB0 for ; Wed, 18 Feb 2015 06:01:00 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-03-54e49b1b3ee7 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D6.D2.24955.B1B94E45; Wed, 18 Feb 2015 15:00:59 +0100 (CET) Received: from [159.107.197.216] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Wed, 18 Feb 2015 15:00:58 +0100 Message-ID: <54E49B1A.3040400@ericsson.com> Date: Wed, 18 Feb 2015 15:00:58 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andy Bierman References: <54DB5A20.1030707@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvja707CchBssmyFg8ODKL3eLqxp+M FvMvNrI6MHssWfKTyWPDAU+Plv6LLAHMUVw2Kak5mWWpRfp2CVwZ/3rOsxTcFat48uQiSwPj EcEuRk4OCQETiaN3p7FD2GISF+6tZ+ti5OIQEjjCKPF48hl2CGcto8TcRzPZQKp4BbQlWu53 MYPYLAKqEi+a5rOC2GwCRhJT+8+zgNiiAlESs88/YIWoF5Q4OfMJWFwEqP7C3IlgvcwC6RJ3 rm0DqxEW0Jd4+v4vI4gtJFAgcX/dUrB6ToFAievr37FB1FtIzJx/nhHClpfY/nYOM0S9hsTD C39ZJzAKzkKybhaSlllIWhYwMq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECAzhg1t+q+5g vPzG8RCjAAejEg9vgcWTECHWxLLiytxDjNIcLErivHbGh0KEBNITS1KzU1MLUovii0pzUosP MTJxcEo1MCbWTvG89i6mf73cDImwg14zLr9ekfB30qH+Pad43A+rctxw2/PYceP1/KqW7zoz zRpVZM4+ZY9/avp0x+RnvCdF9216Vsjx5N9F77l/yjJeJjnVLJte1CDM+OX3EX/dP0LrMo8f ZjrCWvo3l/eJetHCO5M+9SeJpAVXnGD5dvH4kgcGW7kaN3spsRRnJBpqMRcVJwIAGOtPhUIC AAA= Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:01:06 -0000 Hello, Netconf details are today in YANG. They could be removed, but that is not dependent on this proposal in any way. Yes we have to choose whether we address the leaf-list or the leaf-instance in the leaf-list. In YANG 1.0 as in my proposal we address the leaf-instance. I don't want to change that. It would be an incompatible change. If you want addressing the whole leaf-list as a new feature, go ahead propose it. regards Balazs On 2015-02-11 17:13, Andy Bierman wrote: > Hi, > > I don't know if it is such a good idea to add more whistles to a > broken construct. > IMO leaf-list is incomplete because (unlike list) the individual > values are really > managed as a group. But there is no create-all, delete-all, get-all support > in any protocol. A leaf-list has to be placed in an NP-container by itself, > which adds a layer and complexity to the model. > > I would be in favor of a comprehensive fix that made leaf-list as > useful as other YANG data node types. This would require > protocol changes. > > I would really prefer not to continue defining NETCONF protocol behavior > in the YANG spec. YANG 1.1 could be obsolete before it is even > published, because it is so protocol-specific and new protocols will > be using it that are not mentioned. IMO all protocol details need to be > moved out of YANG 1.1 into a NETCONF mapping document. > RESTCONF and other protocols can be specified in their own > mapping documents as well. > > > Andy > > > > > On Wed, Feb 11, 2015 at 5:33 AM, Balazs Lengyel > wrote: >> Hello Juergen, >> I still have an outstanding action point to update the current proposal for >> non-unique-list. >> The only comment I have received was that for replace/merge we should have >> similar behavior as we have for lists: >> >> For merge and replace if the insert attribute is not present an existing >> leaf-list value shall not be moved. >> >> Here are my modifications to what can be found on the issue-list >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58. >> >> I merged the two solutions, as they were not real alternatives; the second >> part about addressing by position, just built on the main part. >> >> regards Balazs >> >> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 Tel: +36-1-437-7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Feb 18 06:05:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862631A924E for ; Wed, 18 Feb 2015 06:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47j7xoV_3rrD for ; Wed, 18 Feb 2015 06:05:02 -0800 (PST) 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 AAFCE1A9127 for ; Wed, 18 Feb 2015 06:04:56 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-37-54e49c06739b Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.61.04231.60C94E45; Wed, 18 Feb 2015 15:04:55 +0100 (CET) Received: from [159.107.197.216] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Wed, 18 Feb 2015 15:04:54 +0100 Message-ID: <54E49C06.1050604@ericsson.com> Date: Wed, 18 Feb 2015 15:04:54 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kent Watsen , Andy Bierman References: <54DB5A20.1030707@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+JvjS77nCchBk+msls8ODKL3eLAHHaL +RcbWR2YPZYs+cnkcb3pKrtHS/9FlgDmKC6blNSczLLUIn27BK6MfQfkC05xVfx6u5+9gXEy RxcjJ4eEgInEo+dvGCFsMYkL99azdTFycQgJHGGU+L3/DjOEs5ZR4uyf1awgVbwC2hKLt75j B7FZBFQlzve9YwOx2QSMJKb2n2cBsUUFoiRmn38AVS8ocXLmE7C4iICHxPpjv8HqmQXUJe6c egxmCwvoSzx9/5cRYtlURomHn1vATuIUMJR42dgKNIgDqMFe4sHWMoheeYntb+cwg9hCAhoS Dy/8ZZ3AKDgLybpZCB2zkHQsYGRexShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYvge3/Nbd wbj6teMhRgEORiUeXgOGJyFCrIllxZW5hxilOViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamBk2VF46ULYkqx3nQxXd7HkvrtU5X39ZHpgCFNFClfKo0bVg0G3NFlernEUz995 y7K5ZpNs89tqxsXbO9kZZCwcboS9LN3BOWnP4bZ3jPUPFm6P2j7tz9kJFp3fnjkl/L78cj/f 35zQy6rbjeewHbx26rzmD583y2LfHHC+/FNwifm6DZofqlUfKbEUZyQaajEXFScCANOPmP1A AgAA Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:05:06 -0000 Hello, In one sense it is only a few items that should be moved from RFC6020 to a new "Netconf encoding of Yang data" RFC: insert-after/before-position for lists and leaflists. IMO really every chapter called "NETCONF Operations" chapter should be moved. Maybe some details about canonical encoding as well, e.g. namespace are handled differently in Netconf and Restconf. regards Balazs On 2015-02-11 19:42, Kent Watsen wrote: >> I would really prefer not to continue defining NETCONF protocol behavior >> in the YANG spec. YANG 1.1 could be obsolete before it is even >> published, because it is so protocol-specific and new protocols will >> be using it that are not mentioned. IMO all protocol details need to be >> moved out of YANG 1.1 into a NETCONF mapping document. >> RESTCONF and other protocols can be specified in their own >> mapping documents as well. > > I agree with this sentiment. So as to not introduce an immediate need for > 6241bis, could YANG 1.1 move all its NETCONF-specific mapping text into an > Addendum section? - how much such text is there? > > Kent > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Feb 18 06:05:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740C61A8983 for ; Wed, 18 Feb 2015 06:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDWnJZKoW0yb for ; Wed, 18 Feb 2015 06:05:39 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7AC1A9141 for ; Wed, 18 Feb 2015 06:05:02 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 1F90C1280B2F; Wed, 18 Feb 2015 15:05:01 +0100 (CET) Date: Wed, 18 Feb 2015 15:05:00 +0100 (CET) Message-Id: <20150218.150500.482202690548793699.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150218092433.GA26863@elstar.local> References: <20150218092433.GA26863@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / 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] comments on draft-bjorklund-yang-conformance-problem-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:05:42 -0000 Juergen Schoenwaelder wrote: > Martin, > > thanks for writing up draft-bjorklund-yang-conformance-problem-00.txt. > I think this collection of specific problems we have to solve is very > helpful. A few comments: > > - The text above A1 says something about identities but then A1 does > not talk about identities. I guess it will quite common that leafs > only support specific subsets of defined identities Agreed. Andy's proposed "get-allowed-identities" is one solution for this. > (and this may > also be true for certain enums / bits). In YANG 1.1 you can have if-feature per enum/bit, but unless you have that, an implemention should implement all enums/bits. > - I do not understand the text at the end of 3.2. Which text? > I also assume that > foo2 should have the second enum included, no? Yes, bug. > - Concerning P3, does 'obsolete' not imply that clients should not > assume that these nodes will be implemented? So the interesting case > is mostly 'deprecated', no? Ok. > - Concerning P4, I think the server must implement container x if it > wants to implement and advertise mod-i. If the server cannot > implement container x anymore, then mod-i can't be implemented. So > I think P4-01 is the correct solution. Agreed. > - Concerning P5: Features are module design time partitions, it is > likely that not all meaningful partitions will always be known at > design time. P5 is just one special case of this. > > I think the alternative here is to do what SMIv2 did, namely to > detach compliance definitions from the module definitions so they > can be managed on their own. Note that SMIv2 rules state that > conformance groups or compliance statements are never semantically > changed. The only way to add something to a conformance group or > compliance statement is to create a new one with a new name. My worry is that a vendor writes his own compliance statement with the nodes he chose to implement. This would essentially let people implement arbitrary subsets of any standard. > - Looking at the netmod-2014-12-17-minutes, we had an axiom that said > that it must be possible to determine which version of a typedef or > grouping was used to define a leaf. I think this is an important > thing to keep. Yes; my intention was that this is covered by axiom A4. /martin From nobody Wed Feb 18 06:23:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520131A8852 for ; Wed, 18 Feb 2015 06:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpiw5mZzNoU6 for ; Wed, 18 Feb 2015 06:23:46 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF0A1A87A1 for ; Wed, 18 Feb 2015 06:23:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4FC4171B; Wed, 18 Feb 2015 15:23:45 +0100 (CET) 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 ZkYVSvziJt1Y; Wed, 18 Feb 2015 15:23:43 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Feb 2015 15:23:44 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A1EF20036; Wed, 18 Feb 2015 15:23:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id puAckUnv_fOV; Wed, 18 Feb 2015 15:23:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E2B220031; Wed, 18 Feb 2015 15:23:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 114383232996; Wed, 18 Feb 2015 15:23:40 +0100 (CET) Date: Wed, 18 Feb 2015 15:23:40 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150218142340.GA27885@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20150218092433.GA26863@elstar.local> <20150218.150500.482202690548793699.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150218.150500.482202690548793699.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-bjorklund-yang-conformance-problem-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 14:23:49 -0000 On Wed, Feb 18, 2015 at 03:05:00PM +0100, Martin Bjorklund wrote: > > - I do not understand the text at the end of 3.2. > > Which text? > I do not recall anymore, perhaps I got the number wrong or after re-reading it it is not uncleary anymore. Lets forget it. > > - Concerning P5: Features are module design time partitions, it is > > likely that not all meaningful partitions will always be known at > > design time. P5 is just one special case of this. > > > > I think the alternative here is to do what SMIv2 did, namely to > > detach compliance definitions from the module definitions so they > > can be managed on their own. Note that SMIv2 rules state that > > conformance groups or compliance statements are never semantically > > changed. The only way to add something to a conformance group or > > compliance statement is to create a new one with a new name. > > My worry is that a vendor writes his own compliance statement with the > nodes he chose to implement. This would essentially let people > implement arbitrary subsets of any standard. But then its the vendor's compliance definition and not the standard's compliance. A vendor who chooses not to implement the standard will not implement the standard, I do not think we can do much to change that. > > - Looking at the netmod-2014-12-17-minutes, we had an axiom that said > > that it must be possible to determine which version of a typedef or > > grouping was used to define a leaf. I think this is an important > > thing to keep. > > Yes; my intention was that this is covered by axiom A4. Yes, perhaps this is implicitly included in A4. I think a big problem are changing groupings. If a module uses a grouping in two places and the grouping gets expanded, then the module is forced to use the expansion on both places, which may however not be meaningful. With an expanded type, I can use subtyping. With an expanded grouping, I am not having any tools to handle this situation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 18 06:27:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994631A87E7 for ; Wed, 18 Feb 2015 06:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5rwjpQwhFhF for ; Wed, 18 Feb 2015 06:27:44 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07081A87F0 for ; Wed, 18 Feb 2015 06:27:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 85B03A15; Wed, 18 Feb 2015 15:27:43 +0100 (CET) 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 BnINy20lFfWQ; Wed, 18 Feb 2015 15:27:41 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Feb 2015 15:27:43 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E136D20036; Wed, 18 Feb 2015 15:27:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 66aJGmyQykzn; Wed, 18 Feb 2015 15:27:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E32C920031; Wed, 18 Feb 2015 15:27:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 03E2D32329D6; Wed, 18 Feb 2015 15:27:41 +0100 (CET) Date: Wed, 18 Feb 2015 15:27:41 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20150218142741.GB27885@elstar.local> Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" References: <54DB5A20.1030707@ericsson.com> <54E49AC2.9070101@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54E49AC2.9070101@ericsson.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 14:27:48 -0000 Balazs, I think we need a better problem statement. The text we have in Y57 says 'lets see whether we can relax the rules' but it does not provide a rationale why we would do that. Which benefit do we get if we relax the rules? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 18 06:50:14 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FBB1A87D7 for ; Wed, 18 Feb 2015 06:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdd5-0DKfbMt for ; Wed, 18 Feb 2015 06:50:10 -0800 (PST) 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 EF4371A8835 for ; Wed, 18 Feb 2015 06:50:07 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-37-54e4a69dcccc Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7B.88.04231.D96A4E45; Wed, 18 Feb 2015 15:50:06 +0100 (CET) Received: from [159.107.197.216] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Wed, 18 Feb 2015 15:50:05 +0100 Message-ID: <54E4A69D.9020908@ericsson.com> Date: Wed, 18 Feb 2015 15:50:05 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Juergen Schoenwaelder , "netmod@ietf.org" References: <54DB5A20.1030707@ericsson.com> <20150218120646.GA27531@elstar.local> In-Reply-To: <20150218120646.GA27531@elstar.local> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvje68ZU9CDP6uZrK4uvEno8X8i42s DkweS5b8ZPLYcMAzgCmKyyYlNSezLLVI3y6BK+PyY5GCA9YVLbOKGxh363YxcnJICJhIHP23 jQ3CFpO4cG89kM3FISRwhFHi7P+lrBDOWkaJ628usIBU8QpoSzw5fZ0ZxGYRUJXYuvo+mM0m YCQxtf88WI2oQJTE7PMPWCHqBSVOznwCFhcRSJdomneNHcQWFlCTuNNzFKxGSCBQ4t/ndUwg NifQnNdH3gDFOTiYBewlHmwtAwkzC8hLbH87hxmiXEPi4YW/rBMYBWYh2TALoWMWko4FjMyr GEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQLD8eCW37o7GFe/djzEKMDBqMTDa8DwJESINbGs uDL3EKM0B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyK1Xv4EjpYHes3pdxU +rTeeE6tmmXjJKmPy2Z69ccuE91VIpJRsliohnNT5J2j6xuYq/vN3p9tSd1xbnL6+wTjZw05 1mlp69fPcDixwPClULtx4OIj97+6Kr5zvOy///elanGLCaYerd//Vn18Iq+zstOObfvpjxqX a/6uyY++2Op5m3eZabkSS3FGoqEWc1FxIgC2x2nJKAIAAA== Archived-At: Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:50:13 -0000 Thanks. As I see it the comments for the solution are: - Why cant we address the full leaf-list? Yes it would be good, but that is a separate proposal - Why don't we move netconf encoding to a separate document? Interesting idea, but not part of my proposal. - Clarifications regarrds Balazs On 2015-02-18 13:06, Juergen Schoenwaelder wrote: > Balazs, > > I added the new writeup as Y57-03 to the issue tracker. > > /js > > On Wed, Feb 11, 2015 at 02:33:20PM +0100, Balazs Lengyel wrote: >> Hello Juergen, >> I still have an outstanding action point to update the current proposal >> for non-unique-list. >> The only comment I have received was that for replace/merge we should have >> similar behavior as we have for lists: >> >> For merge and replace if the insert attribute is not present an existing >> leaf-list value shall not be moved. >> >> Here are my modifications to what can be found on the issue-list >> [1]http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58. >> >> I merged the two solutions, as they were not real alternatives; the second >> part about addressing by position, just built on the main part. >> >> regards Balazs >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 Tel: +36-1-437-7320 >> Mobile: +36-70-330-7909 email: [2]Balazs.Lengyel@ericsson.com >> >> References >> >> Visible links >> 1. http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58 >> 2. mailto:Balazs.Lengyel@ericsson.com >> Description >> --------------- >> >> In YANG 1.0 all values in a leaf-list MUST be unique. The proposal is to relax this in YANG 1.1. >> >> If the leaf-list is unique the handling does not change compared to YANG 1.0 >> >> A nonUnique leaf-list is still handled as a set of separate leafs as in YANG 1.0 >> New mechanism to handle all values of a leaf-list toghether are NOT introduced. >> >> If we have a leaf-list with nonUnique values in the datastore a value in the >> edit-config addresses the first such value in the datastore. >> This alternative is selected for simplicity. >> (Note: Alternatively it could address all such values in the datastore which >> would be simple for delete/remove, but strange for replace and merge. Merge should >> be additive but merging [a,a,a] with [a] would result in [a] which is not >> additive. It would be very strange for insert-after; we want to insert one value, but suddenly >> it can become multiple values.) >> >> >> Solution Y57-01 >> >> Change to section 3: >> >> leaf-list: Like the leaf node but defines a set of uniquely identifiable >> nodes rather than a single node. Each node has a value but no child nodes. >> >> change to >> >> leaf-list: Like the leaf node but defines a set of nodes rather than a >> single node. Each node has a value but no child nodes. >> >> Change to section 4.2.2.2: >> >> A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf. >> >> What does this mean? Does it mean that leaf-lists need to have unique leafs? Change to: >> >> A leaf-list is a sequence of leaf nodes. >> >> Remove from section 7.7: >> >> The values in a leaf-list MUST be unique. >> >> Add to section 7.7.2: >> >> unique-leaf-list cardinality 0..1 >> >> Add a level 3 section before 7.7.6: >> >> 7.7.5b The unique-leaf-list Statement >> >> The "unique-leaf-list" statement takes as an argument the string "true" or "false". >> If "unique-leaf-list" is "true", values within the leaf-lists must be unique. >> If "unique-leaf-list" is "false", values within the leaf-lists may be repeated. >> If "unique-leaf-list" is not specified, the default is true. >> >> Change section 7.7.7 >> >> The operations way of working is dependent on the value of unique-leaf-list. >> If unique-leaf-list is true the current handling is unchanged. >> If unique-leaf-list is false the following applies: >> >> delete/remove: delete/remove the addressed value (first occurence) from the >> leaf-list. If a value exists multiple times in edit-config try to >> delete 2/3/.. instances of the value. For delete it is an error if >> insufficient value instances exist in datastore. >> >> create: create value. It succeeds even if value already exists, just adds the >> value once more. If no "insert" attribute is present in the "create" operation, >> it defaults to "last". If a value exists multiple times in edit-config repeat >> the steps. >> >> replace, merge: For each specific value, the number of instances of the value >> in edit-config and the datastore are matched against each other. >> >> For each such value instance if insert is not specified the value in the datastore is left unchanged. >> >> If the insert is specified, delete the (first/matching) value in the datastore, if >> it exists, and re-create it as specified by >> insert. If the insert attribute refers to a value, it is the first occurrence >> of the value that is indicated. If a value exists multiple times in edit-config >> repeat the steps. >> >> If edit-config contains more instances, the additional ones are created as >> in a create operation. If the datastore contains more instances, they are not modified. >> >> ================================================================================================= >> >> >> >> >> Position can be used to select a leaf in a leaf-list, but only if it is "ordered-by user". >> For system-ordered lists this leads to error. (Same as insert) >> >> Position must be between 1 and the length of the leaf-list, if it is not, send an error message. >> Indexing starts at 1 not 0, following XPATH conventions. >> >> In a delete/remove operation if position is specified, the value of the leaf-instance, has no effect, >> it may be omitted by the client. (Addressing by position takes precedence over addressing by value.) >> >> If both the position and the value attributes are specified in edit-config for the same data node, >> the value attribute has no effect and may be (should be) ommitted by the client. >> >> If position is specified, the insert attribute can only take the values after and before. First >> and last are error. (There is no sense in specifying position once the insert=first/last is specified, >> it would just add one more useless and complicated case.) >> >> Further changes to section 7.7.9: >> >> In an "ordered-by user" leaf-list, the attribute "position" in the YANG XML namespace (Section 5.3.1) >> can be used to address specific values in the leaf-list. >> >> create: add: If position is specified but insert is not specified insert=after is implied. >> >> replace/merge: if position is specified but insert is not, replace the value specified by position. >> If both position and insert=after/before is specified, insert a new leaf with the value at the specified position. (replace/merge works differntly with and without position.) >> > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Feb 18 08:37:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BC61A8A03 for ; Wed, 18 Feb 2015 08:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 sOF25kpl8yBM for ; Wed, 18 Feb 2015 08:37:46 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27BB1A8A1E for ; Wed, 18 Feb 2015 08:37:45 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id f12so1545142qad.9 for ; Wed, 18 Feb 2015 08:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=4z6ENrgWtToiXg6ypT42B0ODEy15JONn/hdrD+AwsFw=; b=MOPJPAQViIBdWUMbBxUUoFNDGW4Xt87NYLQxdMKeyfhQMCnNqhzTlWy8y8aeYYGgJy MNL5QltC/rs915l4gke1ZBPlKbo+mLa/CSV8Tt4hginaVLTd/bPbsa1i1WOg7djZy+eU cntEsli/zjI5wQ9sqQhpZuh1BYgyp/NjyocPRjzKws9SsVwBdznuA86zAx8g3eLc0WI9 Mh2AQvRJ4AsHzch+zAQm5wUUHf0sSPF88fltwTIlM3wVGqcFb3+eKYe20WVRED2b+mpd VlwoRVWi5DN5O6FwrcPiNXnpL0gdbkosOMHGsBVn0TQmC3+jDzo/+WSoJPo9UdjecveU POgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=4z6ENrgWtToiXg6ypT42B0ODEy15JONn/hdrD+AwsFw=; b=VT/6S5t28bPtcNsiNxB3ZJH4XOTG9NM5UDECTnkRdFY07imFq48vTzdfMzaz/Uy4tN 9HCAB69gnCaBbbETXi+txPaCHoehs71duhaWk6lDa5tm+mDVhIO50Zyx0j5oc/1Lc3k9 xjTTr0zB9nYAlLMSz3B7z1g1gPAlGT+baQXzZXcKprD4uGLfbnN6k8GwSsscT5Oo/sBK Hi9tNpviwUIc9SZUZaxX/0Inh8TTyUdU80FGfM/lwDwoWxWL4s5w5tJuzpKyxl3VK4Tq BfMX0cMPSzvK7hxaLTAcifTxViqEtrZ1KPXAItBa2qVd8lSLBKGmpJJwjWKgr9kVUCAM Dyxw== X-Gm-Message-State: ALoCoQnbv12tMhsmIN46wEFZUQxFF8/MThDV/VZ16mghe+h+COrct9sZpuYXwBxm/GU+NA+n2Wr1 X-Received: by 10.140.148.216 with SMTP id 207mr2025142qhu.62.1424277464745; Wed, 18 Feb 2015 08:37:44 -0800 (PST) MIME-Version: 1.0 References: <54DB5A20.1030707@ericsson.com> <20150218120646.GA27531@elstar.local> <54E4A69D.9020908@ericsson.com> From: Anees Shaikh Date: Wed, 18 Feb 2015 16:37:44 +0000 Message-ID: To: Balazs Lengyel , Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113769d0593d31050f5f7037 Archived-At: Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 16:37:49 -0000 --001a113769d0593d31050f5f7037 Content-Type: text/plain; charset=UTF-8 I'd definitely support separation of YANG the data modeling language from NETCONF the management protocol. A document describing NETCONF encoding would help make the separation clear IMO (understanding this is not in scope for the current proposal). As a relative newcomer to authoring and consuming YANG models, I've run into limitations with YANG that seem to be motivated by NETCONF-related considerations, but it's hard to be sure without knowing all of the history. thanks. -- Anees On Wed Feb 18 2015 at 6:50:16 AM Balazs Lengyel wrote: > Thanks. > As I see it the comments for the solution are: > - Why cant we address the full leaf-list? Yes it would be good, but that > is a separate proposal > - Why don't we move netconf encoding to a separate document? Interesting > idea, but not part of my proposal. > - Clarifications > regarrds Balazs > > On 2015-02-18 13:06, Juergen Schoenwaelder wrote: > > Balazs, > > > > I added the new writeup as Y57-03 to the issue tracker. > > > > /js > > > > On Wed, Feb 11, 2015 at 02:33:20PM +0100, Balazs Lengyel wrote: > >> Hello Juergen, > >> I still have an outstanding action point to update the current > proposal > >> for non-unique-list. > >> The only comment I have received was that for replace/merge we > should have > >> similar behavior as we have for lists: > >> > >> For merge and replace if the insert attribute is not present an > existing > >> leaf-list value shall not be moved. > >> > >> Here are my modifications to what can be found on the issue-list > >> [1]http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues. > html#sec-58. > >> > >> I merged the two solutions, as they were not real alternatives; the > second > >> part about addressing by position, just built on the main part. > >> > >> regards Balazs > >> > >> -- > >> Balazs Lengyel Ericsson Hungary Ltd. > >> Senior Specialist > >> ECN: 831 7320 Tel: +36-1-437-7320 > >> Mobile: +36-70-330-7909 email: [2] > Balazs.Lengyel@ericsson.com > >> > >> References > >> > >> Visible links > >> 1. http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues. > html#sec-58 > >> 2. mailto:Balazs.Lengyel@ericsson.com > >> Description > >> --------------- > >> > >> In YANG 1.0 all values in a leaf-list MUST be unique. The proposal is > to relax this in YANG 1.1. > >> > >> If the leaf-list is unique the handling does not change compared to > YANG 1.0 > >> > >> A nonUnique leaf-list is still handled as a set of separate leafs as in > YANG 1.0 > >> New mechanism to handle all values of a leaf-list toghether are NOT > introduced. > >> > >> If we have a leaf-list with nonUnique values in the datastore a value > in the > >> edit-config addresses the first such value in the datastore. > >> This alternative is selected for simplicity. > >> (Note: Alternatively it could address all such values in the datastore > which > >> would be simple for delete/remove, but strange for replace and merge. > Merge should > >> be additive but merging [a,a,a] with [a] would result in [a] which is > not > >> additive. It would be very strange for insert-after; we want to insert > one value, but suddenly > >> it can become multiple values.) > >> > >> > >> Solution Y57-01 > >> > >> Change to section 3: > >> > >> leaf-list: Like the leaf node but defines a set of uniquely identifiable > >> nodes rather than a single node. Each node has a value but no child > nodes. > >> > >> change to > >> > >> leaf-list: Like the leaf node but defines a set of nodes rather than a > >> single node. Each node has a value but no child nodes. > >> > >> Change to section 4.2.2.2: > >> > >> A leaf-list is a sequence of leaf nodes with exactly one value of > a particular type per leaf. > >> > >> What does this mean? Does it mean that leaf-lists need to have unique > leafs? Change to: > >> > >> A leaf-list is a sequence of leaf nodes. > >> > >> Remove from section 7.7: > >> > >> The values in a leaf-list MUST be unique. > >> > >> Add to section 7.7.2: > >> > >> unique-leaf-list cardinality 0..1 > >> > >> Add a level 3 section before 7.7.6: > >> > >> 7.7.5b The unique-leaf-list Statement > >> > >> The "unique-leaf-list" statement takes as an argument the string > "true" or "false". > >> If "unique-leaf-list" is "true", values within the leaf-lists must > be unique. > >> If "unique-leaf-list" is "false", values within the leaf-lists may > be repeated. > >> If "unique-leaf-list" is not specified, the default is true. > >> > >> Change section 7.7.7 > >> > >> The operations way of working is dependent on the value of > unique-leaf-list. > >> If unique-leaf-list is true the current handling is unchanged. > >> If unique-leaf-list is false the following applies: > >> > >> delete/remove: delete/remove the addressed value (first occurence) > from the > >> leaf-list. If a value exists multiple times in edit-config try to > >> delete 2/3/.. instances of the value. For delete it is an error if > >> insufficient value instances exist in datastore. > >> > >> create: create value. It succeeds even if value already exists, > just adds the > >> value once more. If no "insert" attribute is present in the > "create" operation, > >> it defaults to "last". If a value exists multiple times in > edit-config repeat > >> the steps. > >> > >> replace, merge: For each specific value, the number of instances > of the value > >> in edit-config and the datastore are matched against each other. > >> > >> For each such value instance if insert is not specified the value > in the datastore is left unchanged. > >> > >> If the insert is specified, delete the (first/matching) value in > the datastore, if > >> it exists, and re-create it as specified by > >> insert. If the insert attribute refers to a value, it is the first > occurrence > >> of the value that is indicated. If a value exists multiple times > in edit-config > >> repeat the steps. > >> > >> If edit-config contains more instances, the additional ones are > created as > >> in a create operation. If the datastore contains more instances, > they are not modified. > >> > >> ============================================================ > ===================================== > >> > >> > >> > >> > >> Position can be used to select a leaf in a leaf-list, but only if it is > "ordered-by user". > >> For system-ordered lists this leads to error. (Same as insert) > >> > >> Position must be between 1 and the length of the leaf-list, if it is > not, send an error message. > >> Indexing starts at 1 not 0, following XPATH conventions. > >> > >> In a delete/remove operation if position is specified, the value of the > leaf-instance, has no effect, > >> it may be omitted by the client. (Addressing by position takes > precedence over addressing by value.) > >> > >> If both the position and the value attributes are specified in > edit-config for the same data node, > >> the value attribute has no effect and may be (should be) ommitted by > the client. > >> > >> If position is specified, the insert attribute can only take the values > after and before. First > >> and last are error. (There is no sense in specifying position once the > insert=first/last is specified, > >> it would just add one more useless and complicated case.) > >> > >> Further changes to section 7.7.9: > >> > >> In an "ordered-by user" leaf-list, the attribute "position" in the > YANG XML namespace (Section 5.3.1) > >> can be used to address specific values in the leaf-list. > >> > >> create: add: If position is specified but insert is not specified > insert=after is implied. > >> > >> replace/merge: if position is specified but insert is not, replace > the value specified by position. > >> If both position and insert=after/before is specified, insert a > new leaf with the value at the specified position. (replace/merge works > differntly with and without position.) > >> > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113769d0593d31050f5f7037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd definitely support separation of YANG the data mod= eling language from NETCONF the management protocol.=C2=A0 A document descr= ibing NETCONF encoding would help make the separation clear IMO (understand= ing this is not in scope for the current proposal). =C2=A0 As a relative ne= wcomer to authoring and consuming YANG models, I've run into limitation= s with YANG that seem to be motivated by NETCONF-related considerations, bu= t it's hard to be sure without knowing all of the history.

=
thanks.
-- Anees

On Wed Feb 18 2015 at 6:50:16 AM Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
=
Thanks.
As I see it the comments for the solution are:
- Why cant we address the full leaf-list? Yes it would be good, but that is a separate proposal
- Why don't we move netconf encoding to a separate document? Interestin= g
idea, but not part of my proposal.
- Clarifications
regarrds Balazs

On 2015-02-18 13:06, Juergen Schoenwaelder wrote:
> Balazs,
>
> I added the new writeup as Y57-03 to the issue tracker.
>
> /js
>
> On Wed, Feb 11, 2015 at 02:33:20PM +0100, Balazs Lengyel wrote:
>>=C2=A0 =C2=A0 =C2=A0Hello Juergen,
>>=C2=A0 =C2=A0 =C2=A0I still have an outstanding action point to upd= ate the current proposal
>>=C2=A0 =C2=A0 =C2=A0for non-unique-list.
>>=C2=A0 =C2=A0 =C2=A0The only comment I have received was that for r= eplace/merge we should have
>>=C2=A0 =C2=A0 =C2=A0similar behavior as we have for lists:
>>
>>=C2=A0 =C2=A0 =C2=A0For merge and replace if the insert attribute i= s not present an existing
>>=C2=A0 =C2=A0 =C2=A0leaf-list value shall not be moved.
>>
>>=C2=A0 =C2=A0 =C2=A0Here are my modifications to what can be found = on the issue-list
>>=C2=A0 =C2=A0 =C2=A0[1]http://svn.tools.ietf= .org/svn/wg/netmod/yang-1.1/issues.html#sec-58.
>>
>>=C2=A0 =C2=A0 =C2=A0I merged the two solutions, as they were not re= al alternatives; the second
>>=C2=A0 =C2=A0 =C2=A0part about addressing by position, just built o= n the main part.
>>
>>=C2=A0 =C2=A0 =C2=A0regards Balazs
>>
>>=C2=A0 =C2=A0--
>>=C2=A0 =C2=A0Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.
>>=C2=A0 =C2=A0Senior Specialist
>>=C2=A0 =C2=A0ECN: 831 7320=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tel: +36-1-437-7320
>>=C2=A0 =C2=A0Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 email: [2]Balazs.Lengyel@ericsson.com
>>
>> References
>>
>>=C2=A0 =C2=A0 =C2=A0Visible links
>>=C2=A0 =C2=A0 =C2=A01. http://svn.tools.ietf= .org/svn/wg/netmod/yang-1.1/issues.html#sec-58
>>=C2=A0 =C2=A0 =C2=A02. mailto:Balazs.Lengyel@ericsson.com
>> Description
>> ---------------
>>
>> In YANG 1.0 all values in a leaf-list MUST be unique. The proposal= is to relax this in YANG 1.1.
>>
>> If the leaf-list is unique the handling does not change compared t= o YANG 1.0
>>
>> A nonUnique leaf-list is still handled as a set of separate leafs = as in YANG 1.0
>> New mechanism to handle all values of a leaf-list toghether are NO= T introduced.
>>
>> If we have a leaf-list with nonUnique values in the datastore a va= lue in the
>> edit-config addresses the first such value in the datastore.
>> This alternative is selected for simplicity.
>> (Note: Alternatively it could address all such values in the datas= tore which
>> would be simple for delete/remove, but strange for replace and mer= ge. Merge should
>> be additive but merging [a,a,a] with [a] would result in [a] which= is not
>> additive. It would be very strange for insert-after; we want to in= sert one value, but suddenly
>> it can become multiple values.)
>>
>>
>> Solution Y57-01
>>
>>=C2=A0 =C2=A0 =C2=A0 Change to section 3:
>>
>> leaf-list: Like the leaf node but defines a set of uniquely identi= fiable
>> nodes rather than a single node. Each node has a value but no chil= d nodes.
>>
>> change to
>>
>> leaf-list: Like the leaf node but defines a set of nodes rather th= an a
>> single node. Each node has a value but no child nodes.
>>
>>=C2=A0 =C2=A0 =C2=A0 Change to section 4.2.2.2:
>>
>>=C2=A0 =C2=A0 =C2=A0 A leaf-list is a sequence of leaf nodes with e= xactly one value of a particular type per leaf.
>>
>> What does this mean? Does it mean that leaf-lists need to have uni= que leafs? Change to:
>>
>> A leaf-list is a sequence of leaf nodes.
>>
>>=C2=A0 =C2=A0 =C2=A0 Remove from section 7.7:
>>
>>=C2=A0 =C2=A0 =C2=A0 The values in a leaf-list MUST be unique.
>>
>>=C2=A0 =C2=A0 =C2=A0 Add to section 7.7.2:
>>
>>=C2=A0 =C2=A0 =C2=A0 unique-leaf-list cardinality 0..1
>>
>>=C2=A0 =C2=A0 =C2=A0 Add a level 3 section before 7.7.6:
>>
>>=C2=A0 =C2=A0 =C2=A0 7.7.5b The unique-leaf-list Statement
>>
>>=C2=A0 =C2=A0 =C2=A0 The "unique-leaf-list" statement tak= es as an argument the string "true" or "false".
>>=C2=A0 =C2=A0 =C2=A0 If "unique-leaf-list" is "true&= quot;, values within the leaf-lists must be unique.
>>=C2=A0 =C2=A0 =C2=A0 If "unique-leaf-list" is "false= ", values within the leaf-lists may be repeated.
>>=C2=A0 =C2=A0 =C2=A0 If "unique-leaf-list" is not specifi= ed, the default is true.
>>
>>=C2=A0 =C2=A0 =C2=A0 Change section 7.7.7
>>
>>=C2=A0 =C2=A0 =C2=A0 The operations way of working is dependent on = the value of unique-leaf-list.
>>=C2=A0 =C2=A0 =C2=A0 If unique-leaf-list is true the current handli= ng is unchanged.
>>=C2=A0 =C2=A0 =C2=A0 If unique-leaf-list is false the following app= lies:
>>
>>=C2=A0 =C2=A0 =C2=A0 delete/remove: delete/remove the addressed val= ue (first occurence) from the
>>=C2=A0 =C2=A0 =C2=A0 leaf-list. If a value exists multiple times in= edit-config try to
>>=C2=A0 =C2=A0 =C2=A0 delete 2/3/.. instances of the value. For dele= te it is an error if
>>=C2=A0 =C2=A0 =C2=A0 insufficient value instances exist in datastor= e.
>>
>>=C2=A0 =C2=A0 =C2=A0 create: create value. It succeeds even if valu= e already exists, just adds the
>>=C2=A0 =C2=A0 =C2=A0 value once more. If no "insert" attr= ibute is present in the "create" operation,
>>=C2=A0 =C2=A0 =C2=A0 it defaults to "last". If a value ex= ists multiple times in edit-config repeat
>>=C2=A0 =C2=A0 =C2=A0 the steps.
>>
>>=C2=A0 =C2=A0 =C2=A0 replace, merge: For each specific value, the n= umber of instances of the value
>>=C2=A0 =C2=A0 =C2=A0 in edit-config and the datastore are matched a= gainst each other.
>>
>>=C2=A0 =C2=A0 =C2=A0 For each such value instance if insert is not = specified the value in the datastore is left unchanged.
>>
>>=C2=A0 =C2=A0 =C2=A0 If the insert is specified, delete the (first/= matching) value in the datastore, if
>>=C2=A0 =C2=A0 =C2=A0 it exists, and re-create it as specified by >>=C2=A0 =C2=A0 =C2=A0 insert. If the insert attribute refers to a va= lue, it is the first occurrence
>>=C2=A0 =C2=A0 =C2=A0 of the value that is indicated. If a value exi= sts multiple times in edit-config
>>=C2=A0 =C2=A0 =C2=A0 repeat the steps.
>>
>>=C2=A0 =C2=A0 =C2=A0 If edit-config contains more instances, the ad= ditional ones are created as
>>=C2=A0 =C2=A0 =C2=A0 in a create operation. If the datastore contai= ns more instances, they are not modified.
>>
>>=C2=A0 =C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>
>>
>>
>> Position can be used to select a leaf in a leaf-list, but only if = it is "ordered-by user".
>> For system-ordered lists this leads to error. (Same as insert)
>>
>> Position must be between 1 and the length of the leaf-list, if it = is not, send an error message.
>> Indexing starts at 1 not 0, following XPATH conventions.
>>
>> In a delete/remove operation if position is specified, the value o= f the leaf-instance, has no effect,
>> it may be omitted by the client. (Addressing by position takes pre= cedence over addressing by value.)
>>
>> If both the position and the value attributes are specified in edi= t-config for the same data node,
>> the value attribute has no effect and may be (should be) ommitted = by the client.
>>
>> If position is specified, the insert attribute can only take the v= alues after and before. First
>> and last are error. (There is no sense in specifying position once= the insert=3Dfirst/last is specified,
>> it would just add one more useless and complicated case.)
>>
>>=C2=A0 =C2=A0 =C2=A0 Further changes to section 7.7.9:
>>
>>=C2=A0 =C2=A0 =C2=A0 In an "ordered-by user" leaf-list, t= he attribute "position" in the YANG XML namespace (Section 5.3.1)=
>>=C2=A0 =C2=A0 =C2=A0 can be used to address specific values in the = leaf-list.
>>
>>=C2=A0 =C2=A0 =C2=A0 create: add: If position is specified but inse= rt is not specified insert=3Dafter is implied.
>>
>>=C2=A0 =C2=A0 =C2=A0 replace/merge: if position is specified but in= sert is not, replace the value specified by position.
>>=C2=A0 =C2=A0 =C2=A0 If both position and insert=3Dafter/before is = specified, insert a new leaf with the value at the specified position. (rep= lace/merge works differntly with and without position.)
>>
>

--
Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 Tel: +36-1-437-7320
Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ema= il: Balazs= .Lengyel@ericsson.com

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod
--001a113769d0593d31050f5f7037-- From nobody Wed Feb 18 08:40:59 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E169F1A8A54 for ; Wed, 18 Feb 2015 08:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ4Vd3Tv29LS for ; Wed, 18 Feb 2015 08:40:56 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA381A8A46 for ; Wed, 18 Feb 2015 08:40:56 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B9D828ED for ; Wed, 18 Feb 2015 17:40:54 +0100 (CET) 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 u4F8ArfFWBsy for ; Wed, 18 Feb 2015 17:40:52 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 18 Feb 2015 17:40:54 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D6D820036 for ; Wed, 18 Feb 2015 17:40:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fWQZt8luUnFg; Wed, 18 Feb 2015 17:40:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B8B620031; Wed, 18 Feb 2015 17:40:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7A63B3232ACD; Wed, 18 Feb 2015 17:40:53 +0100 (CET) Date: Wed, 18 Feb 2015 17:40:53 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150218164053.GA28365@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20150218092433.GA26863@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150218092433.GA26863@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] comments on draft-bjorklund-yang-conformance-problem-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2015 16:40:58 -0000 Section 3.3.2. refers to P6 which is not in the document, so I guess the reference is wrong. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 18 09:59:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9791A8A14 for ; Wed, 18 Feb 2015 09:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GJRQ1VjQnKB for ; Wed, 18 Feb 2015 09:59:41 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (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 E25F51A8AC9 for ; Wed, 18 Feb 2015 09:59:40 -0800 (PST) Received: by lbvn10 with SMTP id n10so2767170lbv.6 for ; Wed, 18 Feb 2015 09:59:39 -0800 (PST) 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:content-type; bh=lAmYTA4B7HGG/b3KBwJRFa2LpQmWIRMiOwVKB+SLGR0=; b=PImMlZZYla0As9QtQk4tvqToqbONTxNH3WTi1vpqSpC3wluqbvsv3xlu09MkJ94yhI simBgAParPIh6qML0VLTMF8Enyl6PgkiRKtp6orUmfClbr3xuPFAilxnP+riRrXnqvcb /OpfvSMBB6O+rQjTfY3eHoCcJydSw3w5FFrv3a3W/slUdC4hH8URjvQwwinU32MWFJ6L 1WYGsIQtp51oOmtkY+0xnva18HA45Bdvyom3cPWNQacMJ69Ini1OjJ9U7alprx4MJq43 mAhjCfgbZTvNdfjLDO0gxsudzbIx3RoSnDYuZnWcLTimISqJuJyJy8D/VLYUiM85nNim +lVA== X-Gm-Message-State: ALoCoQlIo6mPvISZMRQosAyhSRuvePNDq1cYvSS2J1SQIxDSxjP2sRgS7WwHR1QKvXJNqW6LrpFp MIME-Version: 1.0 X-Received: by 10.152.87.50 with SMTP id u18mr542529laz.82.1424282379396; Wed, 18 Feb 2015 09:59:39 -0800 (PST) Received: by 10.112.78.3 with HTTP; Wed, 18 Feb 2015 09:59:39 -0800 (PST) In-Reply-To: <20150218111633.GA27312@elstar.local> References: <20150218111633.GA27312@elstar.local> Date: Wed, 18 Feb 2015 09:59:39 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] comments on draft-bierman-netmod-yang-conformance-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 17:59:43 -0000 On Wed, Feb 18, 2015 at 3:16 AM, Juergen Schoenwaelder wrote: > Hi, > > this is very valuable input to the conformance issue discussion. There > is likely useful terminology in section 1.1.3 as well. > > - Typedef drift vs. grouping drift: I think typedef drift can be > handled partially. A module update can narrow the value space to an > earlier version of a meanwhile expanded typedef. For groupings, we > do not have a mechanism to do the same. If a grouping got expanded > but a module wants to continue to use the unexpanded definition, > there does not seem to be a way to do this. Options: (i) do not > allow groupings to change, (ii) enhance the uses statement so it can > 'subset' a grouping, (iii) enhance the uses statement so that it can > refer to a specific version of a grouping (which however we do not > do for typedefs). I am concerned that we try to isolate the problems and produce a partial solution, but the actual YANG usage in the wild will not fit the isolated cases. There will be complex combinations of the typdef, grouping, augment, and cross-reference problems. Here are some high-level issues that should be considered: - Each update rule in RFC 6020 sec. 10 should be examined wrt/ its impact on conformance. They are tightly coupled. - Conformance for protocol-accessible objects and other importable statements are different. Combining PA objects and reusable statements in the same module is common, so the conformance should adapt instead of forcing designers to create separate modules - The use-cases for updating a module should be examined wrt/ conformance focusing on typedef, grouping, and augment. Type 1) Corrections: Defects or omissions are being addressed. Do not change the name, but all implementations of previous versions may need to be updated. Type 2) New functionality: This type of change should correlate to a change in the thing being modeled. If that thing is identified with a new version, (e.g, SSHv1 SSHv2) then new typedefs and groupings SHOULD be defined reflecting the new names. (This SHOULD can be raised to a MUST for IETF modules via YANG guidelines). > > /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 Feb 18 12:47:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108A41A1A54 for ; Wed, 18 Feb 2015 12:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jDFDeGqxDIQ for ; Wed, 18 Feb 2015 12:47:23 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 81AEB1A1AA8 for ; Wed, 18 Feb 2015 12:47:08 -0800 (PST) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 8268F1280052 for ; Wed, 18 Feb 2015 21:47:07 +0100 (CET) Date: Wed, 18 Feb 2015 21:46:49 +0100 (CET) Message-Id: <20150218.214649.1028966689268982661.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Feb_18_21_46_49_2015_143)--" Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Fw: New Version Notification for draft-bjorklund-yang-conformance-problem-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 20:47:25 -0000 ----Next_Part(Wed_Feb_18_21_46_49_2015_143)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have updated this draft after the ML and VM discussions today. I have not added anything about a "module compliance"-like solution. I think such a solution is mostly orthogonal to the issues described in this draft; it seems more like a replacement for the "feature/if-feature" statements. But it would be very useful if someone could describe such a solution! /martin ----Next_Part(Wed_Feb_18_21_46_49_2015_143)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on serenity.tail-f.com X-Spam-Level: X-Spam-Status: No, score=-104.8 required=5.0 tests=BAYES_00, DNS_FROM_AHBL_RHSBL,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, RP_MATCHES_RCVD,SPF_PASS,USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.0 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mail.tail-f.com (Postfix) with ESMTPS id D7AEF1280052 for ; Wed, 18 Feb 2015 21:42:58 +0100 (CET) Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640751A0387 for ; Wed, 18 Feb 2015 12:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.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 KEEmykeMm_Er for ; Wed, 18 Feb 2015 12:42:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CACF01A1A2C; Wed, 18 Feb 2015 12:42:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Martin Bjorklund" , "Martin Bjorklund" Subject: New Version Notification for draft-bjorklund-yang-conformance-problem-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218204253.27329.20438.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 12:42:53 -0800 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 int cnt prob spamicity histogram 0.00 53 0.019074 0.017870 ################################################ 0.10 4 0.113791 0.025813 #### 0.20 0 0.000000 0.025813 0.30 0 0.000000 0.025813 0.40 0 0.000000 0.025813 0.50 0 0.000000 0.025813 0.60 0 0.000000 0.025813 0.70 0 0.000000 0.025813 0.80 0 0.000000 0.025813 0.90 0 0.000000 0.025813 A new version of I-D, draft-bjorklund-yang-conformance-problem-01.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Name: draft-bjorklund-yang-conformance-problem Revision: 01 Title: The YANG Conformance Problem Document date: 2015-02-18 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-bjorklund-yang-conformance-problem-01.txt Status: https://datatracker.ietf.org/doc/draft-bjorklund-yang-conformance-problem/ Htmlized: http://tools.ietf.org/html/draft-bjorklund-yang-conformance-problem-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-bjorklund-yang-conformance-problem-01 Abstract: This document describes the YANG conformance problem. It is intended as a temporary document to help the NETMOD WG in the design of YANG 1.1. 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 ----Next_Part(Wed_Feb_18_21_46_49_2015_143)---- From nobody Fri Feb 20 06:03:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312501A86DE for ; Fri, 20 Feb 2015 06:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAAJCcn-cuoq for ; Fri, 20 Feb 2015 06:03:12 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::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 CBB621A8549 for ; Fri, 20 Feb 2015 06:03:11 -0800 (PST) Received: by wesk11 with SMTP id k11so5736739wes.11 for ; Fri, 20 Feb 2015 06:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l6lykuGQFmkFSsYQ5b92JgbmWlrNqF4hhMUimDyocSo=; b=lFxfpg9BBhuqjQtMYb/rybV/nsXCDp3ZohggvsB8BcTZdjoxUgALUvzusPHV6RKLSE 4aQVVOOyEEZHSq27WHzLD8iTakKT8TohgqMlv/gU7WPPUQA1MFm/fATSP3G8674g7+W2 MBQgLzp6oOko+sU4GSbxsuLKYdrUjFjshVl90wYbkdvBLB5JHw3eiTVE83UcAIimOP48 OqQT1FFfvBtkhShr6slh+sPg8PFyuuBzO2Dcy5REwexagOySYPtxzR968Moo2l53AD5m RPX0kO3WtGs22jUNZIO1j1xJru2rgSYj1INEDZ87U2HyGgBWi2hUnQvg8w0A7qWcVL7F BlCg== X-Received: by 10.194.158.234 with SMTP id wx10mr19561216wjb.23.1424440990215; Fri, 20 Feb 2015 06:03:10 -0800 (PST) Received: from host-2003-1c09-0021-0d00-18eb-7eb0-8c41-732f.1c09-h.de.terastrm.net (host-2003-1c09-0021-0d00-18eb-7eb0-8c41-732f.1c09-h.de.terastrm.net. [2003:1c09:21:d00:18eb:7eb0:8c41:732f]) by mx.google.com with ESMTPSA id e18sm42214173wjz.27.2015.02.20.06.03.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Feb 2015 06:03:09 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Qi Sun In-Reply-To: <20150218.214649.1028966689268982661.mbj@tail-f.com> Date: Fri, 20 Feb 2015 15:03:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88538B12-F4D5-4DA5-B21B-37455E7618E8@gmail.com> References: <20150218.214649.1028966689268982661.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1874) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] New Version Notification for draft-bjorklund-yang-conformance-problem-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 14:03:14 -0000 Hi Martin,=20 I=92ve read this draft and have some (minor) language related comments. = (Maybe because I=92m a non-English speaker.) 3.2.1. Solution P1a-01 Fix the type and grouping when using import-by revision. In this case, it is clear what the types of leaf b and c are, and /b2/y is not supported, but /c2/y is. [Qi] I think =93Fix the type and grouping when using import-by = revision.=94 means that =93When using import-by revision, the typedef = and grouping should be bound to that specific imported revision=94, = right? I mistakenly thought the word =93fix=94 had the same meaning as = in =93fix a bug=94. Isn=92t this the current practice? 3.4. Problem P2: Conformance Ambiguity =85. module mod-f { ... revision 2001-04-01; import mod-a { prefix a; revision-date 2001-01-01; // uses initial vsn of mod-e } augment /a:x { ... } } module mod-g { ... revision 2002-04-01; // uses new vsn of mod-e import mod-e { prefix e; revision-date 2002-01-01; } augment /e:y { ... } } [Qi] I think the intension here is to import =93mod-e=94 instead of = =93mod-a=94? And augment /e:x { =85 } ? The comment =93// uses new vsn of mod-e=94 should be placed 3 lines = down? 3.7.2. Solution P5-02 Do nothing. This is an educational issue. Make sure generic containers like this "system" do not require the implementation of many other nodes. [Qi] I suppose the wording here means: Make sure generic containers like this "system" do not contain many other nodes that = require to be implemented besides the augmented nodes if any. Hope it helps. Cheers, Qi On Feb 18, 2015, at 9:46 PM, Martin Bjorklund wrote: > Hi, >=20 > I have updated this draft after the ML and VM discussions today. >=20 > I have not added anything about a "module compliance"-like solution. > I think such a solution is mostly orthogonal to the issues described > in this draft; it seems more like a replacement for the > "feature/if-feature" statements. But it would be very useful if > someone could describe such a solution! >=20 >=20 > /martin >=20 >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-bjorklund-yang-conformance-problem-01.txt > Date: February 18, 2015 at 9:42:53 PM GMT+1 > To: "Martin Bjorklund" , "Martin Bjorklund" = >=20 >=20 >=20 > A new version of I-D, draft-bjorklund-yang-conformance-problem-01.txt > has been successfully submitted by Martin Bjorklund and posted to the > IETF repository. >=20 > Name: draft-bjorklund-yang-conformance-problem > Revision: 01 > Title: The YANG Conformance Problem > Document date: 2015-02-18 > Group: Individual Submission > Pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-bjorklund-yang-conformance-probl= em-01.txt > Status: = https://datatracker.ietf.org/doc/draft-bjorklund-yang-conformance-problem/= > Htmlized: = http://tools.ietf.org/html/draft-bjorklund-yang-conformance-problem-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-bjorklund-yang-conformance-proble= m-01 >=20 > Abstract: > This document describes the YANG conformance problem. It is = intended > as a temporary document to help the NETMOD WG in the design of YANG > 1.1. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 20 06:31:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64A11A8BB1 for ; Fri, 20 Feb 2015 06:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiDTGfb-lHiC for ; Fri, 20 Feb 2015 06:31:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49281A8BB3 for ; Fri, 20 Feb 2015 06:31:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 96D7AB1A for ; Fri, 20 Feb 2015 15:31:26 +0100 (CET) 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 b33a9kQPYNAb for ; Fri, 20 Feb 2015 15:31:11 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 20 Feb 2015 15:31:25 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5166120036 for ; Fri, 20 Feb 2015 15:31:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yF9HSRCQq357; Fri, 20 Feb 2015 15:31:24 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47B7F20031; Fri, 20 Feb 2015 15:31:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 735FB3233E3E; Fri, 20 Feb 2015 15:31:23 +0100 (CET) Date: Fri, 20 Feb 2015 15:31:23 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150220143123.GA35304@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [netmod] minutes of the NETMOD 2015-02-18 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2015 14:31:37 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the minutes of the 2015-02-18 virtual interim meeting. Please let me know if something needs fixing. You can find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2015-02-18-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 13th YANG 1.1 Virtual Interim Wednesday, February 18th, 2015, 16:00-18:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants: AB = Andy Bierman BL = Balasz Lengyel DR = Dan Romascanu IB = Ignas Bagdonas JS = Juergen Schoenwaelder KW = Kent Watsen MB = Martin Bjorklund * YANG 1.1 Conformance ** https://tools.ietf.org/html/draft-bjorklund-yang-conformance-problem-00 AB: Concerning A1, notifications are not required to implement if the server does not implement notifications in general. JS: Some wordsmithing of A1 might make this clearer. MB: A2 should be more precise that implements means implementing data nodes, rpcs, and notifications. AB: I am not sure about C1, if you need only a subset of a module and there is no handy feature for excluding the rest, there is a problem. MB: I believe C1 summarizes how things work today. AB: Are we trying to come up with tighter rules for humans or for tools to take advantage of the tighter rules? AB: I am not sure YANG 1.0 specifies C1 explicitly somewhere. JS: Does A3 not follow from A2? KW: A3 is more a corollary of A2. AB: The high-level problem is how to create and maintain the information needed to achieve A4. If it is too difficult to maintain and manage this information, things will not work in practice. AB: A4 is not the problem statement because we need to capture the maintenance problem. AB: Sometimes a robust solution is more verbose. Auto-numbering is an example where a fancy mechanisms makes things harder to use. MB: Perhaps we should not allow extensions of value spaces of typedefs (except identities that are extensible). MB: P1 is typedef-drift. JS: P1a-01 has the scope problem - if you want a new revision of a typedef, you have to implement the new revision everywhere. Similarly, if you need one updated type of inet-types, you have potentially to implement N other updates that come along with the new revision. MB: Question: If value space extension are problematic for typedefs, is it still OK to extend the value space of a leaf? I would say yes. JS: You might still break must constraints in other modules in this way. And for config false, things are very different. KW: In the netconf server configuration data model, almost everything is defined via groupings. If I can't extend them, things become problematic. AB: You can copy the groupings, may not look as nice. AB: Groupings are often written with a certain context in mind but then they can be used in very different contexts. MB: Another solution would be P1b-03 - typedefs never change. MB: P2 is showing that import-by-revision can lead to unresolvable conflicts requiring import updates (revision update ripple problem) AB: I think we should try to find a solution that avoids import-by-revision. MB: I agree. MB: Import by min revision does resolve this issue, but then it becomes unclear again which version of a typedef was used. JS: Import by min revision resolves P2, but then P1 is a problem again. To fix P1, you want import by exact revision, which then breaks P2 again. KW: Yes, and I can't cherry pick a single updated typedef from a module with N typedefs. MB: P3 is primarily about deprecated definitions, which then are optional to implement. JS: Interesting discussion what deprecated and obsolete means. BL: I think deprecated should mean "must still be implemented". KW: I think obsolete should mean "must not be implemented". KW: It would be nice if there would be an expire time associated with deprecated. JS: But you can already create warnings as soon as something is deprecated. Why do you need an expire time? KW: Other application maintainers may need to know that in order to plan they software update process. MB: I think we are talking about an automatic obsolete, i.e., if the timer expires, the definition moves from deprecated to obsolete. MB: P5 is about missing feature modularity BL: Perhaps the guideline here must be that you should not augment into something if that something is not essential to have; keep the tree flat. ** https://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-04 AB: I think we worked out that isolated problems can be solved, but the solutions do not work together. AB: Grouping drift is a major problem where I do not know how solve this (other than not allowing grouping changes) AB: We need to think about runtime solutions for certain things like identities. AB: I do not think that an implementation has to implement all identities derived from a common base. MB: I agree. AB: The runtime discoverable restrictions may also need to cover leafrefs. BL: But there are other restrictions that you can't describe. If I do not support 42 for uint8, then an attempt to configure 42 may simple fail with a runtime error. AB: We are at a situation where none of the solutions we have that would work do not look very appealing. MB: It seems import by revision does not help. MB: One option might be request via the guidelines that value set changes of typedefs or additions to groupings should not be done in the IETF. --+HP7ph2BbKc20aGI-- From nobody Fri Feb 20 13:57:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66ACC1A01BA for ; Fri, 20 Feb 2015 13:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SluB0erVtbxC for ; Fri, 20 Feb 2015 13:57:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DC4231A016C for ; Fri, 20 Feb 2015 13:57:53 -0800 (PST) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 28CDC1280AC6; Fri, 20 Feb 2015 22:57:52 +0100 (CET) Date: Fri, 20 Feb 2015 22:57:49 +0100 (CET) Message-Id: <20150220.225749.1925568344910786956.mbj@tail-f.com> To: sunqi.csnet.thu@gmail.com From: Martin Bjorklund In-Reply-To: <88538B12-F4D5-4DA5-B21B-37455E7618E8@gmail.com> References: <20150218.214649.1028966689268982661.mbj@tail-f.com> <88538B12-F4D5-4DA5-B21B-37455E7618E8@gmail.com> 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] New Version Notification for draft-bjorklund-yang-conformance-problem-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 21:57:56 -0000 UWkgU3VuIDxzdW5xaS5jc25ldC50aHVAZ21haWwuY29tPiB3cm90ZToNCj4gSGkgTWFydGluLCAN Cj4gDQo+IEnigJl2ZSByZWFkIHRoaXMgZHJhZnQgYW5kIGhhdmUgc29tZSAobWlub3IpIGxhbmd1 YWdlIHJlbGF0ZWQNCj4gY29tbWVudHMuIChNYXliZSBiZWNhdXNlIEnigJltIGEgbm9uLUVuZ2xp c2ggc3BlYWtlci4pDQo+IA0KPiAzLjIuMS4gU29sdXRpb24gUDFhLTAxDQo+IA0KPiAgIEZpeCB0 aGUgdHlwZSBhbmQgZ3JvdXBpbmcgd2hlbiB1c2luZyBpbXBvcnQtYnkgcmV2aXNpb24uICBJbiB0 aGlzDQo+ICAgY2FzZSwgaXQgaXMgY2xlYXIgd2hhdCB0aGUgdHlwZXMgb2YgbGVhZiBiIGFuZCBj IGFyZSwgYW5kIC9iMi95IGlzDQo+ICAgbm90IHN1cHBvcnRlZCwgYnV0IC9jMi95IGlzLg0KPiAN Cj4gW1FpXSBJIHRoaW5rIOKAnEZpeCB0aGUgdHlwZSBhbmQgZ3JvdXBpbmcgd2hlbiB1c2luZyBp bXBvcnQtYnkNCj4gcmV2aXNpb24u4oCdIG1lYW5zIHRoYXQg4oCcV2hlbiB1c2luZyBpbXBvcnQt YnkgcmV2aXNpb24sIHRoZSB0eXBlZGVmIGFuZA0KPiBncm91cGluZyBzaG91bGQgYmUgYm91bmQg dG8gdGhhdCBzcGVjaWZpYyBpbXBvcnRlZCByZXZpc2lvbuKAnSwgcmlnaHQ/DQoNClllcyB5b3Un cmUgcmlnaHQuICBCYWQgd29yZGluZy4NCg0KPiBJDQo+IG1pc3Rha2VubHkgdGhvdWdodCB0aGUg d29yZCDigJxmaXjigJ0gaGFkIHRoZSBzYW1lIG1lYW5pbmcgYXMgaW4g4oCcZml4IGENCj4gYnVn 4oCdLg0KPiANCj4gSXNu4oCZdCB0aGlzIHRoZSBjdXJyZW50IHByYWN0aWNlPw0KDQpOby4gIEkg dGhpbmsgaXQgZGlmZmVycyBhY3Jvc3MgaW1wbGVtZW50YXRpb25zLg0KDQoNCj4gMy40LiBQcm9i bGVtIFAyOiBDb25mb3JtYW5jZSBBbWJpZ3VpdHkNCj4g4oCmLg0KPiAgICAgbW9kdWxlIG1vZC1m IHsNCj4gICAgICAgLi4uDQo+ICAgICAgIHJldmlzaW9uIDIwMDEtMDQtMDE7DQo+ICAgICAgIGlt cG9ydCBtb2QtYSB7DQo+ICAgICAgICAgcHJlZml4IGE7DQo+ICAgICAgICAgcmV2aXNpb24tZGF0 ZSAyMDAxLTAxLTAxOyAgICAvLyB1c2VzIGluaXRpYWwgdnNuIG9mIG1vZC1lDQo+ICAgICAgIH0N Cj4gICAgICAgYXVnbWVudCAvYTp4IHsgLi4uIH0NCj4gICAgIH0NCj4gICAgICBtb2R1bGUgbW9k LWcgew0KPiAgICAgICAuLi4NCj4gICAgICAgcmV2aXNpb24gMjAwMi0wNC0wMTsgICAgICAgICAg Ly8gdXNlcyBuZXcgdnNuIG9mIG1vZC1lDQo+ICAgICAgIGltcG9ydCBtb2QtZSB7DQo+ICAgICAg ICAgcHJlZml4IGU7DQo+ICAgICAgICAgcmV2aXNpb24tZGF0ZSAyMDAyLTAxLTAxOw0KPiAgICAg ICB9DQo+ICAgICAgIGF1Z21lbnQgL2U6eSB7IC4uLiB9DQo+ICAgICB9DQo+IA0KPiBbUWldIEkg dGhpbmsgdGhlIGludGVuc2lvbiBoZXJlIGlzIHRvIGltcG9ydCDigJxtb2QtZeKAnSBpbnN0ZWFk IG9mDQo+IOKAnG1vZC1h4oCdPyBBbmQgYXVnbWVudCAvZTp4IHsg4oCmIH0gPw0KPiBUaGUgY29t bWVudCDigJwvLyB1c2VzIG5ldyB2c24gb2YgbW9kLWXigJ0gc2hvdWxkIGJlIHBsYWNlZCAzIGxp bmVzIGRvd24/DQoNClllcywgdGhpcyBpcyBhIHR5cG8uDQoNCg0KPiAzLjcuMi4gU29sdXRpb24g UDUtMDINCj4gDQo+ICAgIERvIG5vdGhpbmcuICBUaGlzIGlzIGFuIGVkdWNhdGlvbmFsIGlzc3Vl LiAgTWFrZSBzdXJlIGdlbmVyaWMNCj4gICBjb250YWluZXJzIGxpa2UgdGhpcyAic3lzdGVtIiBk byBub3QgcmVxdWlyZSB0aGUgaW1wbGVtZW50YXRpb24gb2YNCj4gICBtYW55IG90aGVyIG5vZGVz Lg0KPiANCj4gW1FpXSBJIHN1cHBvc2UgdGhlIHdvcmRpbmcgaGVyZSBtZWFuczogTWFrZSBzdXJl IGdlbmVyaWMNCj4gICBjb250YWluZXJzIGxpa2UgdGhpcyAic3lzdGVtIiBkbyBub3QgY29udGFp biBtYW55IG90aGVyIG5vZGVzIHRoYXQNCj4gICByZXF1aXJlDQo+ICAgdG8gYmUgaW1wbGVtZW50 ZWQgYmVzaWRlcyB0aGUgYXVnbWVudGVkIG5vZGVzIGlmIGFueS4NCg0KUmlnaHQuDQoNCj4gSG9w ZSBpdCBoZWxwcy4NCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KDQoNCg0KL21hcnRpbg0K DQoNCg0KPiBDaGVlcnMsDQo+IFFpDQo+IA0KPiBPbiBGZWIgMTgsIDIwMTUsIGF0IDk6NDYgUE0s IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90ZToNCj4gDQo+ID4gSGksDQo+ ID4gDQo+ID4gSSBoYXZlIHVwZGF0ZWQgdGhpcyBkcmFmdCBhZnRlciB0aGUgTUwgYW5kIFZNIGRp c2N1c3Npb25zIHRvZGF5Lg0KPiA+IA0KPiA+IEkgaGF2ZSBub3QgYWRkZWQgYW55dGhpbmcgYWJv dXQgYSAibW9kdWxlIGNvbXBsaWFuY2UiLWxpa2Ugc29sdXRpb24uDQo+ID4gSSB0aGluayBzdWNo IGEgc29sdXRpb24gaXMgbW9zdGx5IG9ydGhvZ29uYWwgdG8gdGhlIGlzc3VlcyBkZXNjcmliZWQN Cj4gPiBpbiB0aGlzIGRyYWZ0OyBpdCBzZWVtcyBtb3JlIGxpa2UgYSByZXBsYWNlbWVudCBmb3Ig dGhlDQo+ID4gImZlYXR1cmUvaWYtZmVhdHVyZSIgc3RhdGVtZW50cy4gIEJ1dCBpdCB3b3VsZCBi ZSB2ZXJ5IHVzZWZ1bCBpZg0KPiA+IHNvbWVvbmUgY291bGQgZGVzY3JpYmUgc3VjaCBhIHNvbHV0 aW9uIQ0KPiA+IA0KPiA+IA0KPiA+IC9tYXJ0aW4NCj4gPiANCj4gPiANCj4gPiBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQo+ID4gZHJhZnQtYmpvcmtsdW5kLXlhbmctY29uZm9ybWFuY2UtcHJvYmxlbS0wMS50 eHQNCj4gPiBEYXRlOiBGZWJydWFyeSAxOCwgMjAxNSBhdCA5OjQyOjUzIFBNIEdNVCsxDQo+ID4g VG86ICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb20+LCAiTWFydGluIEJqb3JrbHVu ZCINCj4gPiA8bWJqQHRhaWwtZi5jb20+DQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWJqb3JrbHVuZC15YW5nLWNvbmZvcm1hbmNlLXByb2JsZW0tMDEu dHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNYXJ0aW4gQmpvcmts dW5kIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4gSUVURiByZXBvc2l0b3J5Lg0KPiA+IA0KPiA+IE5h bWU6CQlkcmFmdC1iam9ya2x1bmQteWFuZy1jb25mb3JtYW5jZS1wcm9ibGVtDQo+ID4gUmV2aXNp b246CTAxDQo+ID4gVGl0bGU6CQlUaGUgWUFORyBDb25mb3JtYW5jZSBQcm9ibGVtDQo+ID4gRG9j dW1lbnQgZGF0ZToJMjAxNS0wMi0xOA0KPiA+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+ID4gUGFnZXM6CQkxMw0KPiA+IFVSTDoNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1iam9ya2x1bmQteWFuZy1jb25mb3JtYW5jZS1wcm9ibGVtLTAxLnR4 dA0KPiA+IFN0YXR1czoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1iam9ya2x1bmQteWFuZy1jb25mb3JtYW5jZS1wcm9ibGVtLw0KPiA+IEh0bWxpemVkOg0KPiA+ IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJqb3JrbHVuZC15YW5nLWNvbmZvcm1h bmNlLXByb2JsZW0tMDENCj4gPiBEaWZmOg0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWJqb3JrbHVuZC15YW5nLWNvbmZvcm1hbmNlLXByb2JsZW0tMDENCj4gPiAN Cj4gPiBBYnN0cmFjdDoNCj4gPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBZQU5HIGNv bmZvcm1hbmNlIHByb2JsZW0uICBJdCBpcyBpbnRlbmRlZA0KPiA+ICAgYXMgYSB0ZW1wb3Jhcnkg ZG9jdW1lbnQgdG8gaGVscCB0aGUgTkVUTU9EIFdHIGluIHRoZSBkZXNpZ24gb2YgWUFORw0KPiA+ ICAgMS4xLg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4gc3VibWlz c2lvbg0KPiA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4gDQo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4g PiANCj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCg== From nobody Fri Feb 20 23:35:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C871A1B81 for ; Fri, 20 Feb 2015 23:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yScNddRhTyRP for ; Fri, 20 Feb 2015 23:35:46 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D651A1B7E for ; Fri, 20 Feb 2015 23:35:45 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 401A9AC2 for ; Sat, 21 Feb 2015 08:35:44 +0100 (CET) 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 uA6wbhlNWK-V for ; Sat, 21 Feb 2015 08:35:25 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Sat, 21 Feb 2015 08:35:43 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8474020036 for ; Sat, 21 Feb 2015 08:35:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pQsObBnnpwXv; Sat, 21 Feb 2015 08:35:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9948020031; Sat, 21 Feb 2015 08:35:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 77DC032343C4; Sat, 21 Feb 2015 08:35:42 +0100 (CET) Date: Sat, 21 Feb 2015 08:35:42 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20150221073542.GA37839@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.4.2.3i Archived-At: Subject: [netmod] netmod / netconf meetings in dallas X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2015 07:35:49 -0000 Hi, the draft agenda [1] is out and NETMOD/NETCONF sessions are scheduled as follows: * Monday 2015-03-23 0900-1130 CDT NETMOD - Gold * Tuesday 2015-03-24 0900-1130 CDT NETMOD - Gold 1300-1500 CDT NETCONF - Gold Note that the agenda can still change. The final agenda will be published on Friday February 27th. /js [1] https://datatracker.ietf.org/meeting/92/agenda.html -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 23 06:46:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C40B1A0021 for ; Mon, 23 Feb 2015 06:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRDLlETZytOo for ; Mon, 23 Feb 2015 06:46:06 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BDB921A1AC6 for ; Mon, 23 Feb 2015 06:46:05 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2F6BC1CC0249; Mon, 23 Feb 2015 15:46:11 +0100 (CET) From: Ladislav Lhotka To: Per Hedeland , Andy Bierman , Juergen Schoenwaelder In-Reply-To: <54DE848B.1080701@tail-f.com> References: <20150213212033.GA54556@elstar.local> <54DE848B.1080701@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 23 Feb 2015 15:46:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:46:09 -0000 Per Hedeland writes: > On 2015-02-13 22:41, Andy Bierman wrote: >> On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder >> wrote: >>> Hi, >>> >>> Y25 (make enum numbering purely informative and optional) has been >>> discussed but no clear concensus has been reached so far. Y25-01 >>> proposes to remove the auto-numbering mechanism. With the appearance >>> of a CBOR encoding proposal [1], the numeric values may actually be >>> used on the wire. An alternative is to keep the auto-numbering >>> mechanism but to clarify the risks, this is what I have written up as >>> solution Y25-02: >>> >>> ** Solution Y25-02 >>> >>> Keep the auto-numbering procedure for enums and bits and add an >>> explicit warning that inserting enum definitions or reordering of >>> enum definitions very likely causes interoperability problem and >>> that explicit value assignments avoid this problem. >>> >>=20 >>=20 >> This is not really keeping the current procedure. >> Currently, the auto-numbering is mandatory, and sec 10. >> clearly prohibits changing any value or position statement. >>=20 >> IMO Y25 should be declared DEAD and the YANG 1.0 behavior >> not changed at all. > > +1 > >> You are proposing that Sec. 10 be changed so renumbering is >> a warning, not a violation of the standard. > > Yes - and this is IMO clearly a non-backwards compatible change. The > "backwards compatible" requirement is extremely loosely specified by the > charter, i.e. "All compliant YANG 1.0 modules must be accepted as > compliant YANG 1.1 modules" - which if taken literally would allow for > anything that completely changes the semantics of a 1.0 module, as long > as it is still "accepted as compliant" in 1.1. This is clearly not what > anyone expects - the semantics should be unchanged, at least as long as > the 1.0 semantics are not clearly broken / unimplementable etc. > > RFC 6020 makes the promise to implementations that enum values are > stable as long as section 10 is adhered to. The suggested change breaks > this promise, thus it should be considered non-backwards compatible. What promise are you talking about? It is the enum *string* that is being exchanged in the protocol(s), so, strictly speaking, in the context of RFC 6020 there is no way for a NETCONF/RESTCONF peer to tell whether any implementation uses the auto-allocated values or not. RFC 6020 also clearly says: "The value is unused by YANG and the XML encoding, ...". Of course, the situation changes if CBOR encoding chooses to use numeric values but I'd argue this wasn't the original intention, and so the motivation of the corresponding sec. 10 restriction remains unclear to me. > > The motivations for making any change at all are also very dubious: > > 1. "This rule makes updates of enumerations difficult" > > Disregarding that "difficult" is a very subjective judgement, what > exactly is difficult about it? The only example that I have seen on This has already been discussed several times. Consider an enumeration such= as ISO 3166 alpha-2 country codes: https://www.iso.org/obp/ui/#search It is sorted alphabetically, so new entries will most likely be added somewhere in the middle. This is impossible with auto-numbering, so currently the only solution would be to add a bogus number to each enum, which would make the module defining such an enumeration longer by 30=C2=A0% or so. What's your suggestion as to how such an enumeration should be set up and maintained? Lada > the mailing list is the infamous time zone case. This case revealed sever= al > problems: > > a) The specification of the auto numbering procedure was unclear. This > has been addressed by errata 3871. > > b) No-one wanted to assume the responsibility of maintaining a standard > module specifying the enums, probably in no small part due to > > c) The maintainers of the time zone data were clearly opposed to having > any part of it turned into any kind of standard, due to the (additional) > political controversy this could lead to. > > However no technical or practical difficulty in maintaining a module for > these enums that adheres to section 10 has been demonstrated. In fact > assuming the obvious, that such a module would be auto-generated from > some free-form data, whether the raw timezone data or a simple list > (without any requirement on ordering) of identifiers, it is a very > trivial problem to solve. Martin already offered to provide a piece of > software to do that, I can do the same, but of course this particular > case is now moot. > > In the more typical case of a handful of manually assigned enums, > maintaining the numbering can't reasonably be considered difficult. > > 2. "and/or forces the data modeller to assign the values explicitly even > if they have no meaning otherwise." > > The only case where a data modeller would be *forced* to assign values > is that of removing an enum other than the "last" one, without adding > another to take its place. As far as I can see, removing enums is > already ruled out by section 10, and not a candidate for change. > > But obviously there are cases where some specific order of the enums is > more "natural" than others, and adhering to that order is likely to > improve readability, which is an important goal. Even in such a case > there is no need to assign values in the original version of the module, > but it may be needed on update if it is desired to add an enum "in the > middle" - but this is not being *forced*. (And readability can only be > an actual concern if the total set of enums is small, and then again it > can't reasonably be considered difficult to maintain the values.) > > 3. "The rule also contradicts the statement in Sec. 9.6.4.2 because the > value in fact is used by YANG." > > I disagree, the statement in 9.6.4.2 is accurate - the values aren't > *used* by YANG. YANG mereley puts some restrictions on them and provides > them to implementations. But if someone really feels strongly about > this, the obvious fix is to the text as s/YANG and// - not changing the > semantics. > > --Per Hedeland > >> Andy >>=20 >>> The guidelines document may add further rules such that enum/bits >>> values must be explicitly defined in IETF modules (to be discussed >>> in the context of the guidelines document). >>> >>> [1] https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> _______________________________________________ >> 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 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Feb 23 14:54:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A3A1A0145 for ; Mon, 23 Feb 2015 14:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOB7ebYzVnlo for ; Mon, 23 Feb 2015 14:54:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B2A741A038C for ; Mon, 23 Feb 2015 14:54:31 -0800 (PST) Received: from pluto.hedeland.org (h194n2-hy-a32.ias.bredband.telia.com [81.228.176.194]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B20112801A6; Mon, 23 Feb 2015 23:54:30 +0100 (CET) Message-ID: <54EBAFA6.4050009@tail-f.com> Date: Mon, 23 Feb 2015 23:54:30 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ladislav Lhotka References: <20150213212033.GA54556@elstar.local> <54DE848B.1080701@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 22:54:38 -0000 On 2015-02-23 15:46, Ladislav Lhotka wrote: > Per Hedeland writes: > >> On 2015-02-13 22:41, Andy Bierman wrote: >>> On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder >>> wrote: >>>> Hi, >>>> >>>> Y25 (make enum numbering purely informative and optional) has been >>>> discussed but no clear concensus has been reached so far. Y25-01 >>>> proposes to remove the auto-numbering mechanism. With the appearance >>>> of a CBOR encoding proposal [1], the numeric values may actually be >>>> used on the wire. An alternative is to keep the auto-numbering >>>> mechanism but to clarify the risks, this is what I have written up as >>>> solution Y25-02: >>>> >>>> ** Solution Y25-02 >>>> >>>> Keep the auto-numbering procedure for enums and bits and add an >>>> explicit warning that inserting enum definitions or reordering of >>>> enum definitions very likely causes interoperability problem and >>>> that explicit value assignments avoid this problem. >>>> >>> >>> >>> This is not really keeping the current procedure. >>> Currently, the auto-numbering is mandatory, and sec 10. >>> clearly prohibits changing any value or position statement. >>> >>> IMO Y25 should be declared DEAD and the YANG 1.0 behavior >>> not changed at all. >> >> +1 >> >>> You are proposing that Sec. 10 be changed so renumbering is >>> a warning, not a violation of the standard. >> >> Yes - and this is IMO clearly a non-backwards compatible change. The >> "backwards compatible" requirement is extremely loosely specified by the >> charter, i.e. "All compliant YANG 1.0 modules must be accepted as >> compliant YANG 1.1 modules" - which if taken literally would allow for >> anything that completely changes the semantics of a 1.0 module, as long >> as it is still "accepted as compliant" in 1.1. This is clearly not what >> anyone expects - the semantics should be unchanged, at least as long as >> the 1.0 semantics are not clearly broken / unimplementable etc. >> >> RFC 6020 makes the promise to implementations that enum values are >> stable as long as section 10 is adhered to. The suggested change breaks >> this promise, thus it should be considered non-backwards compatible. > > What promise are you talking about? The auto-numbering procedure, together with the restriction in section 10, guarantees that every enum will have an associated integer value that doesn't change when the module is updated. > It is the enum *string* that is being > exchanged in the protocol(s), so, strictly speaking, in the context of RFC > 6020 there is no way for a NETCONF/RESTCONF peer to tell whether any > implementation uses the auto-allocated values or not. Yes, this is not a protocol issue (yet), but ... > RFC 6020 also clearly says: "The value is unused by YANG and the XML > encoding, ...". ... it goes on to say "... but is carried as a convenience to implementors." I.e. being a "convenience to implementors" is the purpose of the auto-numbering scheme and the section 10 restriction. > Of course, the situation changes if CBOR encoding chooses to use numeric > values but I'd argue this wasn't the original intention, Agreed. > and so the > motivation of the corresponding sec. 10 restriction remains unclear to > me. See above. >> The motivations for making any change at all are also very dubious: >> >> 1. "This rule makes updates of enumerations difficult" >> >> Disregarding that "difficult" is a very subjective judgement, what >> exactly is difficult about it? The only example that I have seen on > > This has already been discussed several times. Consider an enumeration such as > ISO 3166 alpha-2 country codes: > > https://www.iso.org/obp/ui/#search > > It is sorted alphabetically, so new entries will most likely be added > somewhere in the middle. This is impossible with auto-numbering, so > currently the only solution would be to add a bogus number to each enum, > which would make the module defining such an enumeration longer by 30 % > or so. This can hardly be a significant concern for such a module. > What's your suggestion as to how such an enumeration should be set up and > maintained? Same as for the time zone case, described below. If you are wondering about the implementation of the auto-generating piece of software, it is just a matter of parsing the previous version of the module to get the existing value assignments, and make use of that information when generating the new version. However, note that the message you are replying to, and specifically the commentary on Y25-02, was due to a misunderstanding of Juergen's proposal. Per subsequent messages, Y25-02 was not intended to suggest any changes to the auto-numbering scheme or the section 10 restriction. And thus I support that proposal, although I made some suggestions for a minor rewording. --Per > Lada > >> the mailing list is the infamous time zone case. This case revealed several >> problems: > > >> >> a) The specification of the auto numbering procedure was unclear. This >> has been addressed by errata 3871. >> >> b) No-one wanted to assume the responsibility of maintaining a standard >> module specifying the enums, probably in no small part due to >> >> c) The maintainers of the time zone data were clearly opposed to having >> any part of it turned into any kind of standard, due to the (additional) >> political controversy this could lead to. >> >> However no technical or practical difficulty in maintaining a module for >> these enums that adheres to section 10 has been demonstrated. In fact >> assuming the obvious, that such a module would be auto-generated from >> some free-form data, whether the raw timezone data or a simple list >> (without any requirement on ordering) of identifiers, it is a very >> trivial problem to solve. Martin already offered to provide a piece of >> software to do that, I can do the same, but of course this particular >> case is now moot. >> >> In the more typical case of a handful of manually assigned enums, >> maintaining the numbering can't reasonably be considered difficult. >> >> 2. "and/or forces the data modeller to assign the values explicitly even >> if they have no meaning otherwise." >> >> The only case where a data modeller would be *forced* to assign values >> is that of removing an enum other than the "last" one, without adding >> another to take its place. As far as I can see, removing enums is >> already ruled out by section 10, and not a candidate for change. >> >> But obviously there are cases where some specific order of the enums is >> more "natural" than others, and adhering to that order is likely to >> improve readability, which is an important goal. Even in such a case >> there is no need to assign values in the original version of the module, >> but it may be needed on update if it is desired to add an enum "in the >> middle" - but this is not being *forced*. (And readability can only be >> an actual concern if the total set of enums is small, and then again it >> can't reasonably be considered difficult to maintain the values.) >> >> 3. "The rule also contradicts the statement in Sec. 9.6.4.2 because the >> value in fact is used by YANG." >> >> I disagree, the statement in 9.6.4.2 is accurate - the values aren't >> *used* by YANG. YANG mereley puts some restrictions on them and provides >> them to implementations. But if someone really feels strongly about >> this, the obvious fix is to the text as s/YANG and// - not changing the >> semantics. >> >> --Per Hedeland >> >>> Andy >>> >>>> The guidelines document may add further rules such that enum/bits >>>> values must be explicitly defined in IETF modules (to be discussed >>>> in the context of the guidelines document). >>>> >>>> [1] https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Feb 24 04:42:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49021A87A9 for ; Tue, 24 Feb 2015 04:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo2zFezirQND for ; Tue, 24 Feb 2015 04:42:54 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567BC1A8790 for ; Tue, 24 Feb 2015 04:42:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 26048A9B; Tue, 24 Feb 2015 13:42:53 +0100 (CET) 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 c4B0e5Lzbi5n; Tue, 24 Feb 2015 13:42:45 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Feb 2015 13:42:52 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7995820036; Tue, 24 Feb 2015 13:42:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zhmJTZbgaRYN; Tue, 24 Feb 2015 13:42:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 231DD20031; Tue, 24 Feb 2015 13:42:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C29383236C13; Tue, 24 Feb 2015 13:42:49 +0100 (CET) Date: Tue, 24 Feb 2015 13:42:49 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20150224124249.GA170@elstar.local> Mail-Followup-To: Phil Shafer , netmod@ietf.org References: <20150213204153.GA53713@elstar.local> <201502162140.t1GLeW1g050451@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201502162140.t1GLeW1g050451@idle.juniper.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement (2nd try) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2015 12:42:55 -0000 On Mon, Feb 16, 2015 at 04:40:32PM -0500, Phil Shafer wrote: > Juergen Schoenwaelder writes: > > - Introduce a new 'anydata' statement that represents an unknown > > chunk of data that can be modeled with YANG. > > I'd be opposed to introducing anydata. It's a bit too much like > introducing a hole into the model. Sure, the server assumably knows > what's there, but it's still a new feature. The current charter > says: > > - YANG 1.1 is not adding fundamentally new data modeling concepts to the language. > I do not buy this argument. Y34 is addressing issues that have surfaced with the usage of anyxml. Since we can't simple change the semantics of anyxml (for backwards compatibility reasons), the obvious solution is to create a replacement for the situations where "any data that can be defined in YANG is needed" and to discourage the usage of anyxml. /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 Feb 24 04:48:56 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC9F1A1A6C for ; Tue, 24 Feb 2015 04:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 666hVH1ZtX-D for ; Tue, 24 Feb 2015 04:48:53 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B991A87C4 for ; Tue, 24 Feb 2015 04:48:48 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 085A0AC4; Tue, 24 Feb 2015 13:48:47 +0100 (CET) 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 72ONet_cdZi5; Tue, 24 Feb 2015 13:48:38 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Feb 2015 13:48:46 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 166C220031; Tue, 24 Feb 2015 13:48:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V6jNPfcBImsY; Tue, 24 Feb 2015 13:48:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E68C20037; Tue, 24 Feb 2015 13:48:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 374C73236C9B; Tue, 24 Feb 2015 13:48:42 +0100 (CET) Date: Tue, 24 Feb 2015 13:48:42 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150224124840.GB170@elstar.local> Mail-Followup-To: Andy Bierman , Phil Shafer , "netmod@ietf.org" References: <20150213204153.GA53713@elstar.local> <201502162140.t1GLeW1g050451@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement (2nd try) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2015 12:48:55 -0000 On Mon, Feb 16, 2015 at 04:08:59PM -0800, Andy Bierman wrote: > On Mon, Feb 16, 2015 at 1:40 PM, Phil Shafer wrote: > > Juergen Schoenwaelder writes: > >> - Introduce a new 'anydata' statement that represents an unknown > >> chunk of data that can be modeled with YANG. > > > > I'd be opposed to introducing anydata. It's a bit too much like > > introducing a hole into the model. Sure, the server assumably knows > > what's there, but it's still a new feature. The current charter > > says: > > > > - YANG 1.1 is not adding fundamentally new data modeling concepts to the language. > > > > The problem with anydata is that it is a generic attempt to fix all uses > of anyxml. > > Each of the anyxml use-cases in RFCs and I-Ds is really a > poor man's substitutionGroup macro (from XSD), or a node > acting as the root for top-level YANG data nodes. > > Using anydata as a free-form hole in the datastore is a bad idea. > Introducing anydata seems to require a server to support this, > as well as support mixed mode XML (since anyxml is still current, > and that seems to be the only difference from anydata). > > IMO Y34 is in scope because anyxml is not being used as a leaf > holding a blob of HTML, as envisioned by the WG when RFC 6020 > was written. The solution might make the problem worse, not better. > IMO a solution that addresses the 2 actual use-cases for anyxml > is needed. I am not sure I understand the '2 actual use-cases' (or why there are only two). Anyway, you need to writeup a proper solution proposal if you think the one we so far agreed on (Y34-05) is fundamentally flawed. And it might help if you can explain more precisely why anydata will be worse than having anyxml. /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 Feb 24 04:49:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95DB1A1A6C for ; Tue, 24 Feb 2015 04:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgNwDtiZolVN for ; Tue, 24 Feb 2015 04:49:14 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id ADDFD1A1A67 for ; Tue, 24 Feb 2015 04:49:13 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 9D65F1CC0155; Tue, 24 Feb 2015 13:49:20 +0100 (CET) From: Ladislav Lhotka To: Per Hedeland In-Reply-To: <54EBAFA6.4050009@tail-f.com> References: <20150213212033.GA54556@elstar.local> <54DE848B.1080701@tail-f.com> <54EBAFA6.4050009@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 24 Feb 2015 13:49:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 12:49:17 -0000 Per Hedeland writes: > On 2015-02-23 15:46, Ladislav Lhotka wrote: >> Per Hedeland writes: >> >>> On 2015-02-13 22:41, Andy Bierman wrote: >>>> On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder >>>> wrote: >>>>> Hi, >>>>> >>>>> Y25 (make enum numbering purely informative and optional) has been >>>>> discussed but no clear concensus has been reached so far. Y25-01 >>>>> proposes to remove the auto-numbering mechanism. With the appearance >>>>> of a CBOR encoding proposal [1], the numeric values may actually be >>>>> used on the wire. An alternative is to keep the auto-numbering >>>>> mechanism but to clarify the risks, this is what I have written up as >>>>> solution Y25-02: >>>>> >>>>> ** Solution Y25-02 >>>>> >>>>> Keep the auto-numbering procedure for enums and bits and add an >>>>> explicit warning that inserting enum definitions or reordering of >>>>> enum definitions very likely causes interoperability problem and >>>>> that explicit value assignments avoid this problem. >>>>> >>>> >>>> >>>> This is not really keeping the current procedure. >>>> Currently, the auto-numbering is mandatory, and sec 10. >>>> clearly prohibits changing any value or position statement. >>>> >>>> IMO Y25 should be declared DEAD and the YANG 1.0 behavior >>>> not changed at all. >>> >>> +1 >>> >>>> You are proposing that Sec. 10 be changed so renumbering is >>>> a warning, not a violation of the standard. >>> >>> Yes - and this is IMO clearly a non-backwards compatible change. The >>> "backwards compatible" requirement is extremely loosely specified by the >>> charter, i.e. "All compliant YANG 1.0 modules must be accepted as >>> compliant YANG 1.1 modules" - which if taken literally would allow for >>> anything that completely changes the semantics of a 1.0 module, as long >>> as it is still "accepted as compliant" in 1.1. This is clearly not what >>> anyone expects - the semantics should be unchanged, at least as long as >>> the 1.0 semantics are not clearly broken / unimplementable etc. >>> >>> RFC 6020 makes the promise to implementations that enum values are >>> stable as long as section 10 is adhered to. The suggested change breaks >>> this promise, thus it should be considered non-backwards compatible. >> >> What promise are you talking about? > > The auto-numbering procedure, together with the restriction in section > 10, guarantees that every enum will have an associated integer value > that doesn't change when the module is updated. > >> It is the enum *string* that is being >> exchanged in the protocol(s), so, strictly speaking, in the context of RFC >> 6020 there is no way for a NETCONF/RESTCONF peer to tell whether any >> implementation uses the auto-allocated values or not. > > Yes, this is not a protocol issue (yet), but ... And that's my point, it is neither a language nor a protocol issue, and therefore it doesn't belong to the specification. > >> RFC 6020 also clearly says: "The value is unused by YANG and the XML >> encoding, ...". > > ... it goes on to say "... but is carried as a convenience to > implementors." I.e. being a "convenience to implementors" is the purpose > of the auto-numbering scheme and the section 10 restriction. The real convenience is that implementors can choose whatever numbering they like (or no numbering at all), there is no need that the numbering be the same at the sending and receiving side. > >> Of course, the situation changes if CBOR encoding chooses to use numeric >> values but I'd argue this wasn't the original intention, > > Agreed. > >> and so the >> motivation of the corresponding sec. 10 restriction remains unclear to >> me. > > See above. > >>> The motivations for making any change at all are also very dubious: >>> >>> 1. "This rule makes updates of enumerations difficult" >>> >>> Disregarding that "difficult" is a very subjective judgement, what >>> exactly is difficult about it? The only example that I have seen on >> >> This has already been discussed several times. Consider an enumeration such as >> ISO 3166 alpha-2 country codes: >> >> https://www.iso.org/obp/ui/#search >> >> It is sorted alphabetically, so new entries will most likely be added >> somewhere in the middle. This is impossible with auto-numbering, so >> currently the only solution would be to add a bogus number to each enum, >> which would make the module defining such an enumeration longer by 30 % >> or so. > > This can hardly be a significant concern for such a module. > >> What's your suggestion as to how such an enumeration should be set up and >> maintained? > > Same as for the time zone case, described below. If you are wondering > about the implementation of the auto-generating piece of software, it is > just a matter of parsing the previous version of the module to get the > existing value assignments, and make use of that information when > generating the new version. Of course, but I have always assumed *human readability* of YANG modules has the highest priority. And if the numbers are bogus, then they just add noise. I simply don't agree the touted "convenience to implementors" outweighs the inconvenience to readers of such modules and maintainers. YANG wouldn't be less usable if the auto-numbering procedure was removed. > > However, note that the message you are replying to, and specifically the > commentary on Y25-02, was due to a misunderstanding of Juergen's > proposal. Per subsequent messages, Y25-02 was not intended to suggest > any changes to the auto-numbering scheme or the section 10 > restriction. > And thus I support that proposal, although I made some suggestions for > a minor rewording. I don't agree changes to values/positions can lead to interoperability problems - unless we take the COMI decision to use these numbers in the protocol for granted. Lada > > --Per > >> Lada >> >>> the mailing list is the infamous time zone case. This case revealed several >>> problems: >> >> >>> >>> a) The specification of the auto numbering procedure was unclear. This >>> has been addressed by errata 3871. >>> >>> b) No-one wanted to assume the responsibility of maintaining a standard >>> module specifying the enums, probably in no small part due to >>> >>> c) The maintainers of the time zone data were clearly opposed to having >>> any part of it turned into any kind of standard, due to the (additional) >>> political controversy this could lead to. >>> >>> However no technical or practical difficulty in maintaining a module for >>> these enums that adheres to section 10 has been demonstrated. In fact >>> assuming the obvious, that such a module would be auto-generated from >>> some free-form data, whether the raw timezone data or a simple list >>> (without any requirement on ordering) of identifiers, it is a very >>> trivial problem to solve. Martin already offered to provide a piece of >>> software to do that, I can do the same, but of course this particular >>> case is now moot. >>> >>> In the more typical case of a handful of manually assigned enums, >>> maintaining the numbering can't reasonably be considered difficult. >>> >>> 2. "and/or forces the data modeller to assign the values explicitly even >>> if they have no meaning otherwise." >>> >>> The only case where a data modeller would be *forced* to assign values >>> is that of removing an enum other than the "last" one, without adding >>> another to take its place. As far as I can see, removing enums is >>> already ruled out by section 10, and not a candidate for change. >>> >>> But obviously there are cases where some specific order of the enums is >>> more "natural" than others, and adhering to that order is likely to >>> improve readability, which is an important goal. Even in such a case >>> there is no need to assign values in the original version of the module, >>> but it may be needed on update if it is desired to add an enum "in the >>> middle" - but this is not being *forced*. (And readability can only be >>> an actual concern if the total set of enums is small, and then again it >>> can't reasonably be considered difficult to maintain the values.) >>> >>> 3. "The rule also contradicts the statement in Sec. 9.6.4.2 because the >>> value in fact is used by YANG." >>> >>> I disagree, the statement in 9.6.4.2 is accurate - the values aren't >>> *used* by YANG. YANG mereley puts some restrictions on them and provides >>> them to implementations. But if someone really feels strongly about >>> this, the obvious fix is to the text as s/YANG and// - not changing the >>> semantics. >>> >>> --Per Hedeland >>> >>>> Andy >>>> >>>>> The guidelines document may add further rules such that enum/bits >>>>> values must be explicitly defined in IETF modules (to be discussed >>>>> in the context of the guidelines document). >>>>> >>>>> [1] https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ >>>>> >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>> >>> _______________________________________________ >>> 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 Feb 24 06:38:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F3B1A0203 for ; Tue, 24 Feb 2015 06:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MiTCT3OhZ07 for ; Tue, 24 Feb 2015 06:38:01 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605661A1B64 for ; Tue, 24 Feb 2015 06:38:01 -0800 (PST) Received: from BY2PR05CA055.namprd05.prod.outlook.com (10.141.250.45) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.93.16; Tue, 24 Feb 2015 14:37:59 +0000 Received: from BY2FFO11FD020.protection.gbl (2a01:111:f400:7c0c::111) by BY2PR05CA055.outlook.office365.com (2a01:111:e400:2c5f::45) with Microsoft SMTP Server (TLS) id 15.1.93.16 via Frontend Transport; Tue, 24 Feb 2015 14:37:59 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BY2FFO11FD020.mail.protection.outlook.com (10.1.14.137) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Tue, 24 Feb 2015 14:37:58 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 24 Feb 2015 06:37:57 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1OEbuW62497; Tue, 24 Feb 2015 06:37:56 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t1OEbgLZ010318; Tue, 24 Feb 2015 09:37:42 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502241437.t1OEbgLZ010318@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20150224124249.GA170@elstar.local> Date: Tue, 24 Feb 2015 09:37:42 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(50986999)(76506005)(87936001)(62966003)(47776003)(64706001)(77156002)(53416004)(2950100001)(110136001)(48376002)(92566002)(106466001)(81156004)(86362001)(68736005)(50466002)(77096005)(97736003)(54356999)(6806004)(105596002)(69596002)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005004); SRVR:CO1PR05MB441; X-Forefront-PRVS: 04976078F0 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2015 14:37:58.2362 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB441 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement (2nd try) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 14:38:02 -0000 Juergen Schoenwaelder writes: >I do not buy this argument. Y34 is addressing issues that have >surfaced with the usage of anyxml. Since we can't simple change the >semantics of anyxml (for backwards compatibility reasons), the obvious >solution is to create a replacement for the situations where "any data >that can be defined in YANG is needed" and to discourage the usage of >anyxml. I don't understand the need to discourage the use of anyxml. I don't get why it suddenly became scary or dangerous. It's a chunk of XML data, which is a useful datatype regardless of the encoding scheme used to transport it. anyxml is simple and easy to understand. You may not like it or want to use it, but it's concrete and well defined. In contrast, anydata implies something more intangible, where we are saying that there's a chunk of data here that has a data model, but you may not know what that model is. This implies that you may or may not know how to marshal or unmarshal it, how to insert/delete/rename data within it, etc. It's no longer a simple datatype. It's alive, complex, and governed by unknown rules. Yes, the server understands the data model (assumably), but it still seems wrong. Thanks, Phil From nobody Tue Feb 24 07:20:25 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0381A87E9; Tue, 24 Feb 2015 07:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-e8p8pwoBhq; Tue, 24 Feb 2015 07:20:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2177E1A8822; Tue, 24 Feb 2015 07:20:03 -0800 (PST) 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: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150224152003.26255.82373.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 07:20:03 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 15:20:24 -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 Working Group of the IETF. Title : JSON Encoding of Data Modeled with YANG Author : Ladislav Lhotka Filename : draft-ietf-netmod-yang-json-03.txt Pages : 18 Date : 2015-02-24 Abstract: This document defines encoding rules for representing configuration, state data, RPC input and output parameters, and notifications defined using YANG as JavaScript Object Notation (JSON) text. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-yang-json-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-json-03 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 Tue Feb 24 07:22:42 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081661A87E9 for ; Tue, 24 Feb 2015 07:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 fbtZCJK-no0Q for ; Tue, 24 Feb 2015 07:22:36 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8981A1BB3 for ; Tue, 24 Feb 2015 07:22:29 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:f073:a7bf:5b0c:84c4] (unknown [IPv6:2001:718:1a02:1:f073:a7bf:5b0c:84c4]) by mail.nic.cz (Postfix) with ESMTPSA id E4B7814092C for ; Tue, 24 Feb 2015 16:22:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1424791347; bh=muu/VFmooD1Gfp9Y8MoLmYWJgasYuQTIXy4rM7O4jt4=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=WguGVcEWs5q52NmUAa31iOsGE3L9hSDk83Yn+8xjIw+NtQy4cRpKgXPvIUaSPb63q BY2FIC1zNQFe20ixO8g0QWp3kS4SYD2hZ4o7ceDK0GGDrK+Cc8BAEcDG7GVWtSyHRp 1TStNLHhtKkSsTB3wZAOT0AkJS3K7CuFcswStmH0= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Feb 2015 16:22:30 +0100 References: <20150224152003.26255.82373.idtracker@ietfa.amsl.com> To: NETMOD Working Group Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-yang-json-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 15:22:38 -0000 Hi, main changes in this revision: o Namespace encoding is defined without using RFC 2119 keywords. o Specification for anyxml nodes was extended and clarified. o Text about ordering of list entries was corrected. Lada > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: > Date: 24 Feb 2015 16:20:03 CET > Cc: netmod@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the NETCONF Data Modeling Language = Working Group of the IETF. >=20 > Title : JSON Encoding of Data Modeled with YANG > Author : Ladislav Lhotka > Filename : draft-ietf-netmod-yang-json-03.txt > Pages : 18 > Date : 2015-02-24 >=20 > Abstract: > This document defines encoding rules for representing configuration, > state data, RPC input and output parameters, and notifications > defined using YANG as JavaScript Object Notation (JSON) text. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-yang-json-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-json-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Feb 24 08:33:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2348E1A1A9D for ; Tue, 24 Feb 2015 08:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL2i_SOCrwed for ; Tue, 24 Feb 2015 08:33:01 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 59F1D1A8780 for ; Tue, 24 Feb 2015 08:33:00 -0800 (PST) Received: by lbvn10 with SMTP id n10so26114758lbv.6 for ; Tue, 24 Feb 2015 08:32:58 -0800 (PST) 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:content-type; bh=3yJC+muUeahnl304l79/TbuvJShPhY3vWb9HiuNsRnc=; b=UPr2zpWxYD10MIVrn065nZg5xASLTf8MqJLJ/sr7motp/qCj5cstKheaEOjDoxyjcn a6wp/H9II1xw2/lSOs2bYJiUsM65YV0svKnIZrUyUBBmqXU2OAlDn6AzlmFnrDWwQW7l 4v1B2VLjiTOL0Ne0PRG5/CxnxPj7YMih362P022wt6xS5OpKCwEfLdrKUa5Ff4tln9hh Q6k88euykbj8ChSM2dIQf/KIyGk9w9kO4RAOAsq4rvj4OSBLQuz1ja2L1PRopasMuRHF F/Ye3v8rTUGjQRctnfmLiYI1NEfWvWHSbjejT8drPS/A3rd5ooIBsrHYoE6IuRX/Z2Ru 1QYA== X-Gm-Message-State: ALoCoQmOJjSRtR5XyiCwzShmSmlwwds2y0aLatiOaTJitDdwlryMiiOgHMcNN3WU6yDfjFOFjWG4 MIME-Version: 1.0 X-Received: by 10.152.4.5 with SMTP id g5mr14844559lag.119.1424795578673; Tue, 24 Feb 2015 08:32:58 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 24 Feb 2015 08:32:58 -0800 (PST) In-Reply-To: <20150224124840.GB170@elstar.local> References: <20150213204153.GA53713@elstar.local> <201502162140.t1GLeW1g050451@idle.juniper.net> <20150224124840.GB170@elstar.local> Date: Tue, 24 Feb 2015 08:32:58 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Phil Shafer , "netmod@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement (2nd try) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 16:33:03 -0000 On Tue, Feb 24, 2015 at 4:48 AM, Juergen Schoenwaelder wrote: > On Mon, Feb 16, 2015 at 04:08:59PM -0800, Andy Bierman wrote: >> On Mon, Feb 16, 2015 at 1:40 PM, Phil Shafer wrote: >> > Juergen Schoenwaelder writes: >> >> - Introduce a new 'anydata' statement that represents an unknown >> >> chunk of data that can be modeled with YANG. >> > >> > I'd be opposed to introducing anydata. It's a bit too much like >> > introducing a hole into the model. Sure, the server assumably knows >> > what's there, but it's still a new feature. The current charter >> > says: >> > >> > - YANG 1.1 is not adding fundamentally new data modeling concepts to the language. >> > >> >> The problem with anydata is that it is a generic attempt to fix all uses >> of anyxml. >> >> Each of the anyxml use-cases in RFCs and I-Ds is really a >> poor man's substitutionGroup macro (from XSD), or a node >> acting as the root for top-level YANG data nodes. >> >> Using anydata as a free-form hole in the datastore is a bad idea. >> Introducing anydata seems to require a server to support this, >> as well as support mixed mode XML (since anyxml is still current, >> and that seems to be the only difference from anydata). >> >> IMO Y34 is in scope because anyxml is not being used as a leaf >> holding a blob of HTML, as envisioned by the WG when RFC 6020 >> was written. The solution might make the problem worse, not better. >> IMO a solution that addresses the 2 actual use-cases for anyxml >> is needed. > > I am not sure I understand the '2 actual use-cases' (or why there are > only two). Anyway, you need to writeup a proper solution proposal if > you think the one we so far agreed on (Y34-05) is fundamentally flawed. > And it might help if you can explain more precisely why anydata will > be worse than having anyxml. > I don't think the backward compatibility argument holds because nobody actually implemented it. In order for there to be interoperability, there needs to be implementations. I get the fact that anyxml is perfect for a leaf called "web-banner". Too bad nobody actually does that with anyxml. So I am confused about all the great standards success we are preserving with anyxml. The only advocates don't actually have implementations. If anyxml is so great, then declare this issue dead. No need to change anything. > /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 Tue Feb 24 08:47:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042B11A8822 for ; Tue, 24 Feb 2015 08:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9rsFI02LxMl for ; Tue, 24 Feb 2015 08:47:00 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 483851A1B8B for ; Tue, 24 Feb 2015 08:46:43 -0800 (PST) Received: by lbiw7 with SMTP id w7so26211543lbi.9 for ; Tue, 24 Feb 2015 08:46:41 -0800 (PST) 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:content-type; bh=6nz6i2qTlRD+AEhO53qZnXNfNXlWL0Qk/uUAJ5SI4tY=; b=f1efpQKJvcibclQUPYoKkukX9tXG1hapPW1cwm5K/UsKASlDHL/Sj61EsyWZDQ6lq3 lb7p7iw4rY6LAMK3kvJmb98Q/fjOxQ7A/RyVUF4AwN8R3JFx8P4QOZkVtc7rynIsTo+L 8f7HD7bbMW4TbXk1pcdqDBFaXVh/4V+L0qRJTihNuqzY7H8TomKX8dCBb+CdGCZdf+1r BUxhZE3QqwMx1ZGFpZdd6Yl1iVVlu4kKG0D2SheWESK/BrZ4WdiXERlgKM+T5v28hfcO lilfGuEyZMcF+sbgCobgUdykdzV1blTbASUsznkRuRNFIBEPO4NDDQ9BZsHGfsVgrSza CAUQ== X-Gm-Message-State: ALoCoQmV2nipz3UBWXBGqqLuFaUjkDNm3EVBcg3bC7QbfOL2xkzMUgdvt7LMuCt7uyTAdpNur6wX MIME-Version: 1.0 X-Received: by 10.112.139.136 with SMTP id qy8mr15219622lbb.38.1424796401497; Tue, 24 Feb 2015 08:46:41 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 24 Feb 2015 08:46:41 -0800 (PST) In-Reply-To: References: <20150213212033.GA54556@elstar.local> <54DE848B.1080701@tail-f.com> <54EBAFA6.4050009@tail-f.com> Date: Tue, 24 Feb 2015 08:46:41 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 16:47:04 -0000 On Tue, Feb 24, 2015 at 4:49 AM, Ladislav Lhotka wrote: > Per Hedeland writes: > >> On 2015-02-23 15:46, Ladislav Lhotka wrote: >>> Per Hedeland writes: >>> >>>> On 2015-02-13 22:41, Andy Bierman wrote: >>>>> On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> Y25 (make enum numbering purely informative and optional) has been >>>>>> discussed but no clear concensus has been reached so far. Y25-01 >>>>>> proposes to remove the auto-numbering mechanism. With the appearance >>>>>> of a CBOR encoding proposal [1], the numeric values may actually be >>>>>> used on the wire. An alternative is to keep the auto-numbering >>>>>> mechanism but to clarify the risks, this is what I have written up as >>>>>> solution Y25-02: >>>>>> >>>>>> ** Solution Y25-02 >>>>>> >>>>>> Keep the auto-numbering procedure for enums and bits and add an >>>>>> explicit warning that inserting enum definitions or reordering of >>>>>> enum definitions very likely causes interoperability problem and >>>>>> that explicit value assignments avoid this problem. >>>>>> >>>>> >>>>> >>>>> This is not really keeping the current procedure. >>>>> Currently, the auto-numbering is mandatory, and sec 10. >>>>> clearly prohibits changing any value or position statement. >>>>> >>>>> IMO Y25 should be declared DEAD and the YANG 1.0 behavior >>>>> not changed at all. >>>> >>>> +1 >>>> >>>>> You are proposing that Sec. 10 be changed so renumbering is >>>>> a warning, not a violation of the standard. >>>> >>>> Yes - and this is IMO clearly a non-backwards compatible change. The >>>> "backwards compatible" requirement is extremely loosely specified by the >>>> charter, i.e. "All compliant YANG 1.0 modules must be accepted as >>>> compliant YANG 1.1 modules" - which if taken literally would allow for >>>> anything that completely changes the semantics of a 1.0 module, as long >>>> as it is still "accepted as compliant" in 1.1. This is clearly not what >>>> anyone expects - the semantics should be unchanged, at least as long as >>>> the 1.0 semantics are not clearly broken / unimplementable etc. >>>> >>>> RFC 6020 makes the promise to implementations that enum values are >>>> stable as long as section 10 is adhered to. The suggested change breaks >>>> this promise, thus it should be considered non-backwards compatible. >>> >>> What promise are you talking about? >> >> The auto-numbering procedure, together with the restriction in section >> 10, guarantees that every enum will have an associated integer value >> that doesn't change when the module is updated. >> >>> It is the enum *string* that is being >>> exchanged in the protocol(s), so, strictly speaking, in the context of RFC >>> 6020 there is no way for a NETCONF/RESTCONF peer to tell whether any >>> implementation uses the auto-allocated values or not. >> >> Yes, this is not a protocol issue (yet), but ... > > And that's my point, it is neither a language nor a protocol issue, and > therefore it doesn't belong to the specification. > It will be a protocol issue soon. Like tail-f, we also have customers who expect these mappings to be permanent. They are often used in the firmware instead of the strings. The spec clearly says these mappings are permanent. Changing this mapping or removing the numbers altogether will break YANG 1.0 implementations. >> >>> RFC 6020 also clearly says: "The value is unused by YANG and the XML >>> encoding, ...". >> >> ... it goes on to say "... but is carried as a convenience to >> implementors." I.e. being a "convenience to implementors" is the purpose >> of the auto-numbering scheme and the section 10 restriction. > > The real convenience is that implementors can choose whatever numbering > they like (or no numbering at all), there is no need that the numbering > be the same at the sending and receiving side. > >> >>> Of course, the situation changes if CBOR encoding chooses to use numeric >>> values but I'd argue this wasn't the original intention, >> >> Agreed. >> >>> and so the >>> motivation of the corresponding sec. 10 restriction remains unclear to >>> me. >> >> See above. >> >>>> The motivations for making any change at all are also very dubious: >>>> >>>> 1. "This rule makes updates of enumerations difficult" >>>> >>>> Disregarding that "difficult" is a very subjective judgement, what >>>> exactly is difficult about it? The only example that I have seen on >>> >>> This has already been discussed several times. Consider an enumeration such as >>> ISO 3166 alpha-2 country codes: >>> >>> https://www.iso.org/obp/ui/#search >>> >>> It is sorted alphabetically, so new entries will most likely be added >>> somewhere in the middle. This is impossible with auto-numbering, so >>> currently the only solution would be to add a bogus number to each enum, >>> which would make the module defining such an enumeration longer by 30 % >>> or so. >> >> This can hardly be a significant concern for such a module. >> >>> What's your suggestion as to how such an enumeration should be set up and >>> maintained? >> >> Same as for the time zone case, described below. If you are wondering >> about the implementation of the auto-generating piece of software, it is >> just a matter of parsing the previous version of the module to get the >> existing value assignments, and make use of that information when >> generating the new version. > > Of course, but I have always assumed *human readability* of YANG modules > has the highest priority. And if the numbers are bogus, then they just add noise. > There are not really many cases where the list of enums is auto-generated from an external source like IANA. Adding new enums/bits so they do not change old numbers is usually quite easy. > I simply don't agree the touted "convenience to implementors" outweighs > the inconvenience to readers of such modules and maintainers. YANG > wouldn't be less usable if the auto-numbering procedure was removed. > IMO it was inevitable that a protocol would come along that used YANG but still wanted to minimize bytes on the wire. NETCONF WG's apparent lack of concern for message count or message size would not be shared by other WGs. >> >> However, note that the message you are replying to, and specifically the >> commentary on Y25-02, was due to a misunderstanding of Juergen's >> proposal. Per subsequent messages, Y25-02 was not intended to suggest >> any changes to the auto-numbering scheme or the section 10 >> restriction. >> And thus I support that proposal, although I made some suggestions for >> a minor rewording. > > I don't agree changes to values/positions can lead to interoperability > problems - unless we take the COMI decision to use these numbers in the > protocol for granted. > > Lada > Andy >> >> --Per >> >>> Lada >>> >>>> the mailing list is the infamous time zone case. This case revealed several >>>> problems: >>> >>> >>>> >>>> a) The specification of the auto numbering procedure was unclear. This >>>> has been addressed by errata 3871. >>>> >>>> b) No-one wanted to assume the responsibility of maintaining a standard >>>> module specifying the enums, probably in no small part due to >>>> >>>> c) The maintainers of the time zone data were clearly opposed to having >>>> any part of it turned into any kind of standard, due to the (additional) >>>> political controversy this could lead to. >>>> >>>> However no technical or practical difficulty in maintaining a module for >>>> these enums that adheres to section 10 has been demonstrated. In fact >>>> assuming the obvious, that such a module would be auto-generated from >>>> some free-form data, whether the raw timezone data or a simple list >>>> (without any requirement on ordering) of identifiers, it is a very >>>> trivial problem to solve. Martin already offered to provide a piece of >>>> software to do that, I can do the same, but of course this particular >>>> case is now moot. >>>> >>>> In the more typical case of a handful of manually assigned enums, >>>> maintaining the numbering can't reasonably be considered difficult. >>>> >>>> 2. "and/or forces the data modeller to assign the values explicitly even >>>> if they have no meaning otherwise." >>>> >>>> The only case where a data modeller would be *forced* to assign values >>>> is that of removing an enum other than the "last" one, without adding >>>> another to take its place. As far as I can see, removing enums is >>>> already ruled out by section 10, and not a candidate for change. >>>> >>>> But obviously there are cases where some specific order of the enums is >>>> more "natural" than others, and adhering to that order is likely to >>>> improve readability, which is an important goal. Even in such a case >>>> there is no need to assign values in the original version of the module, >>>> but it may be needed on update if it is desired to add an enum "in the >>>> middle" - but this is not being *forced*. (And readability can only be >>>> an actual concern if the total set of enums is small, and then again it >>>> can't reasonably be considered difficult to maintain the values.) >>>> >>>> 3. "The rule also contradicts the statement in Sec. 9.6.4.2 because the >>>> value in fact is used by YANG." >>>> >>>> I disagree, the statement in 9.6.4.2 is accurate - the values aren't >>>> *used* by YANG. YANG mereley puts some restrictions on them and provides >>>> them to implementations. But if someone really feels strongly about >>>> this, the obvious fix is to the text as s/YANG and// - not changing the >>>> semantics. >>>> >>>> --Per Hedeland >>>> >>>>> Andy >>>>> >>>>>> The guidelines document may add further rules such that enum/bits >>>>>> values must be explicitly defined in IETF modules (to be discussed >>>>>> in the context of the guidelines document). >>>>>> >>>>>> [1] https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ >>>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>>> Fax: +49 421 200 3103 >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>> >>>> _______________________________________________ >>>> 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 Feb 24 09:42:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D4E1A1BE9 for ; Tue, 24 Feb 2015 09:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI2kYMWaov0U for ; Tue, 24 Feb 2015 09:42:32 -0800 (PST) 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 CA5271A1B2A for ; Tue, 24 Feb 2015 09:42:29 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-fc-54ecb8034293 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9E.A6.04076.308BCE45; Tue, 24 Feb 2015 18:42:27 +0100 (CET) Received: from [159.107.197.114] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.210.2; Tue, 24 Feb 2015 18:42:27 +0100 Message-ID: <54ECB803.5060107@ericsson.com> Date: Tue, 24 Feb 2015 18:42:27 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "netmod@ietf.org" References: <54DB5A20.1030707@ericsson.com> <54E49AC2.9070101@ericsson.com> <20150218142741.GB27885@elstar.local> In-Reply-To: <20150218142741.GB27885@elstar.local> Content-Type: multipart/mixed; boundary="------------080301030100010501080008" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+JvjS7zjjchBgumW1vMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujF33V7EVNHlUvHg0m7WB8Zl5FyMnh4SAicTBY83sELaYxIV7 69m6GLk4hASOMEr8bzrBDOGsZZT4dH0mWBWvgLbErn+NLCA2i4CqxLOrj8DibAJGElP7z4PF RQWiJGaff8AKUS8ocXLmE7C4iIC6xMydIBs4OYQF9CWevv/LCLFgG6PEx52fwBo4gQatXrcG KMHBwSwQIDHplhJIWEhAQ+Lhhb+sExj5ZyEZOwuhCsK0l3iwtQykgllAXmL72znMEHaUxPFN yxgxxb0lute1MS5gZF/FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERjIB7f8ttrBePC54yFG AQ5GJR7eAsU3IUKsiWXFlbmHGKU5WJTEee2MD4UICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YPT/d9abe72q8gqxWoV93PrFqzcGXHB5b2S172nkn3OmvaGrpnxc/l0lpfej2Lmu0qVczxuO RPx8HbM0RuPoYftw4cPXJ9/7URXq4OdT1y02qZL5cFCiesUKlY9L/3neMuov+WNUGm113Uxk etvird497/OszPdwCOu9tD2+9RiLePpu/76fDUosxRmJhlrMRcWJADUXJPNFAgAA Archived-At: Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 17:42:34 -0000 --------------080301030100010501080008 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Hello Juergen, 1) You misunderstood me. What is now under Y57-3 is actually a merge of Y57-1 and Y57-2. -1 and -2 were never alternatives, they were two parts of the same proposal, so to make life easier they should be merged. Please remove the current -1 and -2 and use the updated/attached version of -3 as the one and only new -1 proposal. 2) About, motivation (a.k.a problem statement) I propose to change the beginning of the text to: "In the number of cases we need to model a list of simple items that do not need or have a key value. Leaf-lists are used for this in YANG. However sometimes a value needs to be included multiple times in the leaf-list. In YANG 1.0 all values in a leaf-list MUST be unique. The proposal is to relax this in YANG 1.1. Examples where nonUnique leaf-list are needed include: - list of AS-Paths - list of queuing weights in a scheduler" So the new text of Y57 considering 1) and 2) above should be the text I attached here. That should replace everything that is in Y57 today. 3) As there were no opposing emails on the list can we move it forward to EDIT status? regards Balazs On 2015-02-18 15:27, Juergen Schoenwaelder wrote: > Balazs, > > I think we need a better problem statement. The text we have in Y57 > says 'lets see whether we can relax the rules' but it does not provide > a rationale why we would do that. Which benefit do we get if we relax > the rules? > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com --------------080301030100010501080008 Content-Type: text/plain; charset="windows-1252"; name="webTextSetnToJurgen20150224.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="webTextSetnToJurgen20150224.txt" Description --------------- In a number of cases we need to model a list of simple items that do not need or have a key value. Leaf-lists are used for this in YANG. However sometimes a value needs to be included multiple times in the leaf-list. In YANG 1.0 all values in a leaf-list MUST be unique. The proposal is to relax this in YANG 1.1. Examples where nonUnique leaf-list are needed include: - list of AS-Paths - list of queueing weights in a scheduler If the leaf-list is unique the handling does not change compared to YANG 1.0 A nonUnique leaf-list is still handled as a set of separate leafs as in YANG 1.0 New mechanism to handle all values of a leaf-list toghether are NOT introduced. If we have a leaf-list with nonUnique values in the datastore a value in edit-config addresses the first such value in the datastore. This alternative is selected for simplicity. (Note: Alternatively it could address all such values in the datastore which would be simple for delete/remove, but strange for replace and merge. Merge should be additive but merging [a,a,a] with [a] would result in [a] which is not additive. It would be very strange for insert-after; we want to insert one value, but suddenly it can become multiple values.) Solution Y57-01 Change to section 3: leaf-list: Like the leaf node but defines a set of uniquely identifiable nodes rather than a single node. Each node has a value but no child nodes. change to leaf-list: Like the leaf node but defines a set of nodes rather than a single node. Each node has a value but no child nodes. Change to section 4.2.2.2: A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf. change to A leaf-list is a sequence of leaf nodes. Remove from section 7.7: The values in a leaf-list MUST be unique. Add to section 7.7.3: (substatements) unique-leaf-list cardinality 0..1 Add a level 3 section before 7.7.7: 7.7.7b The unique-leaf-list Statement The "unique-leaf-list" statement takes as an argument the string "true" or "false". If "unique-leaf-list" is "true", values within the leaf-lists must be unique. If "unique-leaf-list" is "false", values within the leaf-lists may be repeated. If "unique-leaf-list" is not specified, the default is true. Change section 7.7.9 (edit-config stuff) The operation's way of working is dependent on the value of unique-leaf-list. If unique-leaf-list is true the current handling is unchanged. If unique-leaf-list is false the following applies: - delete/remove: delete/remove the addressed value (first occurence) from the leaf-list. If a value exists multiple times in edit-config try to delete 2/3/.. instances of the value. For the delete operation it is an error if insufficient value instances exist in datastore. - create: create value. It succeeds even if value already exists, just adds the value once more. If no "insert" attribute is present in the "create" operation, it defaults to "last". If a value exists multiple times in edit-config repeat the steps. - replace, merge: For each specific value, the number of instances of the value in edit-config and the datastore are matched against each other. For each such value instance if insert is not specified in the edit-config operation the value in the datastore is left unchanged. If the insert is specified, delete the matched value in the datastore, if it exists, and re-create it as specified by insert. If the insert attribute is accomponied with a value attribute, it is the first occurrence of the value in the datastore that is indicated. If a value exists multiple times in edit-config repeat the steps. If edit-config contains more instances then the datastore, the additional ones are created as in a create operation. If the datastore contains more instances, they are not modified. ================================================================================================= Addressing by position Further changes to section 7.7.9: In an "ordered-by user" leaf-list, the attribute "position" in the YANG XML namespace (Section 5.3.1) can be used to address specific values in the leaf-list. Position MUST be between 1 and the length of the leaf-list. If both the position and the value attributes are specified in edit-config for the same data node, the value attribute has no effect and may be (should be) ommitted by the client. If position is specified, the insert attribute can only take the values after and before. First and last are error. (There is no sense in specifying position once the insert=first/last is specified, it would just add one more useless and complicated case.) - delate/remove: add: If position is specified, the value of the leaf-instance, has no effect, it may be omitted by the client. (Addressing by position takes precedence over addressing by value.) - create: add: If position is specified but insert is not specified insert=after is implied. - replace/merge: if position is specified but insert is not, replace the value specified by position. If both position and insert=after/before is specified, insert a new leaf with the value at the specified position. (replace/merge works differently with and without position.) ================================================================================================== Add to 7.7.10 Usage example for position: Ethernet0/0 1500
192.0.2.4 24
-- change 12.1 Add: | unique-leaf-list | value | false | -- change 13 TBD Add the unique-leaf-list statement -- change 14.1 Modify so it applies to leaf-lists as well. ---Note: This is an error correction, independent of the introduction of nonUnique leaf-lists -- change 14.8 Modify to cover the position attribute -- change 14.x Add new sections for the following errors - not allowed combinations of value, insert and position - position out of range - mixed usage of selection by value and position for leaf-lists - mixed usage of the operation parameter for a nonUnique leaf-list when addressing by value --------------080301030100010501080008-- From nobody Tue Feb 24 11:56:50 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398491A889F for ; Tue, 24 Feb 2015 11:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUZZc1lxLGnQ for ; Tue, 24 Feb 2015 11:56:46 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 202971A6EE7 for ; Tue, 24 Feb 2015 11:56:46 -0800 (PST) Received: from pluto.hedeland.org (h194n2-hy-a32.ias.bredband.telia.com [81.228.176.194]) by mail.tail-f.com (Postfix) with ESMTPSA id 379D712801AA; Tue, 24 Feb 2015 20:56:44 +0100 (CET) Message-ID: <54ECD77C.1090407@tail-f.com> Date: Tue, 24 Feb 2015 20:56:44 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ladislav Lhotka References: <20150213212033.GA54556@elstar.local> <54DE848B.1080701@tail-f.com> <54EBAFA6.4050009@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 19:56:49 -0000 On 2015-02-24 13:49, Ladislav Lhotka wrote: > Per Hedeland writes: > >> On 2015-02-23 15:46, Ladislav Lhotka wrote: >>> Per Hedeland writes: >>> >>>> On 2015-02-13 22:41, Andy Bierman wrote: >>>>> On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> Y25 (make enum numbering purely informative and optional) has been >>>>>> discussed but no clear concensus has been reached so far. Y25-01 >>>>>> proposes to remove the auto-numbering mechanism. With the appearance >>>>>> of a CBOR encoding proposal [1], the numeric values may actually be >>>>>> used on the wire. An alternative is to keep the auto-numbering >>>>>> mechanism but to clarify the risks, this is what I have written up as >>>>>> solution Y25-02: >>>>>> >>>>>> ** Solution Y25-02 >>>>>> >>>>>> Keep the auto-numbering procedure for enums and bits and add an >>>>>> explicit warning that inserting enum definitions or reordering of >>>>>> enum definitions very likely causes interoperability problem and >>>>>> that explicit value assignments avoid this problem. >>>>>> >>>>> >>>>> >>>>> This is not really keeping the current procedure. >>>>> Currently, the auto-numbering is mandatory, and sec 10. >>>>> clearly prohibits changing any value or position statement. >>>>> >>>>> IMO Y25 should be declared DEAD and the YANG 1.0 behavior >>>>> not changed at all. >>>> >>>> +1 >>>> >>>>> You are proposing that Sec. 10 be changed so renumbering is >>>>> a warning, not a violation of the standard. >>>> >>>> Yes - and this is IMO clearly a non-backwards compatible change. The >>>> "backwards compatible" requirement is extremely loosely specified by the >>>> charter, i.e. "All compliant YANG 1.0 modules must be accepted as >>>> compliant YANG 1.1 modules" - which if taken literally would allow for >>>> anything that completely changes the semantics of a 1.0 module, as long >>>> as it is still "accepted as compliant" in 1.1. This is clearly not what >>>> anyone expects - the semantics should be unchanged, at least as long as >>>> the 1.0 semantics are not clearly broken / unimplementable etc. >>>> >>>> RFC 6020 makes the promise to implementations that enum values are >>>> stable as long as section 10 is adhered to. The suggested change breaks >>>> this promise, thus it should be considered non-backwards compatible. >>> >>> What promise are you talking about? >> >> The auto-numbering procedure, together with the restriction in section >> 10, guarantees that every enum will have an associated integer value >> that doesn't change when the module is updated. >> >>> It is the enum *string* that is being >>> exchanged in the protocol(s), so, strictly speaking, in the context of RFC >>> 6020 there is no way for a NETCONF/RESTCONF peer to tell whether any >>> implementation uses the auto-allocated values or not. >> >> Yes, this is not a protocol issue (yet), but ... > > And that's my point, it is neither a language nor a protocol issue, and > therefore it doesn't belong to the specification. I most definitely consider it a language issue, as it is part of the current language specification - the one we're supposed to be backwards compatible with. >>> RFC 6020 also clearly says: "The value is unused by YANG and the XML >>> encoding, ...". >> >> ... it goes on to say "... but is carried as a convenience to >> implementors." I.e. being a "convenience to implementors" is the purpose >> of the auto-numbering scheme and the section 10 restriction. > > The real convenience is that implementors can choose whatever numbering > they like (or no numbering at all), there is no need that the numbering > be the same at the sending and receiving side. No, the convenience is that the YANG specification guarantees that the numbers are stable. Implementors can of course choose whatever they want regardless of whether the specification includes a numbering scheme or not. >>> Of course, the situation changes if CBOR encoding chooses to use numeric >>> values but I'd argue this wasn't the original intention, >> >> Agreed. >> >>> and so the >>> motivation of the corresponding sec. 10 restriction remains unclear to >>> me. >> >> See above. >> >>>> The motivations for making any change at all are also very dubious: >>>> >>>> 1. "This rule makes updates of enumerations difficult" >>>> >>>> Disregarding that "difficult" is a very subjective judgement, what >>>> exactly is difficult about it? The only example that I have seen on >>> >>> This has already been discussed several times. Consider an enumeration such as >>> ISO 3166 alpha-2 country codes: >>> >>> https://www.iso.org/obp/ui/#search >>> >>> It is sorted alphabetically, so new entries will most likely be added >>> somewhere in the middle. This is impossible with auto-numbering, so >>> currently the only solution would be to add a bogus number to each enum, >>> which would make the module defining such an enumeration longer by 30 % >>> or so. >> >> This can hardly be a significant concern for such a module. >> >>> What's your suggestion as to how such an enumeration should be set up and >>> maintained? >> >> Same as for the time zone case, described below. If you are wondering >> about the implementation of the auto-generating piece of software, it is >> just a matter of parsing the previous version of the module to get the >> existing value assignments, and make use of that information when >> generating the new version. > > Of course, but I have always assumed *human readability* of YANG modules > has the highest priority. And if the numbers are bogus, then they just add noise. You are raising points that I already addressed in my original message, see below. Readability can't realistically be considered important for a module that has hundreds of auto-generated enum statements as its only content. And for "normal" modules, with enumeration types that have a handful of enums, observing the section 10 requirement in the cases where enums need to be added can't be considered difficult. --Per > I simply don't agree the touted "convenience to implementors" outweighs > the inconvenience to readers of such modules and maintainers. YANG > wouldn't be less usable if the auto-numbering procedure was removed. > >> >> However, note that the message you are replying to, and specifically the >> commentary on Y25-02, was due to a misunderstanding of Juergen's >> proposal. Per subsequent messages, Y25-02 was not intended to suggest >> any changes to the auto-numbering scheme or the section 10 >> restriction. >> And thus I support that proposal, although I made some suggestions for >> a minor rewording. > > I don't agree changes to values/positions can lead to interoperability > problems - unless we take the COMI decision to use these numbers in the > protocol for granted. > > Lada > >> >> --Per >> >>> Lada >>> >>>> the mailing list is the infamous time zone case. This case revealed several >>>> problems: >>> >>> >>>> >>>> a) The specification of the auto numbering procedure was unclear. This >>>> has been addressed by errata 3871. >>>> >>>> b) No-one wanted to assume the responsibility of maintaining a standard >>>> module specifying the enums, probably in no small part due to >>>> >>>> c) The maintainers of the time zone data were clearly opposed to having >>>> any part of it turned into any kind of standard, due to the (additional) >>>> political controversy this could lead to. >>>> >>>> However no technical or practical difficulty in maintaining a module for >>>> these enums that adheres to section 10 has been demonstrated. In fact >>>> assuming the obvious, that such a module would be auto-generated from >>>> some free-form data, whether the raw timezone data or a simple list >>>> (without any requirement on ordering) of identifiers, it is a very >>>> trivial problem to solve. Martin already offered to provide a piece of >>>> software to do that, I can do the same, but of course this particular >>>> case is now moot. >>>> >>>> In the more typical case of a handful of manually assigned enums, >>>> maintaining the numbering can't reasonably be considered difficult. >>>> >>>> 2. "and/or forces the data modeller to assign the values explicitly even >>>> if they have no meaning otherwise." >>>> >>>> The only case where a data modeller would be *forced* to assign values >>>> is that of removing an enum other than the "last" one, without adding >>>> another to take its place. As far as I can see, removing enums is >>>> already ruled out by section 10, and not a candidate for change. >>>> >>>> But obviously there are cases where some specific order of the enums is >>>> more "natural" than others, and adhering to that order is likely to >>>> improve readability, which is an important goal. Even in such a case >>>> there is no need to assign values in the original version of the module, >>>> but it may be needed on update if it is desired to add an enum "in the >>>> middle" - but this is not being *forced*. (And readability can only be >>>> an actual concern if the total set of enums is small, and then again it >>>> can't reasonably be considered difficult to maintain the values.) >>>> >>>> 3. "The rule also contradicts the statement in Sec. 9.6.4.2 because the >>>> value in fact is used by YANG." >>>> >>>> I disagree, the statement in 9.6.4.2 is accurate - the values aren't >>>> *used* by YANG. YANG mereley puts some restrictions on them and provides >>>> them to implementations. But if someone really feels strongly about >>>> this, the obvious fix is to the text as s/YANG and// - not changing the >>>> semantics. >>>> >>>> --Per Hedeland >>>> >>>>> Andy >>>>> >>>>>> The guidelines document may add further rules such that enum/bits >>>>>> values must be explicitly defined in IETF modules (to be discussed >>>>>> in the context of the guidelines document). >>>>>> >>>>>> [1] https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ >>>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>>> Fax: +49 421 200 3103 >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >> > From nobody Tue Feb 24 14:20:55 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABD41A9058; Tue, 24 Feb 2015 14:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lh7EEg7AFvpt; Tue, 24 Feb 2015 14:20:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E61A81A9050; Tue, 24 Feb 2015 14:20:52 -0800 (PST) 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: 5.11.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150224222052.26592.56239.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 14:20:52 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 22:20:54 -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 Working Group of the IETF. Title : SYSLOG YANG model Authors : Clyde Wildes Brocade Communications Systems Filename : draft-ietf-netmod-syslog-model-01.txt Pages : 21 Date : 2015-02-24 Abstract: This document describes a data model for Syslog protocol which is used to convey event notification messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-syslog-model-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-01 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 prasad@anutanetworks.com Wed Feb 25 10:59:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC50C1A1B85 for ; Wed, 25 Feb 2015 10:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9aFNqTP_Dl7 for ; Wed, 25 Feb 2015 10:59:32 -0800 (PST) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (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 7E8221A1A4B for ; Wed, 25 Feb 2015 10:59:32 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id x69so5073940oia.5 for ; Wed, 25 Feb 2015 10:59:32 -0800 (PST) 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 :content-type; bh=ghR5vMjTOVULXndYvR/VU49tV9k2dOQne60s/deTfGk=; b=G8i7vLLgk6CnOw7cCuxMT5QqvWmAdqrJ70ECC5AinDGazi+wf7CTG9IAY/F1UJOKSN Bcb73kek9ikKEwDaUy7aVaVrZXR3j+BBvgTnrKOCK/OGIKzgg/hKRzyF32yVAg7Tdbek Oz5CVL3JmaR62X6+Sat/4iUk14p0g7dkA/ebonBmVJmZTz87WT8s7elxl/kMJAUftgrY DtOXSlx7NvX0+DYIKhCT8OimoLlVIddbEbn+7+QlHjbDmlMCQHKImkg4ljS8IFZW8368 FSbE0VHrlEu/XdYCI+E5KcyA6JHZC+AgHJ8BuIokpEJpoFZR18yKmCNESYzXqF3xZULd mGIg== X-Gm-Message-State: ALoCoQlTrWFr1xsHi5T0BXf/BDptO1Wl+nrN6kHTwaVkUF0+s/iNnd2//Ft6iCFU6OtdbRLAxmQm MIME-Version: 1.0 X-Received: by 10.182.22.137 with SMTP id d9mr3262242obf.67.1424890771903; Wed, 25 Feb 2015 10:59:31 -0800 (PST) Received: by 10.202.129.139 with HTTP; Wed, 25 Feb 2015 10:59:31 -0800 (PST) Date: Wed, 25 Feb 2015 12:59:31 -0600 Message-ID: From: Prasad Sanampudi To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11c2e5584db024050fee3c68 Archived-At: Subject: [netmod] test X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 19:02:49 -0000 --001a11c2e5584db024050fee3c68 Content-Type: text/plain; charset=UTF-8 --001a11c2e5584db024050fee3c68 Content-Type: text/html; charset=UTF-8

--001a11c2e5584db024050fee3c68-- From nobody Wed Feb 25 11:11:15 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D081A6FEA for ; Wed, 25 Feb 2015 11:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIDg9cdg5xTH for ; Wed, 25 Feb 2015 11:11:12 -0800 (PST) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (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 B75F81A6F2E for ; Wed, 25 Feb 2015 11:11:11 -0800 (PST) Received: by mail-oi0-f41.google.com with SMTP id z81so5158650oif.0 for ; Wed, 25 Feb 2015 11:11:11 -0800 (PST) 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 :content-type; bh=e86YXdQvlEzdiI50yKQrWaEORE/S3Fr8m+iR2haxKUw=; b=Sulqx5rhGAe0AX2dOb4uan/kXMa8WKNS1E+BSwC9EANHEEk7FXKlMqIu7m29Mj7oh8 6OCc1anhwKWnvyifw5p5xjkF8P72P+aEiU8Rav5bAX5yS2mRR8DHparfd6UiupHSuXVi 8F2EOoCuS0DhLlMlCuVxDDtrz3XFK9rATSnYz/uedX+Qq+5tLYdq5CGz+pHsZhpkDSDZ Mx7647B7Pyc6WS4GHfYlhlEHmuLYNy4Aov3Xa3i6aqdFpSjW+2s6vW7rZZ6uKtvw3Fbg Wao9PDjbvf6lFN+RGceLkAZDr5IAVEhuA9gHIkZZQ7aVPp8Xpy2/Q0N07xyqqx4n7VfZ 7ZXA== X-Gm-Message-State: ALoCoQmYkZ3scmHFv2AcYEhdO/DubrHg3dKrndKCywEkfZxk1HzmLnbjYeHHTcK6aWplUtfdHLaQ MIME-Version: 1.0 X-Received: by 10.60.78.72 with SMTP id z8mr3302108oew.13.1424891471142; Wed, 25 Feb 2015 11:11:11 -0800 (PST) Received: by 10.202.129.139 with HTTP; Wed, 25 Feb 2015 11:11:11 -0800 (PST) Date: Wed, 25 Feb 2015 13:11:11 -0600 Message-ID: From: Prasad Sanampudi To: netmod@ietf.org Content-Type: multipart/alternative; boundary=089e0111d7cafb5677050fee6577 Archived-At: Subject: [netmod] draft-ietf-netmod-acl-model-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 19:11:14 -0000 --089e0111d7cafb5677050fee6577 Content-Type: text/plain; charset=UTF-8 Hi, we like to use this draft for a proof of concept. I think, if you make the main definition of acl as a grouping, it can be used from external modules. for ex, with the following change to your draft: container access-lists { uses access-lists-group; } grouping access-lists-group { } ------- an external module can use it, like so ------- module y{ yang-version 1; namespace "http://www.x.com/y"; prefix y; import ietf-acl{ prefix ietfacl; } container c { uses ietfacl:access-lists-group; } } please let me know if there are other ways of using your definition in our models. thank you Prasad --089e0111d7cafb5677050fee6577 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
we like t= o use this draft for a proof of concept.

I think, if you make= the main definition of acl as a grouping, it can be used from external mod= ules.

for ex, with the following change to your draft:
cont= ainer access-lists {
=C2=A0=C2=A0=C2=A0=C2=A0 uses access-lists-group;}
grouping access-lists-group {
}

------- an external = module can use it, like so -------
module y{
=C2=A0=C2=A0=C2=A0 yang-= version 1;
=C2=A0=C2=A0=C2=A0 namespace "http://www.x.com/y";
=C2=A0=C2=A0=C2=A0 prefix y;
=C2= =A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 import ietf-acl{
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 prefix ietfacl;
=C2=A0=C2=A0=C2=A0 }
=C2= =A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 container c {
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 uses ietfacl:access-lists-group;=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 }
}


please let me know if there= are other ways of using your definition in our models.

thank= you
Prasad

--089e0111d7cafb5677050fee6577-- From nobody Wed Feb 25 18:28:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE541A8759 for ; Wed, 25 Feb 2015 18:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkLdK0mbmg5X for ; Wed, 25 Feb 2015 18:28:02 -0800 (PST) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (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 377841A1B03 for ; Wed, 25 Feb 2015 18:28:02 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id v63so6861010oia.13 for ; Wed, 25 Feb 2015 18:28:01 -0800 (PST) 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 :content-type; bh=iWySOI6c16WYdRj0Z+Q5CtJuBU8u5whNWcwNy+8JgKM=; b=hPG/DSpTZ9KgM95Tx32sP2sevRz3LQVb6sYi7+3JnrD88go7IZ50fILNJhMswd38/c XMlJrBWgEsmedDYsGkkYQ4XYO2Gxt8PmB9uFaqhVzTMiUxFSmm+88dYM1IG2pma1HFjp mICQu26VAj5UHbuCUAs/4IGIox4Ydp2s/j+4I+HVsXuOjDeLEj/jsAktEsMOhR6GSG7E kPHNY5+64H9vlnU+tL6eck6640yOp9M5Dgz8S9jtor8VE/1p7cIIX138ulKBczpBEtC0 UyujDSBSpD3jhbB206xGB1QVoZf1QbiYJU+Fpj1EzXMnJrKUbpFO8pJtyMa0V2Yqe/Gd oEXA== X-Gm-Message-State: ALoCoQlIZqH0G8IKLR1HAeLlfdm81cd9Y6j1SDNoHuBbj+4mmSqY0ZOc/Wu+cf98s5JEUctJop0B MIME-Version: 1.0 X-Received: by 10.60.79.10 with SMTP id f10mr3284951oex.8.1424917681530; Wed, 25 Feb 2015 18:28:01 -0800 (PST) Received: by 10.202.129.139 with HTTP; Wed, 25 Feb 2015 18:28:01 -0800 (PST) Date: Wed, 25 Feb 2015 20:28:01 -0600 Message-ID: From: Prasad Sanampudi To: netmod@ietf.org Content-Type: multipart/alternative; boundary=089e01227e903dfe60050ff4802d Archived-At: Subject: [netmod] how to reuse a container defined in a module b from module a X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 02:28:03 -0000 --089e01227e903dfe60050ff4802d Content-Type: text/plain; charset=UTF-8 hi, say, a module A defined a container , module A { container common { leaf foo { type string; } } } now, say I have a module B with a container module B { container x { } } if contianer B/x wants to hold A/common, is it possible ? I want the net effect to be the following B/x/foo should be valid. thank you Prasad --089e01227e903dfe60050ff4802d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
hi,

say, a module A defin= ed a container ,

module A {
container=C2=A0 com= mon {
=C2=A0=C2=A0 leaf foo {
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 type string;
=C2=A0=C2=A0 }
}
}

now, say I have a module B with a container

module B {<= br>
=C2=A0=C2=A0 container x {

=C2=A0=C2=A0 }
}
if contianer B/x wants to hold A/common, is it possible ?
I want the net effect to be the following
B/x/f= oo should be valid.

thank you
Prasad

--089e01227e903dfe60050ff4802d-- From nobody Wed Feb 25 19:14:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC2B1A7023 for ; Wed, 25 Feb 2015 19:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJS1WMh_JQQS for ; Wed, 25 Feb 2015 19:14:37 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BC31A0387 for ; Wed, 25 Feb 2015 19:14:36 -0800 (PST) Received: from BL2PR05CA0044.namprd05.prod.outlook.com (10.255.226.44) by BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) with Microsoft SMTP Server (TLS) id 15.1.93.16; Thu, 26 Feb 2015 03:14:18 +0000 Received: from BL2FFO11FD036.protection.gbl (2a01:111:f400:7c09::177) by BL2PR05CA0044.outlook.office365.com (2a01:111:e400:c04::44) with Microsoft SMTP Server (TLS) id 15.1.93.16 via Frontend Transport; Thu, 26 Feb 2015 03:14:18 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BL2FFO11FD036.mail.protection.outlook.com (10.173.161.132) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Thu, 26 Feb 2015 03:14:17 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 25 Feb 2015 19:14:16 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1Q3EFD68486; Wed, 25 Feb 2015 19:14:15 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t1Q3Dxpw024271; Wed, 25 Feb 2015 22:13:59 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502260313.t1Q3Dxpw024271@idle.juniper.net> To: Prasad Sanampudi In-Reply-To: Date: Wed, 25 Feb 2015 22:13:59 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(199003)(189002)(47776003)(46102003)(76506005)(53416004)(2950100001)(86362001)(64706001)(77096005)(68736005)(69596002)(6806004)(81156004)(92566002)(106466001)(62966003)(77156002)(54356999)(87936001)(105596002)(50986999)(48376002)(50466002)(97736003)(110136001)(129723002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB437; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB437; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BN1PR05MB437; X-Forefront-PRVS: 0499DAF22A X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB437; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2015 03:14:17.6887 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB437 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] how to reuse a container defined in a module b from module a X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 03:14:38 -0000 Prasad Sanampudi writes: >say, a module A defined a container , >module A { >container common { > leaf foo { > type string; > } >} >} >now, say I have a module B with a container >module B { > container x { > > } >} >if contianer B/x wants to hold A/common, is it possible ? > >I want the net effect to be the following >B/x/foo should be valid. IF A want's common to be reused, it needs to put it in a grouping, like: module A { grouping common { leaf foo { ... } } } module B { import A; container x { uses A:common; } } Thanks, Phil From nobody Wed Feb 25 19:39:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61C51A000E for ; Wed, 25 Feb 2015 19:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB-nQ1d6JE9i for ; Wed, 25 Feb 2015 19:39:31 -0800 (PST) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (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 492271A1B5E for ; Wed, 25 Feb 2015 19:39:25 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id i138so7134857oig.4 for ; Wed, 25 Feb 2015 19:39:24 -0800 (PST) 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:content-type; bh=UdPgpGy6nqXyzAizma/EZcQz4qrrlRsM6p94sfC51Xg=; b=HFEUCSGyzceZD+oRD8CVpgUZKXrgivzRFV5QMknmaTvsr6Y9keW1MQr1LvFyL/UqHR N1wQmXY4KgS4JM2JBu1ldd4ZRwKLNcAdqC3SJPFe6kJLqJJQs4tuMuEHP2k8urzWiTvz alAW8Q6iYXQzqUuz3JKknXOWmu57YVvOwtIYXN//l5enLYHzF6+IDr8qse19odIzcnwD vlD9cYST07bndf81zDL2DcZ2iuQID/kJf/FFRPW1oigO7uCDGRaj2oK13IDFqA6uYU6W G+5eMBddeM0BFX8Ix31dxQt0WiZ8KKAcAWrwHb0U5o3JnGD1kd6FbNM+cvatr0PUSp99 HJgA== X-Gm-Message-State: ALoCoQmi7r80bBMaOV9jPzPdu4NSNIt1qA5+QfcHfqkAPL3y2e7103K9s8MBHa0ySwmLnIEPDKRG MIME-Version: 1.0 X-Received: by 10.182.241.133 with SMTP id wi5mr4602537obc.10.1424921964710; Wed, 25 Feb 2015 19:39:24 -0800 (PST) Received: by 10.202.129.139 with HTTP; Wed, 25 Feb 2015 19:39:24 -0800 (PST) In-Reply-To: <201502260313.t1Q3Dxpw024271@idle.juniper.net> References: <201502260313.t1Q3Dxpw024271@idle.juniper.net> Date: Wed, 25 Feb 2015 21:39:24 -0600 Message-ID: From: Prasad Sanampudi To: Phil Shafer Content-Type: multipart/alternative; boundary=089e01634be88a261c050ff57fe8 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] how to reuse a container defined in a module b from module a X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 03:39:33 -0000 --089e01634be88a261c050ff57fe8 Content-Type: text/plain; charset=UTF-8 Thanks Phil. I am trying to improve my understanding of yang authoring. since, grouping promotes reuse, should yang authors use 'grouping' construct in yang models to promote reuse of their schema ? thanks Prasad On Wed, Feb 25, 2015 at 9:13 PM, Phil Shafer wrote: > Prasad Sanampudi writes: > >say, a module A defined a container , > >module A { > >container common { > > leaf foo { > > type string; > > } > >} > >} > >now, say I have a module B with a container > >module B { > > container x { > > > > } > >} > >if contianer B/x wants to hold A/common, is it possible ? > > > >I want the net effect to be the following > >B/x/foo should be valid. > > IF A want's common to be reused, it needs to put it in a grouping, like: > > module A { > grouping common { > leaf foo { ... } > } > } > > module B { > import A; > container x { > uses A:common; > } > } > > Thanks, > Phil > --089e01634be88a261c050ff57fe8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Phil.

I am trying to improv= e my understanding of yang authoring.
since, grouping promotes reuse, s= hould yang authors use 'grouping' construct in yang models to promo= te reuse of their schema ?

thanks
Prasad



On Wed, Feb 25, 2015 at 9:13 PM, Phil Shafer <phil@juniper.net>= wrote:
Prasad Sanampudi writes:
>say, a module A defined a container ,
>module A {
>container=C2=A0 common {
>=C2=A0 =C2=A0leaf foo {
>=C2=A0 =C2=A0 =C2=A0 type string;
>=C2=A0 =C2=A0}
>}
>}
>now, say I have a module B with a container
>module B {
>=C2=A0 =C2=A0container x {
>
>=C2=A0 =C2=A0}
>}
>if contianer B/x wants to hold A/common, is it possible ?
>
>I want the net effect to be the following
>B/x/foo should be valid.

IF A want's common to be reused, it needs to put it in a gr= ouping, like:

module A {
=C2=A0 =C2=A0 grouping common {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf foo { ... }
=C2=A0 =C2=A0 }
}

module B {
=C2=A0 =C2=A0 import A;
=C2=A0 =C2=A0 container x {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses A:common;
=C2=A0 =C2=A0 }
}

Thanks,
=C2=A0Phil

--089e01634be88a261c050ff57fe8-- From nobody Wed Feb 25 19:47:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866721A0AFE for ; Wed, 25 Feb 2015 19:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 603Vmb2zlSWB for ; Wed, 25 Feb 2015 19:47:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57D61A0A6A for ; Wed, 25 Feb 2015 19:47:44 -0800 (PST) Received: from BN1PR05MB438.namprd05.prod.outlook.com (10.141.58.12) by BN1PR05MB220.namprd05.prod.outlook.com (10.255.206.27) with Microsoft SMTP Server (TLS) id 15.1.93.16; Thu, 26 Feb 2015 03:47:25 +0000 Received: from BL2PR05CA0041.namprd05.prod.outlook.com (10.255.226.41) by BN1PR05MB438.namprd05.prod.outlook.com (10.141.58.12) with Microsoft SMTP Server (TLS) id 15.1.93.16; Thu, 26 Feb 2015 03:47:24 +0000 Received: from BN1BFFO11FD015.protection.gbl (2a01:111:f400:7c10::1:131) by BL2PR05CA0041.outlook.office365.com (2a01:111:e400:c04::41) with Microsoft SMTP Server (TLS) id 15.1.93.16 via Frontend Transport; Thu, 26 Feb 2015 03:47:24 +0000 Received: from P-EMF03-SAC.jnpr.net (66.129.239.17) by BN1BFFO11FD015.mail.protection.outlook.com (10.58.144.78) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Thu, 26 Feb 2015 03:47:23 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF03-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 25 Feb 2015 19:47:22 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t1Q3lLD86283; Wed, 25 Feb 2015 19:47:21 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t1Q3l6sn024410; Wed, 25 Feb 2015 22:47:07 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201502260347.t1Q3l6sn024410@idle.juniper.net> To: Prasad Sanampudi In-Reply-To: Date: Wed, 25 Feb 2015 22:47:06 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=phil@juniper.net; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(53416004)(97736003)(76506005)(87936001)(48376002)(50466002)(50986999)(64706001)(77156002)(69596002)(92566002)(110136001)(62966003)(6806004)(81156004)(106466001)(105596002)(54356999)(46102003)(86362001)(47776003)(558084003)(2950100001)(77096005)(68736005)(129723002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB438; H:P-EMF03-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB438; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:BN1PR05MB438; X-Forefront-PRVS: 0499DAF22A X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB438; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2015 03:47:23.6242 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB438 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB220; X-OriginatorOrg: juniper.net Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] how to reuse a container defined in a module b from module a X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 03:47:46 -0000 Prasad Sanampudi writes: >since, grouping promotes reuse, should yang authors use 'grouping' >construct in yang models to promote reuse of their schema ? When reasonable, definitely. Thanks, Phil From nobody Wed Feb 25 23:47:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A091A1AE8 for ; Wed, 25 Feb 2015 23:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KucsbKluVB-J for ; Wed, 25 Feb 2015 23:47:15 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4541A1AC7 for ; Wed, 25 Feb 2015 23:47:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D0D39102A; Thu, 26 Feb 2015 08:47:13 +0100 (CET) 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 7tG8st0tzncd; Thu, 26 Feb 2015 08:46:55 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 Feb 2015 08:47:13 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F12220036; Thu, 26 Feb 2015 08:47:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u2C_vcNp3Wma; Thu, 26 Feb 2015 08:47:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 322C520031; Thu, 26 Feb 2015 08:47:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8E49C3246337; Thu, 26 Feb 2015 08:47:08 +0100 (CET) Date: Thu, 26 Feb 2015 08:47:07 +0100 From: Juergen Schoenwaelder To: Prasad Sanampudi Message-ID: <20150226074707.GA31023@elstar.local> Mail-Followup-To: Prasad Sanampudi , netmod@ietf.org References: <201502260313.t1Q3Dxpw024271@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] how to reuse a container defined in a module b from module a X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2015 07:47:17 -0000 On Wed, Feb 25, 2015 at 09:39:24PM -0600, Prasad Sanampudi wrote: > Thanks Phil. > > I am trying to improve my understanding of yang authoring. > since, grouping promotes reuse, should yang authors use 'grouping' > construct in yang models to promote reuse of their schema ? > In principle yes but writing truly reusable groupings is not as easy as it sounds. Writing meaningful description clauses that work in several usage contexts is often more difficult than one might think. And of course, we likely do not want to encourage vendors to reuse standard models in their private namespaces instead of implementing the standard models in their official namespace. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 26 01:06:57 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172821A1BDF for ; Thu, 26 Feb 2015 01:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dAXnZxRFTce for ; Thu, 26 Feb 2015 01:06:52 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EFAC31A1B62 for ; Thu, 26 Feb 2015 01:06:51 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3F3691CC006E; Thu, 26 Feb 2015 10:07:00 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20150213212033.GA54556@elstar.local> <54DE848B.1080701@tail-f.com> <54EBAFA6.4050009@tail-f.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 26 Feb 2015 10:06:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 new solution Y25-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 09:06:55 -0000 Andy Bierman writes: > On Tue, Feb 24, 2015 at 4:49 AM, Ladislav Lhotka wrote: >> Per Hedeland writes: >> >>> On 2015-02-23 15:46, Ladislav Lhotka wrote: >>>> Per Hedeland writes: >>>> >>>>> On 2015-02-13 22:41, Andy Bierman wrote: >>>>>> On Fri, Feb 13, 2015 at 1:20 PM, Juergen Schoenwaelder >>>>>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Y25 (make enum numbering purely informative and optional) has been >>>>>>> discussed but no clear concensus has been reached so far. Y25-01 >>>>>>> proposes to remove the auto-numbering mechanism. With the appearance >>>>>>> of a CBOR encoding proposal [1], the numeric values may actually be >>>>>>> used on the wire. An alternative is to keep the auto-numbering >>>>>>> mechanism but to clarify the risks, this is what I have written up as >>>>>>> solution Y25-02: >>>>>>> >>>>>>> ** Solution Y25-02 >>>>>>> >>>>>>> Keep the auto-numbering procedure for enums and bits and add an >>>>>>> explicit warning that inserting enum definitions or reordering of >>>>>>> enum definitions very likely causes interoperability problem and >>>>>>> that explicit value assignments avoid this problem. >>>>>>> >>>>>> >>>>>> >>>>>> This is not really keeping the current procedure. >>>>>> Currently, the auto-numbering is mandatory, and sec 10. >>>>>> clearly prohibits changing any value or position statement. >>>>>> >>>>>> IMO Y25 should be declared DEAD and the YANG 1.0 behavior >>>>>> not changed at all. >>>>> >>>>> +1 >>>>> >>>>>> You are proposing that Sec. 10 be changed so renumbering is >>>>>> a warning, not a violation of the standard. >>>>> >>>>> Yes - and this is IMO clearly a non-backwards compatible change. The >>>>> "backwards compatible" requirement is extremely loosely specified by the >>>>> charter, i.e. "All compliant YANG 1.0 modules must be accepted as >>>>> compliant YANG 1.1 modules" - which if taken literally would allow for >>>>> anything that completely changes the semantics of a 1.0 module, as long >>>>> as it is still "accepted as compliant" in 1.1. This is clearly not what >>>>> anyone expects - the semantics should be unchanged, at least as long as >>>>> the 1.0 semantics are not clearly broken / unimplementable etc. >>>>> >>>>> RFC 6020 makes the promise to implementations that enum values are >>>>> stable as long as section 10 is adhered to. The suggested change breaks >>>>> this promise, thus it should be considered non-backwards compatible. >>>> >>>> What promise are you talking about? >>> >>> The auto-numbering procedure, together with the restriction in section >>> 10, guarantees that every enum will have an associated integer value >>> that doesn't change when the module is updated. >>> >>>> It is the enum *string* that is being >>>> exchanged in the protocol(s), so, strictly speaking, in the context of RFC >>>> 6020 there is no way for a NETCONF/RESTCONF peer to tell whether any >>>> implementation uses the auto-allocated values or not. >>> >>> Yes, this is not a protocol issue (yet), but ... >> >> And that's my point, it is neither a language nor a protocol issue, and >> therefore it doesn't belong to the specification. >> > > It will be a protocol issue soon. I don't think it is such a great idea, but if we allow an encoding to use the numbers rather than strings in the protocol, then of course this discussion becomes moot. Lada > Like tail-f, we also have customers who expect these mappings > to be permanent. They are often used in the firmware instead of > the strings. The spec clearly says these mappings are permanent. > Changing this mapping or removing the numbers altogether will > break YANG 1.0 implementations. > > >>> >>>> RFC 6020 also clearly says: "The value is unused by YANG and the XML >>>> encoding, ...". >>> >>> ... it goes on to say "... but is carried as a convenience to >>> implementors." I.e. being a "convenience to implementors" is the purpose >>> of the auto-numbering scheme and the section 10 restriction. >> >> The real convenience is that implementors can choose whatever numbering >> they like (or no numbering at all), there is no need that the numbering >> be the same at the sending and receiving side. >> >>> >>>> Of course, the situation changes if CBOR encoding chooses to use numeric >>>> values but I'd argue this wasn't the original intention, >>> >>> Agreed. >>> >>>> and so the >>>> motivation of the corresponding sec. 10 restriction remains unclear to >>>> me. >>> >>> See above. >>> >>>>> The motivations for making any change at all are also very dubious: >>>>> >>>>> 1. "This rule makes updates of enumerations difficult" >>>>> >>>>> Disregarding that "difficult" is a very subjective judgement, what >>>>> exactly is difficult about it? The only example that I have seen on >>>> >>>> This has already been discussed several times. Consider an enumeration such as >>>> ISO 3166 alpha-2 country codes: >>>> >>>> https://www.iso.org/obp/ui/#search >>>> >>>> It is sorted alphabetically, so new entries will most likely be added >>>> somewhere in the middle. This is impossible with auto-numbering, so >>>> currently the only solution would be to add a bogus number to each enum, >>>> which would make the module defining such an enumeration longer by 30 % >>>> or so. >>> >>> This can hardly be a significant concern for such a module. >>> >>>> What's your suggestion as to how such an enumeration should be set up and >>>> maintained? >>> >>> Same as for the time zone case, described below. If you are wondering >>> about the implementation of the auto-generating piece of software, it is >>> just a matter of parsing the previous version of the module to get the >>> existing value assignments, and make use of that information when >>> generating the new version. >> >> Of course, but I have always assumed *human readability* of YANG modules >> has the highest priority. And if the numbers are bogus, then they just add noise. >> > > > There are not really many cases where the list of enums is auto-generated > from an external source like IANA. Adding new enums/bits so they > do not change old numbers is usually quite easy. > >> I simply don't agree the touted "convenience to implementors" outweighs >> the inconvenience to readers of such modules and maintainers. YANG >> wouldn't be less usable if the auto-numbering procedure was removed. >> > > > IMO it was inevitable that a protocol would come along that used YANG > but still wanted to minimize bytes on the wire. NETCONF WG's apparent > lack of concern for message count or message size would not be shared > by other WGs. > > >>> >>> However, note that the message you are replying to, and specifically the >>> commentary on Y25-02, was due to a misunderstanding of Juergen's >>> proposal. Per subsequent messages, Y25-02 was not intended to suggest >>> any changes to the auto-numbering scheme or the section 10 >>> restriction. >>> And thus I support that proposal, although I made some suggestions for >>> a minor rewording. >> >> I don't agree changes to values/positions can lead to interoperability >> problems - unless we take the COMI decision to use these numbers in the >> protocol for granted. >> >> Lada >> > > > Andy > >>> >>> --Per >>> >>>> Lada >>>> >>>>> the mailing list is the infamous time zone case. This case revealed several >>>>> problems: >>>> >>>> >>>>> >>>>> a) The specification of the auto numbering procedure was unclear. This >>>>> has been addressed by errata 3871. >>>>> >>>>> b) No-one wanted to assume the responsibility of maintaining a standard >>>>> module specifying the enums, probably in no small part due to >>>>> >>>>> c) The maintainers of the time zone data were clearly opposed to having >>>>> any part of it turned into any kind of standard, due to the (additional) >>>>> political controversy this could lead to. >>>>> >>>>> However no technical or practical difficulty in maintaining a module for >>>>> these enums that adheres to section 10 has been demonstrated. In fact >>>>> assuming the obvious, that such a module would be auto-generated from >>>>> some free-form data, whether the raw timezone data or a simple list >>>>> (without any requirement on ordering) of identifiers, it is a very >>>>> trivial problem to solve. Martin already offered to provide a piece of >>>>> software to do that, I can do the same, but of course this particular >>>>> case is now moot. >>>>> >>>>> In the more typical case of a handful of manually assigned enums, >>>>> maintaining the numbering can't reasonably be considered difficult. >>>>> >>>>> 2. "and/or forces the data modeller to assign the values explicitly even >>>>> if they have no meaning otherwise." >>>>> >>>>> The only case where a data modeller would be *forced* to assign values >>>>> is that of removing an enum other than the "last" one, without adding >>>>> another to take its place. As far as I can see, removing enums is >>>>> already ruled out by section 10, and not a candidate for change. >>>>> >>>>> But obviously there are cases where some specific order of the enums is >>>>> more "natural" than others, and adhering to that order is likely to >>>>> improve readability, which is an important goal. Even in such a case >>>>> there is no need to assign values in the original version of the module, >>>>> but it may be needed on update if it is desired to add an enum "in the >>>>> middle" - but this is not being *forced*. (And readability can only be >>>>> an actual concern if the total set of enums is small, and then again it >>>>> can't reasonably be considered difficult to maintain the values.) >>>>> >>>>> 3. "The rule also contradicts the statement in Sec. 9.6.4.2 because the >>>>> value in fact is used by YANG." >>>>> >>>>> I disagree, the statement in 9.6.4.2 is accurate - the values aren't >>>>> *used* by YANG. YANG mereley puts some restrictions on them and provides >>>>> them to implementations. But if someone really feels strongly about >>>>> this, the obvious fix is to the text as s/YANG and// - not changing the >>>>> semantics. >>>>> >>>>> --Per Hedeland >>>>> >>>>>> Andy >>>>>> >>>>>>> The guidelines document may add further rules such that enum/bits >>>>>>> values must be explicitly defined in IETF modules (to be discussed >>>>>>> in the context of the guidelines document). >>>>>>> >>>>>>> [1] https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ >>>>>>> >>>>>>> -- >>>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>>>> Fax: +49 421 200 3103 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Feb 26 01:26:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B0C1A1BDF for ; Thu, 26 Feb 2015 01:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: 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-vPdv_vP3bE for ; Thu, 26 Feb 2015 01:26:50 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CA0841A0367 for ; Thu, 26 Feb 2015 01:26:49 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 159AC1CC006E; Thu, 26 Feb 2015 10:26:57 +0100 (CET) From: Ladislav Lhotka To: Phil Shafer , Juergen Schoenwaelder In-Reply-To: <201502241437.t1OEbgLZ010318@idle.juniper.net> References: <201502241437.t1OEbgLZ010318@idle.juniper.net> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 26 Feb 2015 10:26:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] VRFY :Y34: remove/deprecate/replace the 'anyxml' statement (2nd try) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 09:26:51 -0000 Phil Shafer writes: > Juergen Schoenwaelder writes: >>I do not buy this argument. Y34 is addressing issues that have >>surfaced with the usage of anyxml. Since we can't simple change the >>semantics of anyxml (for backwards compatibility reasons), the obvious >>solution is to create a replacement for the situations where "any data >>that can be defined in YANG is needed" and to discourage the usage of >>anyxml. > > I don't understand the need to discourage the use of anyxml. I > don't get why it suddenly became scary or dangerous. It's a chunk > of XML data, which is a useful datatype regardless of the encoding > scheme used to transport it. I agree that occasionally it might be needed to send schemaless on non-YANG data. If it's not HTML, it could be RDF or some other "legacy" stuff. It is true for XML and I think even more so for JSON these days. So my only problem with anyxml is the "xm"' in its name. I think nothing prevents a data modeller from restricting a *particular* anyxml node so that, e.g., the data has to correspond to a YANG model - known or unknown. Lada > > anyxml is simple and easy to understand. You may not like it or > want to use it, but it's concrete and well defined. > > In contrast, anydata implies something more intangible, where we > are saying that there's a chunk of data here that has a data model, > but you may not know what that model is. This implies that you may > or may not know how to marshal or unmarshal it, how to insert/delete/rename > data within it, etc. It's no longer a simple datatype. It's alive, > complex, and governed by unknown rules. Yes, the server understands > the data model (assumably), but it still seems wrong. > > Thanks, > Phil > > _______________________________________________ > 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 Feb 26 02:22:00 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E6E1A1EE8 for ; Thu, 26 Feb 2015 02:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_65=0.6] autolearn=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 UwvgZH7ei8XO for ; Thu, 26 Feb 2015 02:21:57 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id EC0061A1A31 for ; Thu, 26 Feb 2015 02:21:56 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 721C41CC0117; Thu, 26 Feb 2015 11:22:05 +0100 (CET) From: Ladislav Lhotka To: Balazs Lengyel , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: <54DB5A20.1030707@ericsson.com> References: <54DB5A20.1030707@ericsson.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 26 Feb 2015 11:21:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 10:21:59 -0000 Balazs Lengyel writes: > Solution Y57-01 > > Change to section 3: > > leaf-list: Like the leaf node but defines a set of uniquely identifiable > nodes rather than a single node. Each node has a value but no child nodes. > > change to > > leaf-list: Like the leaf node but defines a set of nodes rather than a > single node. Each node has a value but no child nodes. I think the term "node" as used here is confusing. According to sec. 3 in RFC 6020(bis), a leaf-list is in any case only a single "data node" or "schema node". Lada > > Change to section 4.2.2.2: > > A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf. > > What does this mean? Does it mean that leaf-lists need to have unique leafs? Change to: > > A leaf-list is a sequence of leaf nodes. > > Remove from section 7.7: > > The values in a leaf-list MUST be unique. > > Add to section 7.7.2: > > unique-leaf-list cardinality 0..1 > > Add a level 3 section before 7.7.6: > > 7.7.5b The unique-leaf-list Statement > > The "unique-leaf-list" statement takes as an argument the string "true" or "false". > If "unique-leaf-list" is "true", values within the leaf-lists must be unique. > If "unique-leaf-list" is "false", values within the leaf-lists may be repeated. > If "unique-leaf-list" is not specified, the default is true. > > Change section 7.7.7 > > The operations way of working is dependent on the value of unique-leaf-list. > If unique-leaf-list is true the current handling is unchanged. > If unique-leaf-list is false the following applies: > > delete/remove: delete/remove the addressed value (first occurence) from the > leaf-list. If a value exists multiple times in edit-config try to > delete 2/3/.. instances of the value. For delete it is an error if > insufficient value instances exist in datastore. > > create: create value. It succeeds even if value already exists, just adds the > value once more. If no "insert" attribute is present in the "create" operation, > it defaults to "last". If a value exists multiple times in edit-config repeat > the steps. > > replace, merge: For each specific value, the number of instances of the value > in edit-config and the datastore are matched against each other. > > For each such value instance if insert is not specified the value in the datastore is left unchanged. > > If the insert is specified, delete the (first/matching) value in the datastore, if > it exists, and re-create it as specified by > insert. If the insert attribute refers to a value, it is the first occurrence > of the value that is indicated. If a value exists multiple times in edit-config > repeat the steps. > > If edit-config contains more instances, the additional ones are created as > in a create operation. If the datastore contains more instances, they are not modified. > > ================================================================================================= > > > > > Position can be used to select a leaf in a leaf-list, but only if it is "ordered-by user". > For system-ordered lists this leads to error. (Same as insert) > > Position must be between 1 and the length of the leaf-list, if it is not, send an error message. > Indexing starts at 1 not 0, following XPATH conventions. > > In a delete/remove operation if position is specified, the value of the leaf-instance, has no effect, > it may be omitted by the client. (Addressing by position takes precedence over addressing by value.) > > If both the position and the value attributes are specified in edit-config for the same data node, > the value attribute has no effect and may be (should be) ommitted by the client. > > If position is specified, the insert attribute can only take the values after and before. First > and last are error. (There is no sense in specifying position once the insert=first/last is specified, > it would just add one more useless and complicated case.) > > Further changes to section 7.7.9: > > In an "ordered-by user" leaf-list, the attribute "position" in the YANG XML namespace (Section 5.3.1) > can be used to address specific values in the leaf-list. > > create: add: If position is specified but insert is not specified insert=after is implied. > > replace/merge: if position is specified but insert is not, replace the value specified by position. > If both position and insert=after/before is specified, insert a new leaf with the value at the specified position. (replace/merge works differntly with and without position.) > > _______________________________________________ > 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 Feb 26 08:28:09 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBFF1A90E1 for ; Thu, 26 Feb 2015 08:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: 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_UiGBxU5iMe for ; Thu, 26 Feb 2015 08:28:03 -0800 (PST) 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 0642F1A90AB for ; Thu, 26 Feb 2015 08:28:02 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-dd-54ef49905c3b Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B4.FC.04231.0994FE45; Thu, 26 Feb 2015 17:28:00 +0100 (CET) Received: from [159.107.197.114] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.210.2; Thu, 26 Feb 2015 17:27:59 +0100 Message-ID: <54EF498F.7060207@ericsson.com> Date: Thu, 26 Feb 2015 17:27:59 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ladislav Lhotka , Juergen Schoenwaelder , "netmod@ietf.org" References: <54DB5A20.1030707@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvje4Ez/chBj9fKltc3fiT0eLCqrls FvMvNrI6MHssWfKTyWPDAU+PTZfvMAYwR3HZpKTmZJalFunbJXBlzDv9kLHgF2/Fk38nmRoY z3J1MXJySAiYSCyc+ZoRwhaTuHBvPVsXIxeHkMARRokpC5uYQRJCAmsZJf5+SAKxeQW0JVZ+ 3wQWZxFQlVj99ToLiM0mYCQxtf88mC0qECUx+/wDVoh6QYmTM5+wgAwVEehglHjbeB0sISyg L/H0/V9GiAX+EpPnbQSLcwoYSJzc1wQU5+BgFrCXeLC1DCTMLCAvsf3tHKh7NCQeXvjLOoFR YBaSFbMQOmYh6VjAyLyKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzBMD275rbuDcfVrx0OM AhyMSjy8G/68CxFiTSwrrsw9xCjNwaIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6NDj7S/etBXjkyHZecPdPBPzjEVOxPQUmaVKRb+6c4qRTeZLfzl1e/X2cS82fp62afekGUW H9os3wry3c7Y1jVhf3Lr3AkrVcquL3+3QFRr4bZo3i7j3fMkEssvzFfhNjDb+VhfXLGhj42n 7+9HDv0Fu7SvXi1flXvf79Vc6a8LDqlUx/Man1RiKc5INNRiLipOBABE+XfiNAIAAA== Archived-At: Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 16:28:08 -0000 Hello Lada, This terminology is not new, it was not created by Y57. The terminology is not perfect in YANG 1.0 either. The problem is with data-node. "data node: A node in the schema tree that can be instantiated in a data tree. One of container, leaf, leaf-list, list, and anyxml." A single leaf in a leaf-list or a list-entry can be instantiated individual, but it is still the "collection" the list itself or the leaf-list that is listed as a data node. So we may need a new name for these piece of data leaf-list or a list-entry. My first proposal is that on better inspection I do not need to change chapter 3 at all for Y57. If we want to change it would you agree with: "leaf-list: Like the leaf node but while the leaf can have only a single value, a leaf-list can have multiple values at the same time. A leaf-list has zero, one or more values but no child nodes." Balazs On 2015-02-26 11:21, Ladislav Lhotka wrote: > Balazs Lengyel writes: >> Solution Y57-01 >> >> Change to section 3: >> >> leaf-list: Like the leaf node but defines a set of uniquely identifiable >> nodes rather than a single node. Each node has a value but no child nodes. >> >> change to >> >> leaf-list: Like the leaf node but defines a set of nodes rather than a >> single node. Each node has a value but no child nodes. > I think the term "node" as used here is confusing. According to sec. 3 > in RFC 6020(bis), a leaf-list is in any case only a single "data node" > or "schema node". > > Lada -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Feb 26 10:24:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC9C1AC3AB for ; Thu, 26 Feb 2015 10:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smPcwurLHtYj for ; Thu, 26 Feb 2015 10:24:08 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86F31AC3AC for ; Thu, 26 Feb 2015 10:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3996; q=dns/txt; s=iport; t=1424975049; x=1426184649; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=b5eK+TEe4krIklVLxk4pIAdSIgsF4vjzpMJb61pNo+M=; b=YV/WHcF0hpQVo1bfGPAYFpQ8OqzayZwoAIxNGG2OcFyCLqWeHLW2oXLx JZzt235aJWCyU8VkmqIc+qlpqxhcqKW+CZnDKUriVZalIG+zTGJBPoIix 0Ag9T/HjqL2My+sCUzLf3l7AseN/d33tUnmxwAVQJ1fc+PulI3n5vNPgx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B/BQB7Y+9U/xbLJq1bg1Ragwm5B4V3hXACgXEBAQEBAQF8hA8BAQEEI1URDw0DAQIKFgsCAgkDAgECATQHAggGDQYCAQEXiBQNvS+ZUgEBAQEBAQEBAQEBAQEBAQEBARYEixOBPYMgGAaCYoFDBY12hVmFZYZpjGAjgg+BYD0xAYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,654,1418083200"; d="scan'208,217";a="362186741" 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; 26 Feb 2015 18:24:07 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1QIO5Rw025753 for ; Thu, 26 Feb 2015 18:24:05 GMT Message-ID: <54EF64C5.9050005@cisco.com> Date: Thu, 26 Feb 2015 19:24:05 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: NETMOD Working Group References: <20150224170152.6224.60832.idtracker@ietfa.amsl.com> In-Reply-To: <20150224170152.6224.60832.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150224170152.6224.60832.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010201010509090705030404" Archived-At: Subject: [netmod] Fwd: IETF Hackathon at IETF 92, March 21-22, Dallas, TX X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 18:24:09 -0000 This is a multi-part message in MIME format. --------------010201010509090705030404 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit FYI. Regards, Benoit -------- Forwarded Message -------- Subject: IETF Hackathon at IETF 92, March 21-22, Dallas, TX Date: Tue, 24 Feb 2015 09:01:52 -0800 From: IETF Secretariat Reply-To: IETF Agenda To: IETF Announcement List CC: 92all@ietf.org, ietf@ietf.org The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. It takes place just before IETF 92, and it’s free and open to everyone. All you need is a knowledge of networking technologies, and you’ll be guaranteed to learn something new and have fun! Event details: https://developer.cisco.com/site/ietf-hackathon Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html --------------010201010509090705030404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit FYI.

Regards, Benoit


-------- Forwarded Message --------
Subject: IETF Hackathon at IETF 92, March 21-22, Dallas, TX
Date: Tue, 24 Feb 2015 09:01:52 -0800
From: IETF Secretariat <ietf-secretariat@ietf.org>
Reply-To: IETF Agenda <agenda@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: 92all@ietf.org, ietf@ietf.org 


The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. It takes place just before IETF 92, and it’s free and open to everyone.

All you need is a knowledge of networking technologies, and you’ll be guaranteed to learn something new and have fun!

Event details: https://developer.cisco.com/site/ietf-hackathon
Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html


--------------010201010509090705030404-- From nobody Thu Feb 26 10:56:30 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E6E1A005A for ; Thu, 26 Feb 2015 10:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 OR_zioC-ew6H for ; Thu, 26 Feb 2015 10:56:22 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id A813E1A00D0 for ; Thu, 26 Feb 2015 10:56:21 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 39F4D2F5969C; Thu, 26 Feb 2015 13:56:21 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5FA269A9-409D-44CF-97F2-9B02D203105E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <54EF64C5.9050005@cisco.com> Date: Thu, 26 Feb 2015 13:56:20 -0500 Message-Id: References: <20150224170152.6224.60832.idtracker@ietfa.amsl.com> <54EF64C5.9050005@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: IETF Hackathon at IETF 92, March 21-22, Dallas, TX X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 18:56:23 -0000 --Apple-Mail=_5FA269A9-409D-44CF-97F2-9B02D203105E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is BTW orthogonal to the Sunday Yang Advice Session (aka = Yangathon) that was already planned. =E2=80=94Tom > On Feb 26, 2015:1:24 PM, at 1:24 PM, Benoit Claise = wrote: >=20 > FYI. >=20 > Regards, Benoit >=20 >=20 > -------- Forwarded Message -------- > Subject: IETF Hackathon at IETF 92, March 21-22, Dallas, TX > Date: Tue, 24 Feb 2015 09:01:52 -0800 > From: IETF Secretariat = > Reply-To: IETF Agenda > To: IETF Announcement List = > CC: 92all@ietf.org , ietf@ietf.org = >=20 > The Internet Engineering Task Force (IETF) is holding a Hackathon to = encourage developers to discuss, collaborate and develop utilities, = ideas, sample code and solutions that show practical implementations of = IETF standards. It takes place just before IETF 92, and it=E2=80=99s = free and open to everyone. >=20 > All you need is a knowledge of networking technologies, and you=E2=80=99= ll be guaranteed to learn something new and have fun! >=20 > Event details: https://developer.cisco.com/site/ietf-hackathon = > Link to register: = https://www.ietf.org/meeting/92/hackathon-signup.html = >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_5FA269A9-409D-44CF-97F2-9B02D203105E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

This is = BTW orthogonal to the Sunday Yang Advice Session (aka Yangathon) that = was already planned.

= =E2=80=94Tom



On = Feb 26, 2015:1:24 PM, at 1:24 PM, Benoit Claise <bclaise@cisco.com> = wrote:

=20 =20
FYI.

Regards, Benoit


-------- Forwarded Message --------
Subject: IETF Hackathon at IETF 92, March 21-22, = Dallas, TX
Date: Tue, 24 Feb 2015 09:01:52 -0800
From: IETF Secretariat <ietf-secretariat@ietf.org>= ;
Reply-To: IETF Agenda <agenda@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org><= /td>
CC: 92all@ietf.org, ietf@ietf.org 


The Internet Engineering Task Force (IETF) is =
holding a Hackathon to encourage developers to discuss, collaborate and =
develop utilities, ideas, sample code and solutions that show practical =
implementations of IETF standards. It takes place just before IETF 92, =
and it=E2=80=99s free and open to everyone.

All you need is a knowledge of networking technologies, and you=E2=80=99ll=
 be guaranteed to learn something new and have fun!

Event details: https://developer=
.cisco.com/site/ietf-hackathon
Link to register: https://www=
.ietf.org/meeting/92/hackathon-signup.html


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

= --Apple-Mail=_5FA269A9-409D-44CF-97F2-9B02D203105E-- From nobody Thu Feb 26 11:17:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF6A1A0470 for ; Thu, 26 Feb 2015 11:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOhRCws37w58 for ; Thu, 26 Feb 2015 11:17:13 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51AA01A037D for ; Thu, 26 Feb 2015 11:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7978; q=dns/txt; s=iport; t=1424978234; x=1426187834; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=juOVjxArMzbNW5XD0cKORUXNiBkpGHgLAK6b8pje/S0=; b=dwLLaHTTWizUdH4debzdj6jPx2Dqxekbws++6DdSA0ZTX1nGgC105jsC 5MGmOzcpz0AzNHzK0wAIkuvqW3Ee9nnQEiunZAHDSSmJBFjeQMP7J3PRz 3veDh8z7dsdRw4L3GtY/G1YFEVOYVTMYLVwnyOTnr62QfBfKCe85L9Es5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A/BgBScO9U/xbLJq0ZAUGDVFqDCb50AQmFJ0kCgXEBAQEBAQF8hA8BAQEEAQEBIEsKARALEQMBAgEJFggDAgIJAwIBAgEVHwkIBg0BBQIBAReIFA2dLKATmV8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsTgT2DIBEHBoJigUMFk0+FZYZpjGAjgg+BYD0xAYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,654,1418083200"; d="scan'208,217";a="357492559" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 26 Feb 2015 19:17:11 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1QJHAle015587; Thu, 26 Feb 2015 19:17:10 GMT Message-ID: <54EF7136.4030001@cisco.com> Date: Thu, 26 Feb 2015 20:17:10 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Thomas D. Nadeau" References: <20150224170152.6224.60832.idtracker@ietfa.amsl.com> <54EF64C5.9050005@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090601050108070804050208" Archived-At: Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: IETF Hackathon at IETF 92, March 21-22, Dallas, TX X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 19:17:15 -0000 This is a multi-part message in MIME format. --------------090601050108070804050208 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yes, good point. Benoit > > This is BTW orthogonal to the Sunday Yang Advice Session (aka > Yangathon) that was already planned. > > —Tom > > > >> On Feb 26, 2015:1:24 PM, at 1:24 PM, Benoit Claise > > wrote: >> >> FYI. >> >> Regards, Benoit >> >> >> -------- Forwarded Message -------- >> Subject: IETF Hackathon at IETF 92, March 21-22, Dallas, TX >> Date: Tue, 24 Feb 2015 09:01:52 -0800 >> From: IETF Secretariat >> Reply-To: IETF Agenda >> To: IETF Announcement List >> CC: 92all@ietf.org, ietf@ietf.org >> >> >> >> The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. It takes place just before IETF 92, and it’s free and open to everyone. >> >> All you need is a knowledge of networking technologies, and you’ll be guaranteed to learn something new and have fun! >> >> Event details:https://developer.cisco.com/site/ietf-hackathon >> Link to register:https://www.ietf.org/meeting/92/hackathon-signup.html >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > --------------090601050108070804050208 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Yes, good point.

Benoit

This is BTW orthogonal to the Sunday Yang Advice Session (aka Yangathon) that was already planned.

—Tom



On Feb 26, 2015:1:24 PM, at 1:24 PM, Benoit Claise <bclaise@cisco.com> wrote:

FYI.

Regards, Benoit


-------- Forwarded Message --------
Subject: IETF Hackathon at IETF 92, March 21-22, Dallas, TX
Date: Tue, 24 Feb 2015 09:01:52 -0800
From: IETF Secretariat <ietf-secretariat@ietf.org>
Reply-To: IETF Agenda <agenda@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: 92all@ietf.org, ietf@ietf.org 


The Internet Engineering Task Force (IETF) is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. It takes place just before IETF 92, and it’s free and open to everyone.

All you need is a knowledge of networking technologies, and you’ll be guaranteed to learn something new and have fun!

Event details: https://developer.cisco.com/site/ietf-hackathon
Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html


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


--------------090601050108070804050208-- From nobody Fri Feb 27 03:56:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36351A92B1 for ; Fri, 27 Feb 2015 03:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCQuBmPljXDP for ; Fri, 27 Feb 2015 03:56:35 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2621A924C for ; Fri, 27 Feb 2015 03:56:35 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2C7D41CC0156; Fri, 27 Feb 2015 12:56:34 +0100 (CET) From: Ladislav Lhotka To: Balazs Lengyel , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: <54EF498F.7060207@ericsson.com> References: <54DB5A20.1030707@ericsson.com> <54EF498F.7060207@ericsson.com> User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 27 Feb 2015 12:56:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] Y57: non-unique leaf-list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 11:56:37 -0000 Balazs Lengyel writes: > Hello Lada, > This terminology is not new, it was not created by Y57. The terminology > is not perfect in YANG 1.0 either. The problem is with data-node. Yes, I know, and the cited formulations should IMO be improved in 6020bis in any case. Perhaps a new non-XML-centric term should be introduced for what is denoted as "element" in XML. How about "instance"? Lada > "data node: A node in the schema tree that can be instantiated in a data > tree. One of container, leaf, leaf-list, list, and anyxml." > A single leaf in a leaf-list or a list-entry can be instantiated > individual, but it is still the "collection" the list itself or the > leaf-list that is listed as a data node. So we may need a new name for > these piece of data leaf-list or a list-entry. > > > My first proposal is that on better inspection I do not need to change > chapter 3 at all for Y57. > > If we want to change it would you agree with: > "leaf-list: Like the leaf node but while the leaf can have only a single > value, a > leaf-list can have multiple values at the same time. > A leaf-list has zero, one or more values but no child nodes." > > Balazs > > On 2015-02-26 11:21, Ladislav Lhotka wrote: >> Balazs Lengyel writes: >>> Solution Y57-01 >>> >>> Change to section 3: >>> >>> leaf-list: Like the leaf node but defines a set of uniquely identifiable >>> nodes rather than a single node. Each node has a value but no child nodes. >>> >>> change to >>> >>> leaf-list: Like the leaf node but defines a set of nodes rather than a >>> single node. Each node has a value but no child nodes. >> I think the term "node" as used here is confusing. According to sec. 3 >> in RFC 6020(bis), a leaf-list is in any case only a single "data node" >> or "schema node". >> >> Lada > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Feb 27 10:42:37 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D810A1A874A for ; Fri, 27 Feb 2015 10:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d40anGSFSZrp for ; Fri, 27 Feb 2015 10:42:33 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9FC1A1E0B for ; Fri, 27 Feb 2015 10:42:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 346B8187A98; Fri, 27 Feb 2015 10:41:59 -0800 (PST) To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, tnadeau@lucidvision.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150227184159.346B8187A98@rfc-editor.org> Date: Fri, 27 Feb 2015 10:41:59 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, netmod@ietf.org, ccrusius@cisco.com Subject: [netmod] [Technical Errata Reported] RFC6020 (4282) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 18:42:35 -0000 The following errata report has been submitted for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4282 -------------------------------------- Type: Technical Reported by: Cesar Crusius Section: 12 Original Text ------------- unknown-statement = prefix ":" identifier [sep string] optsep (";" / "{" *unknown-statement2 "}") unknown-statement2 = [prefix ":"] identifier [sep string] optsep (";" / "{" *unknown-statement2 "}") Corrected Text -------------- unknown-statement = prefix ":" identifier [sep string] optsep (";" / "{" optsep *unknown-statement2 optsep "}") unknown-statement2 = [prefix ":"] identifier [sep string] optsep (";" / "{" optsep *unknown-statement2 optsep "}") Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Feb 27 15:23:46 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F21D1A1A40 for ; Fri, 27 Feb 2015 15:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.488 X-Spam-Level: ** X-Spam-Status: No, score=2.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 yqR-j1_J-DYp for ; Fri, 27 Feb 2015 15:23:44 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 604D51A1A39 for ; Fri, 27 Feb 2015 15:23:44 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id ED7C02F6F88C for ; Fri, 27 Feb 2015 18:23:43 -0500 (EST) From: Thomas D. Nadeau Content-Type: multipart/alternative; boundary="Apple-Mail=_1EFA6AB9-D249-4E9E-A741-C9FD3A9A8878" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Date: Fri, 27 Feb 2015 13:53:27 -0500 References: <7C52DD5B-33F7-44D1-A701-90254AAD7C12@lucidvision.com> To: NETMOD Working Group In-Reply-To: <7C52DD5B-33F7-44D1-A701-90254AAD7C12@lucidvision.com> X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2015 23:23:45 -0000 --Apple-Mail=_1EFA6AB9-D249-4E9E-A741-C9FD3A9A8878 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The Working Group Last call for this document has concluded.=20 Authors/editors, there were several comments made on the list. = Please address those ASAP and publish an update to the document. Please = inform the WG when the updates have been made so that the folks who made = comments can determine if their changes have been addressed. Thank you, =E2=80=94Tom > On Feb 6, 2015:1:59 PM, at 1:59 PM, Thomas D. Nadeau = > wrote: >=20 >=20 > This commences a NETMOD WG Last call for = draft-ietf-netmod-acl-model-01.txt. Please send comments to the list by = 20-FEB-2015 by 9AM EST. >=20 > Tom and Juergen, NETMOD WG Chairs >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_1EFA6AB9-D249-4E9E-A741-C9FD3A9A8878 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

The = Working Group Last call for this document has concluded. 

= Authors/editors, there were several comments made on the list. = Please address those ASAP and publish an update to the document. =  Please inform the WG when the updates have been made so that the = folks who made comments can determine if their changes have been = addressed.

Thank = you,

= =E2=80=94Tom


On Feb 6, 2015:1:59 PM, at 1:59 PM, Thomas D. = Nadeau <tnadeau@lucidvision.com> wrote:


This commences a NETMOD = WG Last call for draft-ietf-netmod-acl-model-01.txt.  Please send = comments to the list by 20-FEB-2015 by 9AM EST.

Tom and Juergen, NETMOD WG Chairs




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

= --Apple-Mail=_1EFA6AB9-D249-4E9E-A741-C9FD3A9A8878-- From ccrusius@cisco.com Fri Feb 27 17:27:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D095F1A1B20 for ; Fri, 27 Feb 2015 17:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zWx1af-A58m for ; Fri, 27 Feb 2015 17:27:10 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC681A1B1E for ; Fri, 27 Feb 2015 17:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2994; q=dns/txt; s=iport; t=1425086830; x=1426296430; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WEWm7Bz3DdrlgaUsatrvdnirSIsf1L12Gfy84C/7VJ4=; b=gUbqMNS8jo6QteQYn3vKdmCe5RXapuhwe+fQOYGVHUMLvrG0wqnR6ol7 eQ8CnKaNrcbIdsehywPzRJAi3CqJGRr2AkA+EqBrfgGB73VTD7M4pgDrR Wn54XSKyPCVQFFwzLNRaORDXWihOXMBuqGOuRFQm0DBBx1pieE/5Xe9sz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BOBwCLGPFU/4YNJK1BGoMCUloEgwa/GYVwAhyBCE0BAQEBAQF8hBABAQQjEUUQAgEIGgImAgICMBUQAgQBDQWILw03vEmZSgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYlxgT2CfjMHgmiBQwWFbooIiUWBGoMfglGMSSOCAg0PgVBvARGBMn8BAQE X-IronPort-AV: E=Sophos;i="5.09,664,1418083200"; d="scan'208";a="127723314" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 28 Feb 2015 01:27:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1S1R9J9000629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Feb 2015 01:27:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.153]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 19:27:09 -0600 From: "Cesar Crusius (ccrusius)" To: RFC Errata System , "mbj@tail-f.com" , "Benoit Claise (bclaise)" , "joelja@bogus.com" , "j.schoenwaelder@jacobs-university.de" , "tnadeau@lucidvision.com" Thread-Topic: [Technical Errata Reported] RFC6020 (4282) Thread-Index: AQHQUr0pdaC4e9BJO0O1/iGg52LRSZ0FI+QA Date: Sat, 28 Feb 2015 01:27:08 +0000 Message-ID: References: <20150227184159.346B8187A98@rfc-editor.org> In-Reply-To: <20150227184159.346B8187A98@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.250.144] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 27 Feb 2015 23:36:45 -0800 Cc: "netmod@ietf.org" Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (4282) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 03:53:33 -0000 VGhlcmUgaXMgYSBwcm9ibGVtIHdpdGggdGhpcyBlcnJhdGEgZHVlIHRvIGEgcGFzdGUgcHJvYmxl bSAocGFyZW50aGVzZXMNCmdvdCBzdHJpcHBlZCBvdXQpLiBXaGVyZSBpdCByZWFkcw0KDQoqdW5r bm93bl9zdGF0ZW1lbnQyIG9wdHNlcA0KDQpJdCBzaG91bGQgcmVhZA0KDQoqKHVua25vd25fc3Rh dGVtZW50MiBvcHRzZXApDQoNClRoYW5rcywNCg0KDQotIENlc2FyDQoNCk9uIDIvMjcvMTUsIDEw OjQxIEFNLCAiUkZDIEVycmF0YSBTeXN0ZW0iIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPg0K d3JvdGU6DQoNCj5UaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVk IGZvciBSRkM2MDIwLA0KPiJZQU5HIC0gQSBEYXRhIE1vZGVsaW5nIExhbmd1YWdlIGZvciB0aGUg TmV0d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sDQo+KE5FVENPTkYpIi4NCj4NCj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPllvdSBtYXkgcmV2aWV3IHRoZSByZXBv cnQgYmVsb3cgYW5kIGF0Og0KPmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJj aC5waHA/cmZjPTYwMjAmZWlkPTQyODINCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPlR5cGU6IFRlY2huaWNhbA0KPlJlcG9ydGVkIGJ5OiBDZXNhciBDcnVzaXVz IDxjY3J1c2l1c0BjaXNjby5jb20+DQo+DQo+U2VjdGlvbjogMTINCj4NCj5PcmlnaW5hbCBUZXh0 DQo+LS0tLS0tLS0tLS0tLQ0KPnVua25vd24tc3RhdGVtZW50ICAgPSBwcmVmaXggIjoiIGlkZW50 aWZpZXIgW3NlcCBzdHJpbmddIG9wdHNlcA0KPiAgICAgICAgICAgICAgICAgICAgICAoIjsiIC8g InsiICp1bmtub3duLXN0YXRlbWVudDIgIn0iKQ0KPnVua25vd24tc3RhdGVtZW50MiAgID0gW3By ZWZpeCAiOiJdIGlkZW50aWZpZXIgW3NlcCBzdHJpbmddIG9wdHNlcA0KPiAgICAgICAgICAgICAg ICAgICAgICAoIjsiIC8gInsiICp1bmtub3duLXN0YXRlbWVudDIgIn0iKQ0KPg0KPg0KPkNvcnJl Y3RlZCBUZXh0DQo+LS0tLS0tLS0tLS0tLS0NCj51bmtub3duLXN0YXRlbWVudCAgID0gcHJlZml4 ICI6IiBpZGVudGlmaWVyIFtzZXAgc3RyaW5nXSBvcHRzZXANCj4gICAgICAgICAgICAgICAgICAg ICAgKCI7IiAvICJ7IiBvcHRzZXAgKnVua25vd24tc3RhdGVtZW50MiBvcHRzZXAgIn0iKQ0KPnVu a25vd24tc3RhdGVtZW50MiAgID0gW3ByZWZpeCAiOiJdIGlkZW50aWZpZXIgW3NlcCBzdHJpbmdd IG9wdHNlcA0KPiAgICAgICAgICAgICAgICAgICAgICAoIjsiIC8gInsiIG9wdHNlcCAqdW5rbm93 bi1zdGF0ZW1lbnQyIG9wdHNlcCAifSIpDQo+DQo+DQo+Tm90ZXMNCj4tLS0tLQ0KPg0KPg0KPklu c3RydWN0aW9uczoNCj4tLS0tLS0tLS0tLS0tDQo+VGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBw b3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UNCj51c2UgIlJlcGx5IEFs bCIgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPnJlamVjdGVk LiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAoSUVTRykN Cj5jYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlm IG5lY2Vzc2FyeS4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PlJGQzYwMjAgKGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctMTMpDQo+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5UaXRsZSAgICAgICAgICAgICAgIDogWUFORyAtIEEgRGF0 YSBNb2RlbGluZyBMYW5ndWFnZSBmb3IgdGhlIE5ldHdvcmsNCj5Db25maWd1cmF0aW9uIFByb3Rv Y29sIChORVRDT05GKQ0KPlB1YmxpY2F0aW9uIERhdGUgICAgOiBPY3RvYmVyIDIwMTANCj5BdXRo b3IocykgICAgICAgICAgIDogTS4gQmpvcmtsdW5kLCBFZC4NCj5DYXRlZ29yeSAgICAgICAgICAg IDogUFJPUE9TRUQgU1RBTkRBUkQNCj5Tb3VyY2UgICAgICAgICAgICAgIDogTkVUQ09ORiBEYXRh IE1vZGVsaW5nIExhbmd1YWdlDQo+QXJlYSAgICAgICAgICAgICAgICA6IE9wZXJhdGlvbnMgYW5k IE1hbmFnZW1lbnQNCj5TdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KPlZlcmlmeWluZyBQYXJ0 eSAgICAgOiBJRVNHDQo+DQoNCg== From nobody Sat Feb 28 05:41:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36151A037D for ; Sat, 28 Feb 2015 05:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZUPepIIw0Act for ; Sat, 28 Feb 2015 05:41:38 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072721A0218 for ; Sat, 28 Feb 2015 05:41:38 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:1d47:c2ba:62ca:92ca] (unknown [IPv6:2a01:5e0:29:ffff:1d47:c2ba:62ca:92ca]) by mail.nic.cz (Postfix) with ESMTPSA id 94A6113FA24 for ; Sat, 28 Feb 2015 14:41:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1425130896; bh=ifMXnluZxxGWHwYfSbatRugWANJAbRdT0c3XwTQjX8o=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=NTR1xQWqkYMqA5nDFaaLOHEFmyTCwAxSEczjL+1Yl6H08Zw/fKYFuHHgOzTbV/jWO FZ8ZWFiKwslU+Qx4oLtGWtteCF+ezowq8+cgLBvzVj5/9ZENciieDbjdwhZi2HC8D5 PUsnLy5VtaUudqhpDmq0UV/997JuOocfySG+jU9g= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Feb 2015 14:41:36 +0100 References: <20150228133519.21412.69581.idtracker@ietfa.amsl.com> To: NETMOD Working Group Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-metadata-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 13:41:39 -0000 Hi, main changes in this revision are: o Encoding of annotations for anyxml nodes was changed to be the same as for leafs. This was necessary because anyxml value now needn't be an object. o It is stated that "md:annotation" statement defines only the syntax of an annotation. o Allowed "if-feature" as a substatement of "md:annotation". The conversion of annotations from XML to JSON and vice versa is now = fully supported in the development version of pyang: https://code.google.com/p/pyang/ (see the test/test_json directory for an example). Lada =20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: "Ladislav Lhotka" , "Ladislav Lhotka" = > Subject: New Version Notification for = draft-lhotka-netmod-yang-metadata-01.txt > Date: 28 Feb 2015 14:35:19 CET >=20 >=20 > A new version of I-D, draft-lhotka-netmod-yang-metadata-01.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Name: draft-lhotka-netmod-yang-metadata > Revision: 01 > Title: Defining and Using Metadata with YANG > Document date: 2015-02-28 > Group: Individual Submission > Pages: 15 > URL: = http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-metadata-01.t= xt > Status: = https://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-metadata/ > Htmlized: = http://tools.ietf.org/html/draft-lhotka-netmod-yang-metadata-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-lhotka-netmod-yang-metadata-01 >=20 > Abstract: > This document defines a YANG extension statement that allows for > defining the syntax of metadata annotions in YANG modules. The > document also specifies the XML and JSON encoding of annotations and > other rules for annotating instances of YANG data nodes. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sat Feb 28 14:09:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE241A001B; Sat, 28 Feb 2015 14:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGpDnAIdrwSx; Sat, 28 Feb 2015 14:09:41 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED271A001A; Sat, 28 Feb 2015 14:09:41 -0800 (PST) Received: from wonder.chopps.org (c-68-61-203-90.hsd1.mi.comcast.net [68.61.203.90]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8B1CF61E8E; Sat, 28 Feb 2015 22:09:40 +0000 (UTC) From: Christian Hopps Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Feb 2015 17:09:39 -0500 Message-Id: To: YANG Doctors Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2081\)) X-Mailer: Apple Mail (2.2081) Archived-At: Cc: NETMOD Working Group Subject: [netmod] question on leafref path. X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 22:09:43 -0000 Hi, I need to use a =E2=80=9Cpath=E2=80=9D in a leafref to refer to a router = id inside 1 of 2 possible containers. The 2 choices are =E2=80=9Cleft=E2=80= =9D or =E2=80=9Cright=E2=80=9D sides of a lambda. The lambda is = identified by the channel. I=E2=80=99ve tried the following with =E2=80=9C|=E2=80=9D (I believe = this is the valid xpath) and =E2=80=9C*=E2=80=9D (a guess) and neither = works.=20 //path = "../../../lambda[channel=3Dcurrent()/../channel]/left/router-id | = ../../../lambda[channel=3Dcurrent()/../channel]/right/router-id=E2=80=9D; path = "../../../lambda[channel=3Dcurrent()/../channel]/*/router-id=E2=80=9D; If I pick =E2=80=9Cleft=E2=80=9D or =E2=80=9Cright=E2=80=9D only it = works, but that=E2=80=99s not what I need. Any help on how to do this = properly? Thanks, Chris. The actual yang is below: list link { key "link-name"; leaf link-name { type inet:uri; } list lambda { key "channel"; leaf channel { type uint8; } container left { leaf router-id { type leafref { path "../../../../router/router-id"; } } } container right { leaf router-id { type leafref { path "../../../../router/router-id"; } } } } list site { key "site-id"; leaf site-id { type inet:uri; } list connection { key "channel"; leaf channel { type leafref { path "../../../lambda/channel"; } } // Is there a way to xpath refer to left or right containers = of the lambda? leaf router-id { type leafref { //path = "../../../lambda[channel=3Dcurrent()/../channel]/left/router-id | = ../../../lambda[channel=3Dcurrent()/../channel]/right/router-id"; path = "../../../lambda[channel=3Dcurrent()/../channel]/*/router-id"; } } } } From nobody Sat Feb 28 15:42:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B741A00A2 for ; Sat, 28 Feb 2015 15:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92SRQ1JbhZ42 for ; Sat, 28 Feb 2015 15:42:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id DF9031A009B for ; Sat, 28 Feb 2015 15:42:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D9FD5181D1B; Sat, 28 Feb 2015 15:41:22 -0800 (PST) To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, tnadeau@lucidvision.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150228234122.D9FD5181D1B@rfc-editor.org> Date: Sat, 28 Feb 2015 15:41:22 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, netmod@ietf.org, ccrusius@cisco.com Subject: [netmod] [Technical Errata Reported] RFC6020 (4283) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 23:42:02 -0000 The following errata report has been submitted for RFC6020, "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=4283 -------------------------------------- Type: Technical Reported by: Cesar Crusius Section: 12 Original Text ------------- stmtend = ";" / "{" *unknown_statement "}" Corrected Text -------------- stmtend = ";" / "{" stmtsep "}" Notes ----- As specified, there are no spaces allowed between the unknown statements, and between the braces and the unknown statements. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6020 (draft-ietf-netmod-yang-13) -------------------------------------- Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Publication Date : October 2010 Author(s) : M. Bjorklund, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG