From nobody Fri Jan 2 10:24:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2076B1A1E0F; Fri, 2 Jan 2015 10:24:18 -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 sLTJ1DXhsCY1; Fri, 2 Jan 2015 10:24:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A841A87C9; Fri, 2 Jan 2015 10:24:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150102182416.5437.34632.idtracker@ietfa.amsl.com> Date: Fri, 02 Jan 2015 10:24:16 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0Hnyj7c99EkPntGhNtDnhjw6nfw Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 18:24:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-ietf-netconf-yang-patch-02.txt Pages : 27 Date : 2015-01-02 Abstract: This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 2 11:55:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA11A6F1D for ; Fri, 2 Jan 2015 11:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, 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 RoUPjqi5wLin for ; Fri, 2 Jan 2015 11:55:34 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33891A6F15 for ; Fri, 2 Jan 2015 11:55:33 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so17162244lbj.27 for ; Fri, 02 Jan 2015 11:55:31 -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:cc:content-type; bh=bOzdZnWKu94qEGHtJFaluC0qQUgFObA3bTH7GuuyUiI=; b=cJwSXhZfKU/8srFgcf19gCCTq0BLoGTiyEY4ZW+dLUksMpUHy94g2blxdmW8BEITOG bCYgJpWg2VUih4t1ireSnkzyUvo2VMc0Fmc/Z1RUE2Zlsy1gPaffUURPAldarnYx0D6o 1DosXMGEZDiSKUY1ldoqe9jsDSOE+QOFr0QFDDwlEm73Ay8h8ZjEaQtNV/GBv9SlgIWQ wQ3L5aIkCqfCm6iaymNwQOFRpFLDUNQN8K+XMWQialb5Jx/5FtJiV5HNTHkm6k8etYrx FDqxjnWKXvbisP/dZtGRE/p0Xtt13eJR/EsZWUyTqrwvHwG50MXP/CANekDYRr73ZXfv yFDg== X-Gm-Message-State: ALoCoQk+6J+1yFV4cWndblC2XDbq0w5Rp3XsbDfohj0F2ykFGd7na8Nxg8BkstGDfZj5AN1oNK/y MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr54582919lbv.21.1420228531725; Fri, 02 Jan 2015 11:55:31 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 2 Jan 2015 11:55:31 -0800 (PST) In-Reply-To: <20150102182416.5437.34632.idtracker@ietfa.amsl.com> References: <20150102182416.5437.34632.idtracker@ietfa.amsl.com> Date: Fri, 2 Jan 2015 11:55:31 -0800 Message-ID: From: Andy Bierman Cc: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ChA6vGvXWcPXk_vLX3RApEyZKUY Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 19:55:35 -0000 Hi, Issue #1 has been addressed in this draft. The anyxml value node is required to contain a single child node corresponding to the target node object. Issue #2 is still open. If there is no agreement that #2 is a problem, then it will just be identified as an implementation issue in the draft. Andy On Fri, Jan 2, 2015 at 10:24 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of the IETF. > > Title : YANG Patch Media Type > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Rex Fernando > Filename : draft-ietf-netconf-yang-patch-02.txt > Pages : 27 > Date : 2015-01-02 > > Abstract: > This document describes a method for applying patches to NETCONF > datastores using data defined with the YANG data modeling language. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Jan 2 12:42:14 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557931A00EB for ; Fri, 2 Jan 2015 12:42:10 -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 UTYY1YRte1SW for ; Fri, 2 Jan 2015 12:42: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 98DD01A009E for ; Fri, 2 Jan 2015 12:42:08 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B1B41280098; Fri, 2 Jan 2015 21:42:07 +0100 (CET) Date: Fri, 02 Jan 2015 21:42:20 +0100 (CET) Message-Id: <20150102.214220.1710624933492775163.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: http://mailarchive.ietf.org/arch/msg/netconf/hE6dJW8dUNxkjMBOKKBiKUsNCdo Cc: netconf@ietf.org Subject: Re: [Netconf] YANG Patch #2: parsing QNames in value parameter anyxml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 20:42:10 -0000 Hi, I do not understand the problem in #2 - or rather, I think it is an implementation detail. The description says: The edit "value" node is encoded as YANG anyxml. If the content passed in this parameter contains qualified names, such as an identityref or instance-identifier data types, then the generic anyxml parser will ignore prefix information and simply parse a string node. The parser needs to know a specific node has QNames in the content or just guess that any string with a colon in it is a QName (not very robust). IMO, the parser needs to be schema aware. So first it parses the target parameter in order to find which node to modify. Then, using the schema for the target node, it can parse the value parameter. (The edit-config parser is just a specific case of this, with the target node being the root node of the datastore.) /martin From nobody Fri Jan 2 12:51:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E651A0451 for ; Fri, 2 Jan 2015 12:51:46 -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 vBRvJGaGStlC for ; Fri, 2 Jan 2015 12:51:45 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF83B1A0461 for ; Fri, 2 Jan 2015 12:51:42 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id z12so15543443lbi.18 for ; Fri, 02 Jan 2015 12:51: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=dApTNHoPLTsdItW62W7sU2zYs/0T3xiUaxy5LW8HCvE=; b=hludYucf1G58GkgaGY5e2ZNHRWb72Jv7d7EF/RZyY7tikzxvH1CEBo61TpVRuDe02Y o1jO4dLoMIarLfVdOl83MrODRG5YA1DtG/6vGGwBaUuZXKFUU3JGaTBAgv88x8YVL++a 146bLKqpCJI6bPX5cZKx6tmQ5tnTxLRQK3b4ABWN/ZIjzomggmFB4NW+vit/IhFQ7jEH ufXJ8lEKBn6c2QPDhdSotUf4Um0AEyiLERZ8ak12KwLHJmznqQOKYJlHjKBeW0+lz11K 67EF6YtB50DEhJKJh9a8E9wW2xbay7/4a6sO/f1JsE1F8Ir/jJoF1r9yVBOco8PW45wX lHiA== X-Gm-Message-State: ALoCoQmS/zoLz2FmOBulzjzjWItCAylIUec5X0miIdYQkMttMwiAEh39jG5beOKlqG6uhjIyJ5+K MIME-Version: 1.0 X-Received: by 10.112.85.11 with SMTP id d11mr78228780lbz.100.1420231901408; Fri, 02 Jan 2015 12:51:41 -0800 (PST) Received: by 10.112.77.231 with HTTP; Fri, 2 Jan 2015 12:51:41 -0800 (PST) In-Reply-To: <20150102.214220.1710624933492775163.mbj@tail-f.com> References: <20150102.214220.1710624933492775163.mbj@tail-f.com> Date: Fri, 2 Jan 2015 12:51:41 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/y6pIWJMuW3k0elTefJKvmpNQMPY Cc: Netconf Subject: Re: [Netconf] YANG Patch #2: parsing QNames in value parameter anyxml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 20:51:46 -0000 Hi, I think it is an implementation detail. The order within a JSON object is not required to have the target before the value. Another implementation detail. Andy On Fri, Jan 2, 2015 at 12:42 PM, Martin Bjorklund wrote: > Hi, > > I do not understand the problem in #2 - or rather, I think it is an > implementation detail. The description says: > > The edit "value" node is encoded as YANG anyxml. If the content > passed in this parameter contains qualified names, such as an > identityref or instance-identifier data types, then the generic > anyxml parser will ignore prefix information and simply parse a > string node. > > The parser needs to know a specific node has QNames in the content > or just guess that any string with a colon in it is a QName (not > very robust). > > IMO, the parser needs to be schema aware. So first it parses the > target parameter in order to find which node to modify. Then, using > the schema for the target node, it can parse the value parameter. > > (The edit-config parser is just a specific case of this, with the > target node being the root node of the datastore.) > > > /martin From nobody Fri Jan 2 12:55:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4909D1A0372 for ; Fri, 2 Jan 2015 12:55:10 -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 bOhC0UgR6HIQ for ; Fri, 2 Jan 2015 12:55: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 533621A00EB for ; Fri, 2 Jan 2015 12:55:09 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 9094D1280098; Fri, 2 Jan 2015 21:55:08 +0100 (CET) Date: Fri, 02 Jan 2015 21:55:21 +0100 (CET) Message-Id: <20150102.215521.1274734043096811743.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150102.214220.1710624933492775163.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: http://mailarchive.ietf.org/arch/msg/netconf/WO_vhDyfE-wryZ348vgMIdq7Gvo Cc: netconf@ietf.org Subject: Re: [Netconf] YANG Patch #2: parsing QNames in value parameter anyxml X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 20:55:10 -0000 Andy Bierman wrote: > Hi, > > I think it is an implementation detail. > > The order within a JSON object is not required to > have the target before the value. > Another implementation detail. Yep; requires buffering. /martin From nobody Sat Jan 3 06:58:20 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C2D1A8A6E for ; Sat, 3 Jan 2015 06:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 svMLZAJr4HHq for ; Sat, 3 Jan 2015 06:58:16 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C401A8A6D for ; Sat, 3 Jan 2015 06:58:15 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t03EwCCN014584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 3 Jan 2015 14:58:12 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t03EwAe0028227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 3 Jan 2015 15:58:12 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 3 Jan 2015 15:58:10 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Sat, 3 Jan 2015 15:58:09 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: Agenda of the NETCONF Virtual Interim Meeting on January 5, 2015 1700-1900 UTC Thread-Index: AQHQE99GZrTFXkVgekeUGdFhdQWh7Jyuk4wg Date: Sat, 3 Jan 2015 14:58:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2523 X-purgate-ID: 151667::1420297092-00002DC5-9AA2A8C8/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WhiHLQsU9cc-cUs9k8FRb2J_jIE Subject: [Netconf] Agenda of the NETCONF Virtual Interim Meeting on January 5, 2015 1700-1900 UTC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 14:58:18 -0000 Dear NETCONF WG, please find below the agenda of the NETCONF virtual interim meeting on Janu= ary 5, 2015 1700-1900 UTC and the access information for the meeting. I would like to invite all WG members to participate in the meeting and the= issue discussion. Based on the discussion result and preparation, we will start the WGLC for = some of the WG items. Agenda of the virtual interim meeting on December 15, 2014 1700-1900 UTC ---------------------------------------------------------------------------= ---------- Agenda is also available at:=20 http://www.ietf.org/proceedings/interim/2015/01/05/netconf/agenda/agenda-in= terim-2015-netconf-1=20 - 5 min chair intro, scribe, agenda bashing The notes will be taken on: http://beta.etherpad.org/p/netconf-Jan05 =20 Issue discussion per WG item: - Call Home (Kent) (10min) Currently 3 open issues. See https://github.com/netconf-wg/call-home/issues =20 - Server Model (Kent) (20min) Currently 4 open issues. See https://github.com/netconf-wg/server-model/issues - rfc5539bis (Juergen) (5min) No open issues. - Restconf/YANG Patch (Andy) (40min) Currently 9/2 open issues. https://github.com/netconf-wg/restconf/issues =20 https://github.com/netconf-wg/yang-patch/issues - Zerotouch (Kent) (30min) Currently 2 open issues. See https://github.com/netconf-wg/yang-patch/issues - 5 min AOB other topics Best Regards, Mehmet & Mahesh -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext IESG Secre= tary Sent: Monday, December 01, 2014 10:05 PM To: IETF Announcement List Cc: netconf@ietf.org Subject: [Netconf] NETCONF WG Virtual Interim Meetings December 15, 2014, a= nd bi-weekly starting January 5, 2015 The NETCONF WG will hold a series of virtual interim meetings beginning Mon= day, December 15, 2014. Meeting day: Mondays Time: 1700 UTC - 1800 CET Duration: 2 hours Starting with: January 5, 2015 bi-weekly End date: March 16, 2015 WebEx information: Access code: 640 672 878 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm2580594e0bc14b4b94f= 869a415ce437c=20 Meeting number: 640 672 878 Meeting password: nc2015 Use Webex audio or audio connection: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Jan 4 11:00:42 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3E41A1BCB for ; Sun, 4 Jan 2015 11:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 GZbRuoUfdfGE for ; Sun, 4 Jan 2015 11:00:36 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5A01A014D for ; Sun, 4 Jan 2015 11:00:35 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t04J0NC0029278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 19:00:24 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t04J0NbK028933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Jan 2015 20:00:23 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0195.001; Sun, 4 Jan 2015 20:00:23 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Rohit R Ranade , "netconf@ietf.org" Thread-Topic: Notification updation RFC 5277 Thread-Index: AdAdmGPAceznqgnXSje9O6PD47W4GwKspEgg Date: Sun, 4 Jan 2015 19:00:23 +0000 Message-ID: References: <991B70D8B4112A4699D5C00DDBBF878A671DA5FC@szxeml512-mbs.china.huawei.com> In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A671DA5FC@szxeml512-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.114] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8195A665CDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 27335 X-purgate-ID: 151667::1420398024-00001177-4DAB11BC/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/G544Zv5dBQGsbD9aIW1dYPxSByQ Subject: Re: [Netconf] Notification updation RFC 5277 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:00:41 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195A665CDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Rohit, can you elaborate in which scenario you need to modify a notification subsc= ription? Regards, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Rohit R Ra= nade Sent: Monday, December 22, 2014 4:36 AM To: netconf@ietf.org Subject: [Netconf] Notification updation RFC 5277 Hello, RFC 5277 clearly states that subscriptions cannot be updated. Is there some= reason for it ? I have a scenario, where subscriptions can get added and d= eleted. Is there some mechanism to update subscription ? With Regards, Rohit --_000_E4DE949E6CE3E34993A2FF8AE79131F8195A665CDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Rohit,

 

can you elaborate in which= scenario you need to modify a notification subscription?=

 

Regards,
Mehmet

 

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Rohit R Ranade
Sent: Monday, December 22, 2014 4:36 AM
To: netconf@ietf.org
Subject: [Netconf] Notification updation RFC 5277<= /p>

 

Hello,

 

RFC 5277 clearly states that subscriptions cannot be= updated. Is there some reason for it ? I have a scenario, where subscripti= ons can get added and deleted.

Is there some mechanism to update subscription ?

 

With Regards,

Rohit

--_000_E4DE949E6CE3E34993A2FF8AE79131F8195A665CDEMUMBX005nsnin_-- From nobody Sun Jan 4 11:00:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7B51A8A53 for ; Sun, 4 Jan 2015 11:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 iXKgwJQ8v4N6 for ; Sun, 4 Jan 2015 11:00:42 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4191A1B82 for ; Sun, 4 Jan 2015 11:00:39 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t04J0cCH029470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 19:00:38 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t04J0b2f025675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Jan 2015 20:00:37 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Sun, 4 Jan 2015 20:00:37 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Andy Bierman , Kent Watsen Thread-Topic: [Netconf] zerotouch-02 configuration server issues Thread-Index: AQHQG6Q28nAoW9Pevk+8t4ynBsdkz5yXTvAAgAAITYCAGQRY8A== Date: Sun, 4 Jan 2015 19:00:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3971 X-purgate-ID: 151667::1420398038-00001177-7A374390/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7jRhM1qVD951e5gBCpzHTAHbMss Cc: Netconf Subject: Re: [Netconf] zerotouch-02 configuration server issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:00:44 -0000 Hi Kent, is there a strong reason for not using YANG (instead of XSD)? I assume we can solve the "container" issue raised for YANG usage. Cheers,=20 Mehmet=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bie= rman > Sent: Friday, December 19, 2014 10:06 PM > To: Kent Watsen > Cc: Netconf > Subject: Re: [Netconf] zerotouch-02 configuration server issues >=20 > On Fri, Dec 19, 2014 at 12:36 PM, Kent Watsen wrote= : > > Hi Andy, > > > > > > > >>The configuration server described in sec. 2 is going to be > >>an important system component if it is successfully standardized. > > > > True. > > > > > > > >>I do not like the XSD for the configlet. > >>It reminds me why we invented YANG in the first place. > >>(Oh yeah, XSD is unreadable. Almost forgot ;-) > > > > We had YANG in the -00 version of this draft, it changed to XSD in the > > -01 version. Btw, -02 hasn't been posted yet, though you reference it > > in the subject line. > > >=20 > typo on my part. >=20 >=20 > > In addition to side-stepping the whole debate regarding the use of a YA= NG > > "container", the draft simultaneously moved to definitively using XML, = due > > to the use of the XMLSIG and XMLENC standards. Do you think this is to= o > > onerous? Should we track this as an issue? > > > > >=20 > I guess XSD is OK. It avoids the YANG data structure controversy an > excludes JSON (which nay be a new controversy ;-) >=20 >=20 > > > >>The configlets are completely opaque, except there are 2 header fields > >>"unique-identifier" and "software-version". There is nothing identifyi= ng > >>the configuration blob. I think "configuration-identifier" and > >>"configuration-version" fields are also needed. > >> >=20 >=20 > Do you agree these extra fields are useful? > IMO they could be optional. >=20 > Some use cases: > - the identified device may have different config setups, based > on factors such as licenses, device capabilities, etc. so > "config-identifier" could identify the config variant > - cache IDs such as "config-id" (defined in NETCONF-EX) could be mapped > to the "config-version" field, or a revision-date could be used instea= d. >=20 >=20 > >>I would prefer a more direct mapping to YANG for the "configuration" > >>element. > >>It should be possible to have a "vendor-opaque" section, > >>but it would be nice to know if subtrees in the configlet > >>actually show up in the running config after booting. > >>The description in the XSD implies that, but nothing normative. > > > > We had something like this back in Feb when the draft was still an I.D. > > [1]. See how the YANG imports "ietf-netconf-server" and copies select= ed > > parts of the "ietf-system" module? But you're saying that it's OK for > > there to be vendor-opqaue values - so do you want the draft to say the > > content of the Configlet MUST/SHOULD have a configuration that maps to > > these ietf-netconf-server and ietf-system models? > > >=20 >=20 >=20 > I would prefer if the configuration element was equivalent to > the element in a operation. > There is no constraint on what YANG modules are present. > Whatever config is present must match YANG module schema > supported by the server. >=20 > I do not know if there is a need for additional XML in the configlet > that does not map to any advertised YANG module. Phil mentioned > a need for this sort of bootstrap data at IETF #91. This should > go in a different element within the configlet. >=20 >=20 > > [1] https://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01 > > > > > > > > Thanks, > > Kent > > > > >=20 >=20 >=20 > Andy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Jan 4 11:01:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7171A014D for ; Sun, 4 Jan 2015 11:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Afr7uTAwfeY8 for ; Sun, 4 Jan 2015 11:01:03 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD631A1BCB for ; Sun, 4 Jan 2015 11:01:02 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t04J10wT029785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 19:01:00 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t04J10mO025932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Jan 2015 20:01:00 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 4 Jan 2015 20:01:00 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Sun, 4 Jan 2015 20:01:00 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Andy Bierman Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-02.txt Thread-Index: AQHQJsYYOgJThnxYs0CKWxoaD6i+YZywQwSg Date: Sun, 4 Jan 2015 19:00:59 +0000 Message-ID: References: <20150102182416.5437.34632.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2702 X-purgate-ID: 151667::1420398060-00001177-03303985/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/sT2VYAA0Q-OnZi4VH8Ugk1vhy4M Cc: Netconf Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:01:05 -0000 Hi All, yang-patch issues #1 and #2 are going to be closed as proposed below. Please speak up by January 8 if you have any strong objections. Regards,=20 Mehmet=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bie= rman > Sent: Friday, January 02, 2015 8:56 PM > Cc: Netconf > Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-02.txt >=20 > Hi, >=20 > Issue #1 has been addressed in this draft. > The anyxml value node is required to contain a single child node > corresponding to the target node object. >=20 > Issue #2 is still open. If there is no agreement that #2 is a problem, > then it will just be identified as an implementation issue in the draft. >=20 >=20 > Andy >=20 >=20 >=20 > On Fri, Jan 2, 2015 at 10:24 AM, wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Network Configuration Working Group o= f the IETF. > > > > Title : YANG Patch Media Type > > Authors : Andy Bierman > > Martin Bjorklund > > Kent Watsen > > Rex Fernando > > Filename : draft-ietf-netconf-yang-patch-02.txt > > Pages : 27 > > Date : 2015-01-02 > > > > Abstract: > > This document describes a method for applying patches to NETCONF > > datastores using data defined with the YANG data modeling language. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-yang-patch-02 > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Jan 4 11:01:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A859A1A1B82 for ; Sun, 4 Jan 2015 11:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_HI=-5, 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_AIAinDbIs9 for ; Sun, 4 Jan 2015 11:01:27 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EB91A014D for ; Sun, 4 Jan 2015 11:01:22 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t04J1Lwd030117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 19:01:21 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t04J1Kml026245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Jan 2015 20:01:20 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Sun, 4 Jan 2015 20:01:20 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Andy Bierman , Ladislav Lhotka Thread-Topic: [Netconf] RESTCONF #15: usage of groupings Thread-Index: AQHQHgoMU6xQrWaea0exojqIsjbvnJywSmng Date: Sun, 4 Jan 2015 19:01:19 +0000 Message-ID: References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.114] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7806 X-purgate-ID: 151667::1420398081-00001177-7B95CCC4/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4fcQkoE-09GYq5yWA0pblUKw7oA Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:01:35 -0000 SGkgQWxsLA0KDQp3ZSBkaWQgbm90IHNlZSBhbnkgY29tbWVudHMgb24gQW5keSdzIHByb3Bvc2Vk IHNvbHV0aW9uIG9uIEdpdGh1YiBzaW5jZSAyIHdlZWtzLg0KVGhpcyBpc3N1ZSBpcyBzdWJqZWN0 IHRvIGNsb3NlLg0KDQpNZWhtZXQgDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgZXh0IEFuZHkgQmllcm1hbg0KPiBTZW50OiBNb25kYXksIERlY2VtYmVyIDIyLCAyMDE0 IDY6MDkgUE0NCj4gVG86IExhZGlzbGF2IExob3RrYQ0KPiBDYzogTmV0Y29uZg0KPiBTdWJqZWN0 OiBSZTogW05ldGNvbmZdIFJFU1RDT05GICMxNTogdXNhZ2Ugb2YgZ3JvdXBpbmdzDQo+IA0KPiBI aSwNCj4gDQo+IEkgdXBkYXRlZCB0aGUgaXNzdWUgdHJhY2tlciB3aXRoIHRoZSBjb25jcmV0ZSBw cm9wb3NhbCBmb3INCj4gaWV0Zi1yZXN0Y29uZiBncm91cGluZ3MuDQo+IA0KPiBodHRwczovL2dp dGh1Yi5jb20vbmV0Y29uZi13Zy9yZXN0Y29uZi9pc3N1ZXMvMTUNCj4gDQo+IEkgZm9yZ290IHRv IG1lbnRpb24gdGhhdCBpZXRmLXlhbmctcGF0Y2gueWFuZyBhbHJlYWR5IHVzZXMgdGhlICJlcnJv cnMiIGdyb3VwaW5nDQo+IHdpdGhpbiB0aGUgcnBjIG91dHB1dCBwYXJhbWV0ZXJzLCBzbyByZW1v dmluZyBpdCB3aWxsIGJyZWFrIFlBTkcgUGF0Y2guDQo+IA0KPiBBbmR5DQo+IA0KPiANCj4gT24g TW9uLCBEZWMgMTUsIDIwMTQgYXQgMTA6NDkgQU0sIExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5p Yy5jej4gd3JvdGU6DQo+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyaXRl czoNCj4gPg0KPiA+PiBPbiBUaHUsIERlYyAxMSwgMjAxNCBhdCA0OjQ4IEFNLCBNYXJ0aW4gQmpv cmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+ID4+PiBMYWRpc2xhdiBMaG90a2EgPGxo b3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+Pj4+DQo+ID4+Pj4gPiBPbiAxMSBEZWMgMjAxNCwgYXQg MTI6NDksIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+PiA+ DQo+ID4+Pj4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+Pj4+ ID4+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3cml0ZXM6DQo+ID4+Pj4gPj4N Cj4gPj4+PiA+Pj4gSGksDQo+ID4+Pj4gPj4+DQo+ID4+Pj4gPj4+IEEgbmV3IGlzc3VlIGhhcyBi ZWVuIGFkZGVkIHRvIHRoZSB0cmFja2VyOg0KPiA+Pj4+ID4+Pg0KPiA+Pj4+ID4+PiBodHRwczov L2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9yZXN0Y29uZi9pc3N1ZXMvMTUNCj4gPj4+PiA+Pj4NCj4g Pj4+PiA+Pj4gVGhlcmUgYXJlIDMgc29sdXRpb25zIG1lbnRpb25lZC4NCj4gPj4+PiA+Pj4gVGhl IGRlZmF1bHQgc29sdXRpb24gaXMgUzEsIHdoaWNoIHdpbGwgYmUgaW1wbGVtZW50ZWQNCj4gPj4+ PiA+Pj4gdW5sZXNzIHRoZXJlIGlzIFdHIGNvbnNlbnN1cyBkZW1vbnN0cmF0ZWQgdG8NCj4gPj4+ PiA+Pj4gZG8gc29tZXRoaW5nIGVsc2UuDQo+ID4+Pj4gPj4NCj4gPj4+PiA+PiBUaGUgYmlnZ2Vz dCBwcm9ibGVtIHdpdGggUzEgaXMgdGhhdCBpdCBtYXkgbWlzbGVhZCByZWFkZXJzIGludG8NCj4g Pj4+PiA+PiB0aGlua2luZzogIkhleSwgbm93IEkgdW5kZXJzdGFuZCBob3cgbmFtZXNwYWNlcyB3 b3JrIGluIGdyb3VwaW5ncyEiDQo+ID4+Pj4gPj4NCj4gPj4+PiA+PiBJIGFsc28gZG9uJ3QgbGlr ZSB0aGUgaWRlYSBvZiBkZWZpbmluZyBhbiBhZCBob2MgZXh0ZW5zaW9uLg0KPiA+Pj4+ID4NCj4g Pj4+PiA+IEkgZGlzYWdyZWUuICBJIHRoaW5rIGFuIGV4dGVuc2lvbiBpcyB0aGUgYmVzdCBzb2x1 dGlvbiBpbiB0aGlzIGNhc2UuDQo+ID4+Pj4gPiBIb3dldmVyLCB3ZSBjYW4gdXNlIGEgZGlmZmVy ZW50IG5hbWUgdGhhbiAnc3RydWN0dXJlJy4gICdzdHJ1Y3R1cmUnDQo+ID4+Pj4gPiB3YXMgb3Jp Z2luYWxseSBteSBwcm9wb3NhbCBmb3IgYSBidWlsdC1pbiBzdGF0ZW1lbnQgKFlBTkcgMS4xKSBm b3INCj4gPj4+PiA+IHRoaXMgcHVycG9zZS4gIFdlIGNhbiBjYWxsIGl0ICdyZXN0Y29uZi1zdHJ1 Y3R1cmUnIG9yICdyZXN0Y29uZi1kYXRhJw0KPiA+Pj4+ID4gb3Igc29tZXRoaW5nLg0KPiA+Pj4+ DQo+ID4+Pj4gU28gYW5vdGhlciBkb2N1bWVudCB0aGF0IHdhbnRzIHRvIGRvIHRoZSBzYW1lIHNo b3VsZCBkZWZpbmUgaXRzIG93biBhZA0KPiA+Pj4+IGhvYyBleHRlbnNpb24/IE9yIGltcG9ydCB0 aGUgaWV0Zi1yZXN0Y29uZiBtb2R1bGU/DQo+ID4+Pg0KPiA+Pj4gU3VwcG9zZSB3ZSBtYWtlIGEg bmV3IGRvY3VtZW50IHRoYXQgZGVmaW5lcyBhIG5ldyBSRVNUQ09ORiByZXNvdXJjZQ0KPiA+Pj4g dHlwZSwgYW5kIHdlIG5lZWQgYSBzdHJ1Y3R1cmUgZm9yIGl0LCB0aGVuIHRoYXQgZG9jdW1lbnQg d291bGQgaW1wb3J0DQo+ID4+PiBhbmQgdXNlICdyZXN0Y29uZi1zdHJ1Y3R1cmUnLg0KPiA+Pj4N Cj4gPj4+PiA+PiBJZiB3ZSB3YW50DQo+ID4+Pj4gPj4gdG8gdHVybiBZQU5HIGludG8gYSBnZW5l cmFsIHNjaGVtYSBsYW5ndWFnZSwgaXQgc2hvdWxkIGJlIGRvbmUNCj4gPj4+PiA+PiBwcm9wZXJs eS4NCj4gPj4+PiA+Pg0KPiA+Pj4+ID4+IEkgdGhpbmsgdGhlIHNpbXBsZXN0IHNvbHV0aW9uIHdv dWxkIGJlIHRvIHJlbW92ZSB0aGUgZ3JvdXBpbmdzIGFuZA0KPiA+Pj4+ID4+IGhhdmUNCj4gPj4+ PiA+PiAiZXJyb3JzIiwgInJlc3Rjb25mIiwgImNvbGxlY3Rpb24iIGFuZCAibm90aWZpY2F0aW9u IiBhcyB0b3AtbGV2ZWwNCj4gPj4+PiA+PiBjb250YWluZXJzLiBUaGUgbmFtZXNwYWNlIGFzc2ln bm1lbnQgdGhlbiBmb2xsb3dzIFlBTkcgcnVsZXMuDQo+ID4+Pj4gPg0KPiA+Pj4+ID4gVGhpcyBp cyBhbHNvIF92ZXJ5XyBtaXNsZWFkaW5nLCBiL2MgdGhlbiBpdCBsb29rcyBsaWtlIGEgbm9ybWFs IGNvbmZpZw0KPiA+Pj4+ID4gb3Igc3RhdGUgbW9kdWxlLCB3aGljaCBvbmUgd291bGQgZXhwZWN0 IGEgc2VydmVyIHRvIGltcGxlbWVudCBpbiB0aGUNCj4gPj4+PiA+IG5vcm1hbCB3YXkuDQo+ID4+ Pj4NCj4gPj4+PiBXaGF0IG1ha2VzIHRoZSBzb2x1dGlvbnMgd2l0aCBncm91cGluZ3Mgb3IgZXh0 ZW5zaW9ucyBkaWZmZXJlbnQ/DQo+ID4+Pg0KPiA+Pj4gSSBhZ3JlZSB0aGF0IGdyb3VwaW5ncyBh cmUgbWlzbGVhZGluZy4gIEJ1dCB1c2luZyBhbiBleHRlbnNpb24gd291bGQNCj4gPj4+IGJlIGRp ZmZlcmVudCwgYi9jIHRoZSBleHRlbnNpb24gZGVmaW5lcyB0aGUgc2VtYW50aWNzIC0gdGhpcyBp cyBub3QNCj4gPj4+IGNvbmZpZyBvciBvcGVyIHN0YXRlLCBidXQgc29tZXRoaW5nIGVsc2UuDQo+ ID4+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSB0aGVz ZSBhcmUgc3BlY2lhbCBvciBtaXNsZWFkaW5nIGdyb3VwaW5ncy4NCj4gPj4gSSBjYW5ub3QgZmlu ZCBhbnkgdGV4dCBpbiBhbnkgUkZDIHRoYXQgc2F5cyBhIFlBTkcgbW9kdWxlIHdpdGgNCj4gPj4g anVzdCBncm91cGluZ3MgaW4gaXQgaXMgaW52YWxpZCwgaW1wcm9wZXIsIG9yIGV2ZW4gZGlzY291 cmFnZWQuDQo+ID4+DQo+ID4+IEkgYW0gYWxyZWFkeSB1c2luZyAxIG9mIHRoZXNlIGdyb3VwaW5n cyBpbiBhIGxvZ2dpbmcgbW9kZWwuDQo+ID4+IFBsZWFzZSBleHBsYWluIHdoeSB0aGVzZSBhcmUg c3BlY2lhbCBncm91cGluZ3MgdGhhdCBjYW5ub3QNCj4gPj4gYmUgdXNlZCBpbiBhIG5vcm1hbCBk YXRhIG1vZGVsIGluIGFub3RoZXIgbW9kdWxlLg0KPiA+Pg0KPiA+PiBUaGF0IGlzIHdoeSBJIHBy ZWZlciBzb2x1dGlvbiBTMi1CDQo+ID4+DQo+ID4+ICAgcmM6c3RydWN0dXJlIGVycm9ycyB7DQo+ ID4+ICAgICAgdXNlcyBlcnJvcnM7DQo+ID4+ICAgfQ0KPiA+Pg0KPiA+PiBUaGlzIGFzc2lnbnMg YSBtb2R1bGUtbmFtZSBhbmQgYSBuYW1lc3BhY2UgYW5kIGRvZXMgbm90DQo+ID4+IHByZWNsdWRl IHJlLXVzYWdlIG9mIHRoZSBkYXRhIHdpdGhpbiBhIGxhcmdlciBkYXRhIHN0cnVjdHVyZS4NCj4g Pg0KPiA+IEkgZG9uJ3Qgd2FudCB0byBibG9jayB0aGUgcmVzb2x1dGlvbiBvZiB0aGlzIGlzc3Vl LCBzbyBJIHByb3Bvc2UgdGhhdCB5b3UNCj4gPiB3cml0ZSBhIGNvbmNyZXRlIGRlZmluaXRpb24g b2YgdGhlIGV4dGVuc2lvbiwgYW5kIEkgd2lsbCB0aGVuIGNvbW1lbnQgb24NCj4gPiB0aGF0Lg0K PiA+DQo+ID4gTGFkYQ0KPiA+DQo+ID4+DQo+ID4+DQo+ID4+Pj4gSW4NCj4gPj4+PiBhbnkgY2Fz ZSwgdGhlIG1vZHVsZSBkZXNjcmlwdGlvbiBoYXMgdG8gc3RhdGUgdmVyeSBjbGVhcmx5IHRoYXQg aXQgaXMNCj4gPj4+PiBhIHN0cmF3bWFuIG1vZHVsZSB0aGF04oCZcyBub3Qgc3VwcG9zZWQgdG8g YmUgdXNlZCBpbiB0aGUgbm9ybWFsDQo+ID4+Pj4gTkVUQ09ORi9SRVNUQ09ORiB3YXkuIEJ1dCBp ZiB5b3UgYWJvdmUgdGhhdCBkZXZpYXRlIGZyb20gWUFORw0KPiA+Pj4+IHNlbWFudGljcywgYXMg dGhlIGdyb3VwaW5ncyBkbywgeW91IGNhbm5vdCBldmVuIHVzZSBzdGFuZGFyZCBZQU5HDQo+ID4+ Pj4gdG9vbHMgYmVjYXVzZSB0aGV5IHdvdWxkIHByb2R1Y2Ugd3JvbmcgcmVzdWx0cy4NCj4gPj4+ Pg0KPiA+Pj4+IElmIHRoZSBtb2R1bGUgaXMgYXMgSSBwcm9wb3NlZCwgSSBjYW4gc3RpbGwgdXNl IHB5YW5nIGZvciBnZW5lcmF0aW5nDQo+ID4+Pj4gY29ycmVjdCBEU0RMIHNjaGVtYXMsIFhNTC1K U09OIG1hcHBpbmcgZXRjLg0KPiA+Pj4+DQo+ID4+Pj4gQW5kIGlmIGEgc2VydmVyIGltcGxlbWVu dG9yIGxpa2VzIHRoZSBtb2R1bGUgYW5kIGRlY2lkZXMgdG8gaW1wbGVtZW50DQo+ID4+Pj4gaXQg YXMgaWYgaXQgd2FzIGEgbm9ybWFsIG1vZHVsZSwgc28gd2hhdD8NCj4gPj4+Pg0KPiA+Pj4+ID4N Cj4gPj4+PiA+PiBTMyBzaG91bGQgSU1PIGJlIGZpbmUsIHRvbywgdGhlIHN0cnVjdHVyZXMgYXJl bid0IHRoYXQgY29tcGxpY2F0ZWQuDQo+ID4+Pj4gPg0KPiA+Pj4+ID4gSSBjYW4gc2VlIG9ubHkg ZHJhd2JhY2tzIGNvbXBhcmVkIHRvIFMyLiAgV2hhdGV2ZXIgd2UgZG8gaW4gdGV4dCBpdA0KPiA+ Pj4+ID4gd2lsbCBiZSBsZXNzIHByZWNpc2UgdGhhbiBhbiBleHRlbnNpb24uDQo+ID4+Pj4NCj4g Pj4+PiBJIHByZWZlciBsZXNzIHByZWNpc2UgdG8gcHJlY2lzZSBidXQgd3JvbmcuDQo+ID4+Pg0K PiA+Pj4gQW4gZXh0ZW5zaW9uIGlzIGluIG5vIHdheSB3cm9uZy4NCj4gPj4+DQo+ID4+DQo+ID4+ IGFncmVlZA0KPiA+Pg0KPiA+Pj4+IEtlZXAgaW4gbWluZCB0aGF0IHlvdSBhcmUNCj4gPj4+PiBh IFlBTkcgZGVzaWduZXIgc28geW91IGFyZSBub3QgYXMgbGlrZWx5IHRvIGdldCBjb25mdXNlZCBi eSBsYW5ndWFnZQ0KPiA+Pj4+IGFub21hbGllcyBhcyBhbiBhdmVyYWdlIHJlYWRlciBvZiB0aGUg UkVTVENPTkYgZG9jdW1lbnQuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC9tYXJ0aW4NCj4gPj4NCj4g Pj4gQW5keQ0KPiA+DQo+ID4gLS0NCj4gPiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+ ID4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m DQo= From nobody Sun Jan 4 11:01:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFA11A1B61 for ; Sun, 4 Jan 2015 11:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, 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 uyvgCgJyILrm for ; Sun, 4 Jan 2015 11:01:46 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505C31A1B84 for ; Sun, 4 Jan 2015 11:01:45 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t04J1fmT030309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 4 Jan 2015 19:01:41 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t04J1fOo030211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Jan 2015 20:01:41 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 4 Jan 2015 20:01:40 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Sun, 4 Jan 2015 20:01:40 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Kent Watsen , Andy Bierman , "Reinaldo Penno (repenno)" Thread-Topic: [Netconf] call-home#6: Too busy with all the NETCONF/RESTCONF and SSH/TLS switches? Thread-Index: AQHQGK4ZMVLZeaH6bke4DK+bIvTIApyRLVwAgAACcACAAAmuAIAEVqeAgBq/YgA= Date: Sun, 4 Jan 2015 19:01:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4649 X-purgate-ID: 151667::1420398101-00001177-6A7D5A27/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/e9BXHJdL7amDn9gJxKx_TPFbBpc Cc: Netconf Subject: Re: [Netconf] call-home#6: Too busy with all the NETCONF/RESTCONF and SSH/TLS switches? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:01:49 -0000 Hi Kent, All, as I stated on Github I am against splitting the draft into two. I believe we can improve the readability, e.g. by writing Restconf-related = statements in separate sentences or collecting Restconf text in a subsectio= n. That said I do not see consensus on the maillist for splitting the call-hom= e draft. Regards,=20 Mehmet=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Kent Wat= sen > Sent: Thursday, December 18, 2014 10:36 PM > To: Andy Bierman; Reinaldo Penno (repenno) > Cc: Netconf > Subject: Re: [Netconf] call-home#6: Too busy with all the NETCONF/RESTCON= F and > SSH/TLS switches? >=20 >=20 > So it seems that everyone that has commented on this issue so far agrees > that the current draft is too busy, but have different ideas for how to > proceed. Is this a correct assessment? Has anyone else that read the -0= 2 > draft provide their thoughts for how to better structure the content? >=20 > PS: given the comments received so far, the proposal to use the current > draft will not be automatically accepted tomorrow. But for those who > haven't commented yet, please provide your comments quickly so we can mov= e > forward with an update as soon as possible. >=20 > Thanks, > Kent >=20 >=20 > On 12/15/14, 5:21 PM, "Andy Bierman" wrote: >=20 > >On Mon, Dec 15, 2014 at 1:46 PM, Reinaldo Penno (repenno) > > wrote: > >> Hi Andy, > >> > >> I personally think parsing paragraphs like this one is a bit tricky bu= t > >>if > >> that is what the WG prefers, fine by me. > >> > >> " o Using this TCP session, the NETCONF/RESTCONF server immediately > >> starts either the SSH-server or the TLS-server protocol, dependi= ng > >> on which port is connected. The server MUST start the SSH-serve= r > >> protocol when port PORT-X is connected or the TLS-server protoco= l > >> when either port PORT-Y or PORT-Z is connected. The SSH-server > >> and TLS-server protocols are described by [RFC4253 > >> ] and [RFC5246 > >> ] > >> respectively.=B2 > >> > >> > > > >This could be split into 2 separate paragraphs. > > > > > >> Thanks, > > > >Andy > > > >> > >> On 12/15/14, 1:37 PM, "Andy Bierman" wrote: > >> > >>>On Mon, Dec 15, 2014 at 1:28 PM, Reinaldo Penno (repenno) > >>> wrote: > >>>> I think so. I understand the point the chair(?) made today on the ca= ll > >>>>that > >>>> more drafts require mode energy but the draft today is very difficul= t > >>>>to > >>>> read. Moreover, if as we start introducing words like MUST/SHOULD a= nd > >>>> Netconf/RESTconf have different levels of support then it would be > >>>> impossible to follow. > >>> > >>>Why can't the text be expanded into 2 sentences where needed, > >>>instead of 2 drafts? Just use one RFC 2119 keyword per sentence. > >>> > >>> > >>>Andy > >>> > >>> > >>> > >>>> > >>>> Since we are talking about call home draft, I think it is okay for t= he > >>>> client to identity the server using IP:port instead of just IP. One = of > >>>>the > >>>> =B3strategies=B2 is for the server to use STUN/TURN, grab a IP:port = and > >>>>convey > >>>> that info to the client. > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> From: Kent Watsen > >>>> Date: Monday, December 15, 2014 at 11:52 AM > >>>> To: NetConf > >>>> Subject: [Netconf] call-home#6: Too busy with all the NETCONF/RESTCO= NF > >>>>and > >>>> SSH/TLS switches? > >>>> > >>>> > >>>> This issue was discussed in today's virtual interim meeting: > >>>> > >>>> https://github.com/netconf-wg/call-home/issues/6 > >>>> > >>>> Essentially, after adding RESTCONF to the call-home draft, it seems > >>>>that > >>>> draft might be somewhat difficult to read, with all the > >>>>NETCONF/RESTCONF and > >>>> SSH/TLS switches in it. Does anyone else think so? > >>>> > >>>> Unless there are any objections by 12/19/14, plan is to keep RESTCON= F > >>>>in > >>>> this draft as is. > >>>> > >>>> Thanks, > >>>> Kent > >>>> > >>>> > >>>> _______________________________________________ > >>>> Netconf mailing list > >>>> Netconf@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netconf > >>>> > >> >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Jan 4 11:11:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74001A1BBF for ; Sun, 4 Jan 2015 11:11:44 -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 BloE_XDKv0qb for ; Sun, 4 Jan 2015 11:11:42 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415521A1BB1 for ; Sun, 4 Jan 2015 11:11:42 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so17088126lab.23 for ; Sun, 04 Jan 2015 11:11: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:date:message-id:subject:from:to :content-type; bh=Pazwrcq7EmF1Emz9aIVVoXKH/I7n67Yp9cY8iwWwOPo=; b=Zbc0XSenzCBcGsTTRY6igySEyDctQo4GdV/XcyEDt92FIy7RGrlxr2Q7WGcePx8qOJ 0pKK0f5TI2SoA5AgEI0r1jzsa5m8kaJT656sVPIxCL8PX+ZKNbtFK9OV7pBYMGbEgCZW wOuAhT1WexLLgTBwbCWRQEKt8x9INb/4G1ZnNbVRIMTFp1BH/KbNqOtway/8HGm3nlxK WeCqyaTlrqQS8jnkcIIopSoRO20rizuthUb4we29UpPeTj3EoLWckopn1QbGU1Funo0x MG//Pi4/iVUlRz5xkdqZaPPNap1a47/67MmgxPCZirUyNf/cySULgnRDUselgGLk3ChW mx6w== X-Gm-Message-State: ALoCoQm5LZnyTv0HwWTRORu3gRl36cyIpMy2bu6iEgaRTAQMq/ems3NU0NRLCFM2yX1DyykuzH0x MIME-Version: 1.0 X-Received: by 10.152.5.198 with SMTP id u6mr89401133lau.42.1420398700490; Sun, 04 Jan 2015 11:11:40 -0800 (PST) Received: by 10.112.77.231 with HTTP; Sun, 4 Jan 2015 11:11:40 -0800 (PST) Date: Sun, 4 Jan 2015 11:11:40 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gJxV_2dzU5-QE5CF_wVoZPlhgq0 Subject: [Netconf] RESTCONF/YANG Patch Status for Jan. 5 Virtual Interim meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:11:45 -0000 Hi, There are no RESTCONF or YANG Patch issues that really need discussion at this time. RESTCONF Issues: https://github.com/netconf-wg/restconf/issues YANG Patch Issues: https://github.com/netconf-wg/yang-patch/issues Most RESTCONF issues have some sort of resolution and do not need to be discussed until the next draft is reviewed. These include: #1: select parameter Resolution: rename select to fields #2: netconf-state monitoring support Resolution: do not add any session monitoring #3:collection resource Resolution: split all collection resource details out into a new WG draft that will be called draft-ietf-netconf-restconf-collection-00 #4: defaults handling Resolution: add 2 capabilities as proposed #9: Define how authentication is performed Resolution: Security section text has been updated #14: define module name prefix rules Resolution: Will accept YANG JSON encoding rules (SHOULD use prefix) #15: use of groupings in ietf-restconf.yang Resolution: Use restconf-resource extension solution to bind namespace and module-name to a RESTCONF resource #16: content parameter should be mandatory to implement Resolution: make content parameter mandatory The following issue depends on the NETMOD WG resolution of Y45: #13: ietf-yang-library: which RFC should contain this module There are 2 open issues for YANG Patch that have resolution proposals. #1: structure of edit value anyxml Resolution: require child value to contain child node representing the edit content #2: parsing QNames in value parameter anyxml Resolution: this is an implementation detail. It is expected that the edit content will be validated against the YANG schema for the indicated object somehow Future Discussion items: RESTCONF #3: Query parameters and other mechanisms needed for needed for management and retrieval of collection resources. There are no concrete proposals for extended selection and sorting support at this time. This discussion is expected to occur for the new collection draft. Andy From nobody Mon Jan 5 01:23:16 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E6C1A2130 for ; Mon, 5 Jan 2015 01:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 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, J_CHICKENPOX_29=0.6, 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 5qPutDzrNiQQ for ; Mon, 5 Jan 2015 01:23:11 -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 270291A212D for ; Mon, 5 Jan 2015 01:23:10 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 03DD213F69B; Mon, 5 Jan 2015 10:23:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420449788; bh=55PUU0zFGztmVKrlT+M4wPjYhDOHHlIw4aaAhfs6Ekc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=n4BMR1cxNGViaW1S9N9cpCtSWEBmrtZSHLM3eST6ox6cO3tEMGUUtgVwEhbUxTTzw QGwTLiKqrwZkTfTtC9QqLtLuUHmXzMbClb6K4y7E2+Sw33sNbdJTSO4XHUAt1Zhp3d kqYmcMUAGs5FbbCPl7U4NgIRcCaNm6XG1EQwGiiI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 5 Jan 2015 10:23:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bTyVDePEkPt_C7HSPsIveArBA7g Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 09:23:14 -0000 > On 22 Dec 2014, at 18:09, Andy Bierman wrote: >=20 > Hi, >=20 > I updated the issue tracker with the concrete proposal for > ietf-restconf groupings. I=E2=80=99d rather like to see the definition of the proposed extension, = and I will comment on that. Lada >=20 > https://github.com/netconf-wg/restconf/issues/15 >=20 > I forgot to mention that ietf-yang-patch.yang already uses the = "errors" grouping > within the rpc output parameters, so removing it will break YANG = Patch. >=20 > Andy >=20 >=20 > On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka = wrote: >> Andy Bierman writes: >>=20 >>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund = wrote: >>>> Ladislav Lhotka wrote: >>>>>=20 >>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund = wrote: >>>>>>=20 >>>>>> Ladislav Lhotka wrote: >>>>>>> Andy Bierman writes: >>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> A new issue has been added to the tracker: >>>>>>>>=20 >>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>=20 >>>>>>>> There are 3 solutions mentioned. >>>>>>>> The default solution is S1, which will be implemented >>>>>>>> unless there is WG consensus demonstrated to >>>>>>>> do something else. >>>>>>>=20 >>>>>>> The biggest problem with S1 is that it may mislead readers into >>>>>>> thinking: "Hey, now I understand how namespaces work in = groupings!" >>>>>>>=20 >>>>>>> I also don't like the idea of defining an ad hoc extension. >>>>>>=20 >>>>>> I disagree. I think an extension is the best solution in this = case. >>>>>> However, we can use a different name than 'structure'. = 'structure' >>>>>> was originally my proposal for a built-in statement (YANG 1.1) = for >>>>>> this purpose. We can call it 'restconf-structure' or = 'restconf-data' >>>>>> or something. >>>>>=20 >>>>> So another document that wants to do the same should define its = own ad >>>>> hoc extension? Or import the ietf-restconf module? >>>>=20 >>>> Suppose we make a new document that defines a new RESTCONF resource >>>> type, and we need a structure for it, then that document would = import >>>> and use 'restconf-structure'. >>>>=20 >>>>>>> If we want >>>>>>> to turn YANG into a general schema language, it should be done >>>>>>> properly. >>>>>>>=20 >>>>>>> I think the simplest solution would be to remove the groupings = and >>>>>>> have >>>>>>> "errors", "restconf", "collection" and "notification" as = top-level >>>>>>> containers. The namespace assignment then follows YANG rules. >>>>>>=20 >>>>>> This is also _very_ misleading, b/c then it looks like a normal = config >>>>>> or state module, which one would expect a server to implement in = the >>>>>> normal way. >>>>>=20 >>>>> What makes the solutions with groupings or extensions different? >>>>=20 >>>> I agree that groupings are misleading. But using an extension = would >>>> be different, b/c the extension defines the semantics - this is not >>>> config or oper state, but something else. >>>>=20 >>>=20 >>>=20 >>>=20 >>> I do not understand why these are special or misleading groupings. >>> I cannot find any text in any RFC that says a YANG module with >>> just groupings in it is invalid, improper, or even discouraged. >>>=20 >>> I am already using 1 of these groupings in a logging model. >>> Please explain why these are special groupings that cannot >>> be used in a normal data model in another module. >>>=20 >>> That is why I prefer solution S2-B >>>=20 >>> rc:structure errors { >>> uses errors; >>> } >>>=20 >>> This assigns a module-name and a namespace and does not >>> preclude re-usage of the data within a larger data structure. >>=20 >> I don't want to block the resolution of this issue, so I propose that = you >> write a concrete definition of the extension, and I will then comment = on >> that. >>=20 >> Lada >>=20 >>>=20 >>>=20 >>>>> In >>>>> any case, the module description has to state very clearly that it = is >>>>> a strawman module that=E2=80=99s not supposed to be used in the = normal >>>>> NETCONF/RESTCONF way. But if you above that deviate from YANG >>>>> semantics, as the groupings do, you cannot even use standard YANG >>>>> tools because they would produce wrong results. >>>>>=20 >>>>> If the module is as I proposed, I can still use pyang for = generating >>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>=20 >>>>> And if a server implementor likes the module and decides to = implement >>>>> it as if it was a normal module, so what? >>>>>=20 >>>>>>=20 >>>>>>> S3 should IMO be fine, too, the structures aren't that = complicated. >>>>>>=20 >>>>>> I can see only drawbacks compared to S2. Whatever we do in text = it >>>>>> will be less precise than an extension. >>>>>=20 >>>>> I prefer less precise to precise but wrong. >>>>=20 >>>> An extension is in no way wrong. >>>>=20 >>>=20 >>> agreed >>>=20 >>>>> Keep in mind that you are >>>>> a YANG designer so you are not as likely to get confused by = language >>>>> anomalies as an average reader of the RESTCONF document. >>>>=20 >>>>=20 >>>> /martin >>>=20 >>> Andy >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 5 05:20:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9C71A8750 for ; Mon, 5 Jan 2015 05:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 20gocxER-WOs for ; Mon, 5 Jan 2015 05:20:40 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7691A8713 for ; Mon, 5 Jan 2015 05:20:39 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so17689917lab.41 for ; Mon, 05 Jan 2015 05:20:38 -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=3u97ovUar/x7ntt1CIf1Wfz53juqGA/eWm0gC4wmTXY=; b=DC7DCbht1+9Hid0W5FxzGjYKzFMXyYTmbqAxEMHmp5vQghy2NoZabtaYJ66yTu9YIM +FZW1XnnAGL4aJvcnVQX8Ifuk9uw/sfmYAHfuFb67g7mSo3r3Iw53fFGvxrCVfDblEtN ++Qhs6AQY8XfQQI3XIj0/+dAtADXxE/GvrFxw+dqdnx9X+i/0E0aTyLptdLPaa/G+VKB DH05IBMn9wD/cug9BK4NBPJzH/srWF37O6iLnonSLM6nQfEhAxoU5lI5sn2JlLvmP4eR hStjxblAYPMz/ThzUkpwe4fRSqV86VhIcuUsAUxZ07KvKP5o5v30v9+A/JPMXEp0nQ0x qrLA== X-Gm-Message-State: ALoCoQmG622wpKhhDv1kLBPKWfZxO+mH7h/huap28Gek19vrrJNZHb27LDz060wKFEuIHaipwHYr MIME-Version: 1.0 X-Received: by 10.112.8.69 with SMTP id p5mr91778140lba.97.1420464038113; Mon, 05 Jan 2015 05:20:38 -0800 (PST) Received: by 10.112.77.231 with HTTP; Mon, 5 Jan 2015 05:20:38 -0800 (PST) In-Reply-To: References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> Date: Mon, 5 Jan 2015 05:20:38 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ttPQQy9gUYXsZuNmOVBldVyrAUo Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:20:45 -0000 On Mon, Jan 5, 2015 at 1:23 AM, Ladislav Lhotka wrote: > >> On 22 Dec 2014, at 18:09, Andy Bierman wrote: >> >> Hi, >> >> I updated the issue tracker with the concrete proposal for >> ietf-restconf groupings. > > I=E2=80=99d rather like to see the definition of the proposed extension, = and I will comment on that. > https://github.com/netconf-wg/restconf/issues/15 > Lada Andy > >> >> https://github.com/netconf-wg/restconf/issues/15 >> >> I forgot to mention that ietf-yang-patch.yang already uses the "errors" = grouping >> within the rpc output parameters, so removing it will break YANG Patch. >> >> Andy >> >> >> On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka wrote: >>> Andy Bierman writes: >>> >>>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund wro= te: >>>>> Ladislav Lhotka wrote: >>>>>> >>>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund wrote: >>>>>>> >>>>>>> Ladislav Lhotka wrote: >>>>>>>> Andy Bierman writes: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> A new issue has been added to the tracker: >>>>>>>>> >>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>> >>>>>>>>> There are 3 solutions mentioned. >>>>>>>>> The default solution is S1, which will be implemented >>>>>>>>> unless there is WG consensus demonstrated to >>>>>>>>> do something else. >>>>>>>> >>>>>>>> The biggest problem with S1 is that it may mislead readers into >>>>>>>> thinking: "Hey, now I understand how namespaces work in groupings!= " >>>>>>>> >>>>>>>> I also don't like the idea of defining an ad hoc extension. >>>>>>> >>>>>>> I disagree. I think an extension is the best solution in this case= . >>>>>>> However, we can use a different name than 'structure'. 'structure' >>>>>>> was originally my proposal for a built-in statement (YANG 1.1) for >>>>>>> this purpose. We can call it 'restconf-structure' or 'restconf-dat= a' >>>>>>> or something. >>>>>> >>>>>> So another document that wants to do the same should define its own = ad >>>>>> hoc extension? Or import the ietf-restconf module? >>>>> >>>>> Suppose we make a new document that defines a new RESTCONF resource >>>>> type, and we need a structure for it, then that document would import >>>>> and use 'restconf-structure'. >>>>> >>>>>>>> If we want >>>>>>>> to turn YANG into a general schema language, it should be done >>>>>>>> properly. >>>>>>>> >>>>>>>> I think the simplest solution would be to remove the groupings and >>>>>>>> have >>>>>>>> "errors", "restconf", "collection" and "notification" as top-level >>>>>>>> containers. The namespace assignment then follows YANG rules. >>>>>>> >>>>>>> This is also _very_ misleading, b/c then it looks like a normal con= fig >>>>>>> or state module, which one would expect a server to implement in th= e >>>>>>> normal way. >>>>>> >>>>>> What makes the solutions with groupings or extensions different? >>>>> >>>>> I agree that groupings are misleading. But using an extension would >>>>> be different, b/c the extension defines the semantics - this is not >>>>> config or oper state, but something else. >>>>> >>>> >>>> >>>> >>>> I do not understand why these are special or misleading groupings. >>>> I cannot find any text in any RFC that says a YANG module with >>>> just groupings in it is invalid, improper, or even discouraged. >>>> >>>> I am already using 1 of these groupings in a logging model. >>>> Please explain why these are special groupings that cannot >>>> be used in a normal data model in another module. >>>> >>>> That is why I prefer solution S2-B >>>> >>>> rc:structure errors { >>>> uses errors; >>>> } >>>> >>>> This assigns a module-name and a namespace and does not >>>> preclude re-usage of the data within a larger data structure. >>> >>> I don't want to block the resolution of this issue, so I propose that y= ou >>> write a concrete definition of the extension, and I will then comment o= n >>> that. >>> >>> Lada >>> >>>> >>>> >>>>>> In >>>>>> any case, the module description has to state very clearly that it i= s >>>>>> a strawman module that=E2=80=99s not supposed to be used in the norm= al >>>>>> NETCONF/RESTCONF way. But if you above that deviate from YANG >>>>>> semantics, as the groupings do, you cannot even use standard YANG >>>>>> tools because they would produce wrong results. >>>>>> >>>>>> If the module is as I proposed, I can still use pyang for generating >>>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>> >>>>>> And if a server implementor likes the module and decides to implemen= t >>>>>> it as if it was a normal module, so what? >>>>>> >>>>>>> >>>>>>>> S3 should IMO be fine, too, the structures aren't that complicated= . >>>>>>> >>>>>>> I can see only drawbacks compared to S2. Whatever we do in text it >>>>>>> will be less precise than an extension. >>>>>> >>>>>> I prefer less precise to precise but wrong. >>>>> >>>>> An extension is in no way wrong. >>>>> >>>> >>>> agreed >>>> >>>>>> Keep in mind that you are >>>>>> a YANG designer so you are not as likely to get confused by language >>>>>> anomalies as an average reader of the RESTCONF document. >>>>> >>>>> >>>>> /martin >>>> >>>> Andy >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Mon Jan 5 05:46:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7451A87BD for ; Mon, 5 Jan 2015 05:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 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, J_CHICKENPOX_29=0.6, 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 O4z1M-FToaCM for ; Mon, 5 Jan 2015 05:46:20 -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 DE7231A87AE for ; Mon, 5 Jan 2015 05:46:19 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:31da:e4d3:7849:f94f] (unknown [IPv6:2001:718:1a02:1:31da:e4d3:7849:f94f]) by mail.nic.cz (Postfix) with ESMTPSA id 520C013FA5E; Mon, 5 Jan 2015 14:46:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420465578; bh=j7IbaABIlfTehp/6qYsjxV17xIx7+w4l6arudb7OYE0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mMwq/ChOABPTZoSw8yIPQEaAng9qbnUmIbqsulRTVSwSYkp4a82Xkz42qzYLHD5c6 feHDZVU5r37nBbfoD40poWuhnf3r+8aeWON4UnkeLInbG2wIUmilpmQJRlpGF+2UCp yQzUa/Rli8E7AymdSAEJapYdERvh1qtUds0RmVFE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 5 Jan 2015 14:46:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <27E3CF22-5D4C-4AB3-AB2A-97C93843B9E7@nic.cz> References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xNamRUPkvpQquy4EcZDGRKSZyig Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:46:22 -0000 > On 05 Jan 2015, at 14:20, Andy Bierman wrote: >=20 > On Mon, Jan 5, 2015 at 1:23 AM, Ladislav Lhotka wrote: >>=20 >>> On 22 Dec 2014, at 18:09, Andy Bierman wrote: >>>=20 >>> Hi, >>>=20 >>> I updated the issue tracker with the concrete proposal for >>> ietf-restconf groupings. >>=20 >> I=E2=80=99d rather like to see the definition of the proposed = extension, and I will comment on that. >>=20 >=20 > https://github.com/netconf-wg/restconf/issues/15 The ietf-restconf module imports ietf-yang-types. How can an implementor = figure out which revision of ietf-yang-types to use? Lada >=20 >=20 >> Lada >=20 > Andy >=20 >>=20 >>>=20 >>> https://github.com/netconf-wg/restconf/issues/15 >>>=20 >>> I forgot to mention that ietf-yang-patch.yang already uses the = "errors" grouping >>> within the rpc output parameters, so removing it will break YANG = Patch. >>>=20 >>> Andy >>>=20 >>>=20 >>> On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka = wrote: >>>> Andy Bierman writes: >>>>=20 >>>>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund = wrote: >>>>>> Ladislav Lhotka wrote: >>>>>>>=20 >>>>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund = wrote: >>>>>>>>=20 >>>>>>>> Ladislav Lhotka wrote: >>>>>>>>> Andy Bierman writes: >>>>>>>>>=20 >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> A new issue has been added to the tracker: >>>>>>>>>>=20 >>>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>>=20 >>>>>>>>>> There are 3 solutions mentioned. >>>>>>>>>> The default solution is S1, which will be implemented >>>>>>>>>> unless there is WG consensus demonstrated to >>>>>>>>>> do something else. >>>>>>>>>=20 >>>>>>>>> The biggest problem with S1 is that it may mislead readers = into >>>>>>>>> thinking: "Hey, now I understand how namespaces work in = groupings!" >>>>>>>>>=20 >>>>>>>>> I also don't like the idea of defining an ad hoc extension. >>>>>>>>=20 >>>>>>>> I disagree. I think an extension is the best solution in this = case. >>>>>>>> However, we can use a different name than 'structure'. = 'structure' >>>>>>>> was originally my proposal for a built-in statement (YANG 1.1) = for >>>>>>>> this purpose. We can call it 'restconf-structure' or = 'restconf-data' >>>>>>>> or something. >>>>>>>=20 >>>>>>> So another document that wants to do the same should define its = own ad >>>>>>> hoc extension? Or import the ietf-restconf module? >>>>>>=20 >>>>>> Suppose we make a new document that defines a new RESTCONF = resource >>>>>> type, and we need a structure for it, then that document would = import >>>>>> and use 'restconf-structure'. >>>>>>=20 >>>>>>>>> If we want >>>>>>>>> to turn YANG into a general schema language, it should be done >>>>>>>>> properly. >>>>>>>>>=20 >>>>>>>>> I think the simplest solution would be to remove the groupings = and >>>>>>>>> have >>>>>>>>> "errors", "restconf", "collection" and "notification" as = top-level >>>>>>>>> containers. The namespace assignment then follows YANG rules. >>>>>>>>=20 >>>>>>>> This is also _very_ misleading, b/c then it looks like a normal = config >>>>>>>> or state module, which one would expect a server to implement = in the >>>>>>>> normal way. >>>>>>>=20 >>>>>>> What makes the solutions with groupings or extensions different? >>>>>>=20 >>>>>> I agree that groupings are misleading. But using an extension = would >>>>>> be different, b/c the extension defines the semantics - this is = not >>>>>> config or oper state, but something else. >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I do not understand why these are special or misleading groupings. >>>>> I cannot find any text in any RFC that says a YANG module with >>>>> just groupings in it is invalid, improper, or even discouraged. >>>>>=20 >>>>> I am already using 1 of these groupings in a logging model. >>>>> Please explain why these are special groupings that cannot >>>>> be used in a normal data model in another module. >>>>>=20 >>>>> That is why I prefer solution S2-B >>>>>=20 >>>>> rc:structure errors { >>>>> uses errors; >>>>> } >>>>>=20 >>>>> This assigns a module-name and a namespace and does not >>>>> preclude re-usage of the data within a larger data structure. >>>>=20 >>>> I don't want to block the resolution of this issue, so I propose = that you >>>> write a concrete definition of the extension, and I will then = comment on >>>> that. >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>>=20 >>>>>>> In >>>>>>> any case, the module description has to state very clearly that = it is >>>>>>> a strawman module that=E2=80=99s not supposed to be used in the = normal >>>>>>> NETCONF/RESTCONF way. But if you above that deviate from YANG >>>>>>> semantics, as the groupings do, you cannot even use standard = YANG >>>>>>> tools because they would produce wrong results. >>>>>>>=20 >>>>>>> If the module is as I proposed, I can still use pyang for = generating >>>>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>>>=20 >>>>>>> And if a server implementor likes the module and decides to = implement >>>>>>> it as if it was a normal module, so what? >>>>>>>=20 >>>>>>>>=20 >>>>>>>>> S3 should IMO be fine, too, the structures aren't that = complicated. >>>>>>>>=20 >>>>>>>> I can see only drawbacks compared to S2. Whatever we do in = text it >>>>>>>> will be less precise than an extension. >>>>>>>=20 >>>>>>> I prefer less precise to precise but wrong. >>>>>>=20 >>>>>> An extension is in no way wrong. >>>>>>=20 >>>>>=20 >>>>> agreed >>>>>=20 >>>>>>> Keep in mind that you are >>>>>>> a YANG designer so you are not as likely to get confused by = language >>>>>>> anomalies as an average reader of the RESTCONF document. >>>>>>=20 >>>>>>=20 >>>>>> /martin >>>>>=20 >>>>> Andy >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 5 05:59:12 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB04A1A87E1 for ; Mon, 5 Jan 2015 05:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 glkKGHCf3R3A for ; Mon, 5 Jan 2015 05:59:09 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 320311A87D2 for ; Mon, 5 Jan 2015 05:59:09 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so18560659lab.1 for ; Mon, 05 Jan 2015 05:59: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 :content-transfer-encoding; bh=PznVH/dGzMxwePDQJi8gKz5MCIP+u2cnA8P9MRIOhlE=; b=Wut++ousP8TDFEx8l8N+Tld2XGYYzhd6dPBZjfD4epihLg1+luZUv/mJicBSnL5OU0 2b8Ioour57Y35e3mHylhA+aGLH9Bnrdm6+KXglzrYem1lDHCJ5DwZLO6vTIu/iWjjFwG XY3QjJXzkVb5WZpsfX0mIwMYvfGLBYvezmq97rDu6px1mlvLW888YFY5bE8hCpHMNHMa xp45o+pw2e57fkVtREtyjJFY3QstE6aIimEk531T4RkVCLzXHV8zbtD6HcKkaRxYL1u6 JjIyagv7gG+FvludhutICMVqrcZy0f/JcbvNdiXfZeWut0SKxsbC0UAziK7eOZWCLsuu ptfg== X-Gm-Message-State: ALoCoQnT/m9hRqPgYceoqTmc/NjPZhnPpUQCSo/v6YjFmJ6xJ3rR7KJ8uUQZHXNrz1nJK1TKAukU MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr93843844laf.82.1420466347553; Mon, 05 Jan 2015 05:59:07 -0800 (PST) Received: by 10.112.77.231 with HTTP; Mon, 5 Jan 2015 05:59:07 -0800 (PST) In-Reply-To: <27E3CF22-5D4C-4AB3-AB2A-97C93843B9E7@nic.cz> References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> <27E3CF22-5D4C-4AB3-AB2A-97C93843B9E7@nic.cz> Date: Mon, 5 Jan 2015 05:59:07 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/TCuKBMblmobl0_4u1XQlyyqwxxg Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 13:59:11 -0000 On Mon, Jan 5, 2015 at 5:46 AM, Ladislav Lhotka wrote: > >> On 05 Jan 2015, at 14:20, Andy Bierman wrote: >> >> On Mon, Jan 5, 2015 at 1:23 AM, Ladislav Lhotka wrote: >>> >>>> On 22 Dec 2014, at 18:09, Andy Bierman wrote: >>>> >>>> Hi, >>>> >>>> I updated the issue tracker with the concrete proposal for >>>> ietf-restconf groupings. >>> >>> I=E2=80=99d rather like to see the definition of the proposed extension= , and I will comment on that. >>> >> >> https://github.com/netconf-wg/restconf/issues/15 > > The ietf-restconf module imports ietf-yang-types. How can an implementor = figure out which revision of ietf-yang-types to use? > Either the server advertises it or the ietf-netconf-monitoring module contains that data. How does this have anything to do with the restconf-resource extension? > Lada > Andy >> >> >>> Lada >> >> Andy >> >>> >>>> >>>> https://github.com/netconf-wg/restconf/issues/15 >>>> >>>> I forgot to mention that ietf-yang-patch.yang already uses the "errors= " grouping >>>> within the rpc output parameters, so removing it will break YANG Patch= . >>>> >>>> Andy >>>> >>>> >>>> On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka wrot= e: >>>>> Andy Bierman writes: >>>>> >>>>>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund w= rote: >>>>>>> Ladislav Lhotka wrote: >>>>>>>> >>>>>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund wrote= : >>>>>>>>> >>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>> Andy Bierman writes: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> A new issue has been added to the tracker: >>>>>>>>>>> >>>>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>>> >>>>>>>>>>> There are 3 solutions mentioned. >>>>>>>>>>> The default solution is S1, which will be implemented >>>>>>>>>>> unless there is WG consensus demonstrated to >>>>>>>>>>> do something else. >>>>>>>>>> >>>>>>>>>> The biggest problem with S1 is that it may mislead readers into >>>>>>>>>> thinking: "Hey, now I understand how namespaces work in grouping= s!" >>>>>>>>>> >>>>>>>>>> I also don't like the idea of defining an ad hoc extension. >>>>>>>>> >>>>>>>>> I disagree. I think an extension is the best solution in this ca= se. >>>>>>>>> However, we can use a different name than 'structure'. 'structur= e' >>>>>>>>> was originally my proposal for a built-in statement (YANG 1.1) fo= r >>>>>>>>> this purpose. We can call it 'restconf-structure' or 'restconf-d= ata' >>>>>>>>> or something. >>>>>>>> >>>>>>>> So another document that wants to do the same should define its ow= n ad >>>>>>>> hoc extension? Or import the ietf-restconf module? >>>>>>> >>>>>>> Suppose we make a new document that defines a new RESTCONF resource >>>>>>> type, and we need a structure for it, then that document would impo= rt >>>>>>> and use 'restconf-structure'. >>>>>>> >>>>>>>>>> If we want >>>>>>>>>> to turn YANG into a general schema language, it should be done >>>>>>>>>> properly. >>>>>>>>>> >>>>>>>>>> I think the simplest solution would be to remove the groupings a= nd >>>>>>>>>> have >>>>>>>>>> "errors", "restconf", "collection" and "notification" as top-lev= el >>>>>>>>>> containers. The namespace assignment then follows YANG rules. >>>>>>>>> >>>>>>>>> This is also _very_ misleading, b/c then it looks like a normal c= onfig >>>>>>>>> or state module, which one would expect a server to implement in = the >>>>>>>>> normal way. >>>>>>>> >>>>>>>> What makes the solutions with groupings or extensions different? >>>>>>> >>>>>>> I agree that groupings are misleading. But using an extension woul= d >>>>>>> be different, b/c the extension defines the semantics - this is not >>>>>>> config or oper state, but something else. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I do not understand why these are special or misleading groupings. >>>>>> I cannot find any text in any RFC that says a YANG module with >>>>>> just groupings in it is invalid, improper, or even discouraged. >>>>>> >>>>>> I am already using 1 of these groupings in a logging model. >>>>>> Please explain why these are special groupings that cannot >>>>>> be used in a normal data model in another module. >>>>>> >>>>>> That is why I prefer solution S2-B >>>>>> >>>>>> rc:structure errors { >>>>>> uses errors; >>>>>> } >>>>>> >>>>>> This assigns a module-name and a namespace and does not >>>>>> preclude re-usage of the data within a larger data structure. >>>>> >>>>> I don't want to block the resolution of this issue, so I propose that= you >>>>> write a concrete definition of the extension, and I will then comment= on >>>>> that. >>>>> >>>>> Lada >>>>> >>>>>> >>>>>> >>>>>>>> In >>>>>>>> any case, the module description has to state very clearly that it= is >>>>>>>> a strawman module that=E2=80=99s not supposed to be used in the no= rmal >>>>>>>> NETCONF/RESTCONF way. But if you above that deviate from YANG >>>>>>>> semantics, as the groupings do, you cannot even use standard YANG >>>>>>>> tools because they would produce wrong results. >>>>>>>> >>>>>>>> If the module is as I proposed, I can still use pyang for generati= ng >>>>>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>>>> >>>>>>>> And if a server implementor likes the module and decides to implem= ent >>>>>>>> it as if it was a normal module, so what? >>>>>>>> >>>>>>>>> >>>>>>>>>> S3 should IMO be fine, too, the structures aren't that complicat= ed. >>>>>>>>> >>>>>>>>> I can see only drawbacks compared to S2. Whatever we do in text = it >>>>>>>>> will be less precise than an extension. >>>>>>>> >>>>>>>> I prefer less precise to precise but wrong. >>>>>>> >>>>>>> An extension is in no way wrong. >>>>>>> >>>>>> >>>>>> agreed >>>>>> >>>>>>>> Keep in mind that you are >>>>>>>> a YANG designer so you are not as likely to get confused by langua= ge >>>>>>>> anomalies as an average reader of the RESTCONF document. >>>>>>> >>>>>>> >>>>>>> /martin >>>>>> >>>>>> Andy >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Mon Jan 5 06:28:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7803C1A885E for ; Mon, 5 Jan 2015 06:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 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, J_CHICKENPOX_29=0.6, 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 iKaTxHpPDbkP for ; Mon, 5 Jan 2015 06:28: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 9DEE51A885F for ; Mon, 5 Jan 2015 06:28:06 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:31da:e4d3:7849:f94f] (unknown [IPv6:2001:718:1a02:1:31da:e4d3:7849:f94f]) by mail.nic.cz (Postfix) with ESMTPSA id 3597013FA5E; Mon, 5 Jan 2015 15:28:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420468085; bh=wTALGJEUxc9upCmKpUbqoB03RiFDU6Doac2Xh0kpRWY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=icatSqmfariRHvI9uDMqWamVvzMDstHBdvX49IFvp21SK5MLGLzf5PLwx8fdqouSl 7jfgy3zYwKCi/NtO/BgsE+i2usip5zlpIQkJizpJCwSn3ORRYM42lDuzCsiISK7hZl /wopcVI5Ch1RyrRt93Km60/qs+spvzecFmXt7M2k= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 5 Jan 2015 15:28:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> <27E3CF22-5D4C-4AB3-AB2A-97C93843B9E7@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HNZl1XFHx0KnZHWMFh6AS7mhyJY Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:28:09 -0000 > On 05 Jan 2015, at 14:59, Andy Bierman wrote: >=20 > On Mon, Jan 5, 2015 at 5:46 AM, Ladislav Lhotka wrote: >>=20 >>> On 05 Jan 2015, at 14:20, Andy Bierman wrote: >>>=20 >>> On Mon, Jan 5, 2015 at 1:23 AM, Ladislav Lhotka = wrote: >>>>=20 >>>>> On 22 Dec 2014, at 18:09, Andy Bierman wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I updated the issue tracker with the concrete proposal for >>>>> ietf-restconf groupings. >>>>=20 >>>> I=E2=80=99d rather like to see the definition of the proposed = extension, and I will comment on that. >>>>=20 >>>=20 >>> https://github.com/netconf-wg/restconf/issues/15 >>=20 >> The ietf-restconf module imports ietf-yang-types. How can an = implementor figure out which revision of ietf-yang-types to use? >>=20 >=20 >=20 > Either the server advertises it or the ietf-netconf-monitoring > module contains that data. IMO schemas outside the data and operation resources have to be fixed = for the given RESTconf version. >=20 > How does this have anything to do with the restconf-resource = extension? This has to do with using YANG as a general schema language, i.e. = outside the normal NETCONF context. Lada >=20 >=20 >> Lada >>=20 >=20 > Andy >=20 >>>=20 >>>=20 >>>> Lada >>>=20 >>> Andy >>>=20 >>>>=20 >>>>>=20 >>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>=20 >>>>> I forgot to mention that ietf-yang-patch.yang already uses the = "errors" grouping >>>>> within the rpc output parameters, so removing it will break YANG = Patch. >>>>>=20 >>>>> Andy >>>>>=20 >>>>>=20 >>>>> On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka = wrote: >>>>>> Andy Bierman writes: >>>>>>=20 >>>>>>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund = wrote: >>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>=20 >>>>>>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund = wrote: >>>>>>>>>>=20 >>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>> Andy Bierman writes: >>>>>>>>>>>=20 >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> A new issue has been added to the tracker: >>>>>>>>>>>>=20 >>>>>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>>>>=20 >>>>>>>>>>>> There are 3 solutions mentioned. >>>>>>>>>>>> The default solution is S1, which will be implemented >>>>>>>>>>>> unless there is WG consensus demonstrated to >>>>>>>>>>>> do something else. >>>>>>>>>>>=20 >>>>>>>>>>> The biggest problem with S1 is that it may mislead readers = into >>>>>>>>>>> thinking: "Hey, now I understand how namespaces work in = groupings!" >>>>>>>>>>>=20 >>>>>>>>>>> I also don't like the idea of defining an ad hoc extension. >>>>>>>>>>=20 >>>>>>>>>> I disagree. I think an extension is the best solution in = this case. >>>>>>>>>> However, we can use a different name than 'structure'. = 'structure' >>>>>>>>>> was originally my proposal for a built-in statement (YANG = 1.1) for >>>>>>>>>> this purpose. We can call it 'restconf-structure' or = 'restconf-data' >>>>>>>>>> or something. >>>>>>>>>=20 >>>>>>>>> So another document that wants to do the same should define = its own ad >>>>>>>>> hoc extension? Or import the ietf-restconf module? >>>>>>>>=20 >>>>>>>> Suppose we make a new document that defines a new RESTCONF = resource >>>>>>>> type, and we need a structure for it, then that document would = import >>>>>>>> and use 'restconf-structure'. >>>>>>>>=20 >>>>>>>>>>> If we want >>>>>>>>>>> to turn YANG into a general schema language, it should be = done >>>>>>>>>>> properly. >>>>>>>>>>>=20 >>>>>>>>>>> I think the simplest solution would be to remove the = groupings and >>>>>>>>>>> have >>>>>>>>>>> "errors", "restconf", "collection" and "notification" as = top-level >>>>>>>>>>> containers. The namespace assignment then follows YANG = rules. >>>>>>>>>>=20 >>>>>>>>>> This is also _very_ misleading, b/c then it looks like a = normal config >>>>>>>>>> or state module, which one would expect a server to implement = in the >>>>>>>>>> normal way. >>>>>>>>>=20 >>>>>>>>> What makes the solutions with groupings or extensions = different? >>>>>>>>=20 >>>>>>>> I agree that groupings are misleading. But using an extension = would >>>>>>>> be different, b/c the extension defines the semantics - this is = not >>>>>>>> config or oper state, but something else. >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> I do not understand why these are special or misleading = groupings. >>>>>>> I cannot find any text in any RFC that says a YANG module with >>>>>>> just groupings in it is invalid, improper, or even discouraged. >>>>>>>=20 >>>>>>> I am already using 1 of these groupings in a logging model. >>>>>>> Please explain why these are special groupings that cannot >>>>>>> be used in a normal data model in another module. >>>>>>>=20 >>>>>>> That is why I prefer solution S2-B >>>>>>>=20 >>>>>>> rc:structure errors { >>>>>>> uses errors; >>>>>>> } >>>>>>>=20 >>>>>>> This assigns a module-name and a namespace and does not >>>>>>> preclude re-usage of the data within a larger data structure. >>>>>>=20 >>>>>> I don't want to block the resolution of this issue, so I propose = that you >>>>>> write a concrete definition of the extension, and I will then = comment on >>>>>> that. >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>> In >>>>>>>>> any case, the module description has to state very clearly = that it is >>>>>>>>> a strawman module that=E2=80=99s not supposed to be used in = the normal >>>>>>>>> NETCONF/RESTCONF way. But if you above that deviate from YANG >>>>>>>>> semantics, as the groupings do, you cannot even use standard = YANG >>>>>>>>> tools because they would produce wrong results. >>>>>>>>>=20 >>>>>>>>> If the module is as I proposed, I can still use pyang for = generating >>>>>>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>>>>>=20 >>>>>>>>> And if a server implementor likes the module and decides to = implement >>>>>>>>> it as if it was a normal module, so what? >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> S3 should IMO be fine, too, the structures aren't that = complicated. >>>>>>>>>>=20 >>>>>>>>>> I can see only drawbacks compared to S2. Whatever we do in = text it >>>>>>>>>> will be less precise than an extension. >>>>>>>>>=20 >>>>>>>>> I prefer less precise to precise but wrong. >>>>>>>>=20 >>>>>>>> An extension is in no way wrong. >>>>>>>>=20 >>>>>>>=20 >>>>>>> agreed >>>>>>>=20 >>>>>>>>> Keep in mind that you are >>>>>>>>> a YANG designer so you are not as likely to get confused by = language >>>>>>>>> anomalies as an average reader of the RESTCONF document. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> /martin >>>>>>>=20 >>>>>>> Andy >>>>>>=20 >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 5 06:29:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3251A885F for ; Mon, 5 Jan 2015 06:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 XHx6aRzcXH2e for ; Mon, 5 Jan 2015 06:29:18 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990E61A885E for ; Mon, 5 Jan 2015 06:29:18 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t05ETGFJ022971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jan 2015 14:29:16 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t05ETGkJ018528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 15:29:16 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 15:29:16 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Andy Bierman , Netconf Thread-Topic: Issues #14 and #16 WAS:RE: [Netconf] RESTCONF/YANG Patch Status for Jan. 5 Virtual Interim meeting Thread-Index: AQHQKFJNOyWKI0hgU0+QKyW37FzyTpyxlp7Q Date: Mon, 5 Jan 2015 14:29:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3041 X-purgate-ID: 151667::1420468156-00001177-4F09FEB4/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/VYwmXtt5VTCvEAbQlO-ED8Vzn9c Subject: [Netconf] Issues #14 and #16 WAS:RE: RESTCONF/YANG Patch Status for Jan. 5 Virtual Interim meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 14:29:21 -0000 Hi All, the resolution and the way forward for the Restconf issues #14 and #16 have= been now updated on Github.=20 We are going to implement as described. Please speak up by January 8 if you have any strong objections. Mehmet=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bie= rman > Sent: Sunday, January 04, 2015 8:12 PM > To: Netconf > Subject: [Netconf] RESTCONF/YANG Patch Status for Jan. 5 Virtual Interim = meeting >=20 > Hi, >=20 > There are no RESTCONF or YANG Patch issues that > really need discussion at this time. >=20 > RESTCONF Issues: > https://github.com/netconf-wg/restconf/issues >=20 > YANG Patch Issues: > https://github.com/netconf-wg/yang-patch/issues >=20 > Most RESTCONF issues have some sort of > resolution and do not need to be discussed until the > next draft is reviewed. These include: >=20 > #1: select parameter > Resolution: rename select to fields >=20 > #2: netconf-state monitoring support > Resolution: do not add any session monitoring >=20 > #3:collection resource > Resolution: split all collection resource details out into > a new WG draft that will be called > draft-ietf-netconf-restconf-collection-00 >=20 > #4: defaults handling > Resolution: add 2 capabilities as proposed >=20 > #9: Define how authentication is performed > Resolution: Security section text has been updated >=20 > #14: define module name prefix rules > Resolution: Will accept YANG JSON encoding rules > (SHOULD use prefix) >=20 > #15: use of groupings in ietf-restconf.yang > Resolution: Use restconf-resource extension solution to > bind namespace and module-name to a RESTCONF resource >=20 > #16: content parameter should be mandatory to implement > Resolution: make content parameter mandatory >=20 > The following issue depends on the NETMOD WG resolution > of Y45: >=20 > #13: ietf-yang-library: which RFC should contain this module >=20 > There are 2 open issues for YANG Patch that have resolution > proposals. >=20 > #1: structure of edit value anyxml > Resolution: require child value to contain child node representing > the edit content >=20 > #2: parsing QNames in value parameter anyxml > Resolution: this is an implementation detail. It is expected > that the edit content will be validated against the YANG > schema for the indicated object somehow >=20 > Future Discussion items: > RESTCONF #3: Query parameters and other mechanisms > needed for needed for management and retrieval of collection resource= s. > There are no concrete proposals for extended selection and sorting su= pport > at this time. This discussion is expected to occur for the new > collection draft. >=20 >=20 > Andy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jan 5 07:12:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04B71A005A for ; Mon, 5 Jan 2015 07:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 6sVBXSPMWzxD for ; Mon, 5 Jan 2015 07:12:44 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A731A000C for ; Mon, 5 Jan 2015 07:12:44 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id b6so17822990lbj.36 for ; Mon, 05 Jan 2015 07:12:42 -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=V+7Z7WZEY0En0/+7OHpTgooQEcToZ1PcQLPzA26Lxq0=; b=Y2o4wupKlH2z7wes4fRVJKgOYDa+jqhH7a9bJw4PmxlQ9M+Z41XzXR/+RjayY0PgzP t31DRGbkVJr3bH06OTeErA1bKS/nKQV4Nl83ewtQV2Z59QiGDKN0b8AD6VluIAKij/6s lgTEkCGHs7dRgKGJFe5ucfCeGKalWDRcs0gyqrLA361tY67IxN0agmYlDbCoAzOakbAp YsWm8CNROsdBNh4EfqhkMadWdhFyps+6aA2LfWGalF7IYnQMCcAGuNjODwL7ejalwhIA bPcneN9CVOlfnhQi8WZjjSl5BrWpyuAMQYESLtXwspSjCybnWWtE35x44SBjpto1Ru4m 8pqQ== X-Gm-Message-State: ALoCoQnpxSPdfo6CyS4IC1TbWYgX5I8YfHqx0wBhG14rQZLFTZ4GPtv8eGfLbqcMyO0kXobhpUA0 MIME-Version: 1.0 X-Received: by 10.112.8.69 with SMTP id p5mr92680777lba.97.1420470762079; Mon, 05 Jan 2015 07:12:42 -0800 (PST) Received: by 10.112.77.231 with HTTP; Mon, 5 Jan 2015 07:12:41 -0800 (PST) In-Reply-To: References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> <27E3CF22-5D4C-4AB3-AB2A-97C93843B9E7@nic.cz> Date: Mon, 5 Jan 2015 07:12:41 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/813_gzMeX4Zk7wAaMW5uHAEOnCE Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 15:12:47 -0000 On Mon, Jan 5, 2015 at 6:28 AM, Ladislav Lhotka wrote: > >> On 05 Jan 2015, at 14:59, Andy Bierman wrote: >> >> On Mon, Jan 5, 2015 at 5:46 AM, Ladislav Lhotka wrote: >>> >>>> On 05 Jan 2015, at 14:20, Andy Bierman wrote: >>>> >>>> On Mon, Jan 5, 2015 at 1:23 AM, Ladislav Lhotka wrote: >>>>> >>>>>> On 22 Dec 2014, at 18:09, Andy Bierman wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I updated the issue tracker with the concrete proposal for >>>>>> ietf-restconf groupings. >>>>> >>>>> I=E2=80=99d rather like to see the definition of the proposed extensi= on, and I will comment on that. >>>>> >>>> >>>> https://github.com/netconf-wg/restconf/issues/15 >>> >>> The ietf-restconf module imports ietf-yang-types. How can an implemento= r figure out which revision of ietf-yang-types to use? >>> >> >> >> Either the server advertises it or the ietf-netconf-monitoring >> module contains that data. > > IMO schemas outside the data and operation resources have to be fixed for= the given RESTconf version. > OK -- but the restconf-resource extension is on github and the ietf-restconf module in draft-03 that does not have an import-by-revision is not related to this issue. However, I share concerns raised by Balazs that the increased complexity and confusion that can result from trying to follow all the revision-specif= ic differences may be unacceptable. (The solution is worse than the original problem.) It might work if the revision-date was the min-revision instead of the exact revision, but we should debate Y45 on the NETMOD list. >> >> How does this have anything to do with the restconf-resource extension? > > This has to do with using YANG as a general schema language, i.e. outside= the normal NETCONF context. > Do you have any objections to the resource-identifier definition? > Lada > Andy > >> >> >>> Lada >>> >> >> Andy >> >>>> >>>> >>>>> Lada >>>> >>>> Andy >>>> >>>>> >>>>>> >>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>> >>>>>> I forgot to mention that ietf-yang-patch.yang already uses the "erro= rs" grouping >>>>>> within the rpc output parameters, so removing it will break YANG Pat= ch. >>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>>> On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka wr= ote: >>>>>>> Andy Bierman writes: >>>>>>> >>>>>>>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund = wrote: >>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>> >>>>>>>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund wro= te: >>>>>>>>>>> >>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>> Andy Bierman writes: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> A new issue has been added to the tracker: >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>>>>> >>>>>>>>>>>>> There are 3 solutions mentioned. >>>>>>>>>>>>> The default solution is S1, which will be implemented >>>>>>>>>>>>> unless there is WG consensus demonstrated to >>>>>>>>>>>>> do something else. >>>>>>>>>>>> >>>>>>>>>>>> The biggest problem with S1 is that it may mislead readers int= o >>>>>>>>>>>> thinking: "Hey, now I understand how namespaces work in groupi= ngs!" >>>>>>>>>>>> >>>>>>>>>>>> I also don't like the idea of defining an ad hoc extension. >>>>>>>>>>> >>>>>>>>>>> I disagree. I think an extension is the best solution in this = case. >>>>>>>>>>> However, we can use a different name than 'structure'. 'struct= ure' >>>>>>>>>>> was originally my proposal for a built-in statement (YANG 1.1) = for >>>>>>>>>>> this purpose. We can call it 'restconf-structure' or 'restconf= -data' >>>>>>>>>>> or something. >>>>>>>>>> >>>>>>>>>> So another document that wants to do the same should define its = own ad >>>>>>>>>> hoc extension? Or import the ietf-restconf module? >>>>>>>>> >>>>>>>>> Suppose we make a new document that defines a new RESTCONF resour= ce >>>>>>>>> type, and we need a structure for it, then that document would im= port >>>>>>>>> and use 'restconf-structure'. >>>>>>>>> >>>>>>>>>>>> If we want >>>>>>>>>>>> to turn YANG into a general schema language, it should be done >>>>>>>>>>>> properly. >>>>>>>>>>>> >>>>>>>>>>>> I think the simplest solution would be to remove the groupings= and >>>>>>>>>>>> have >>>>>>>>>>>> "errors", "restconf", "collection" and "notification" as top-l= evel >>>>>>>>>>>> containers. The namespace assignment then follows YANG rules. >>>>>>>>>>> >>>>>>>>>>> This is also _very_ misleading, b/c then it looks like a normal= config >>>>>>>>>>> or state module, which one would expect a server to implement i= n the >>>>>>>>>>> normal way. >>>>>>>>>> >>>>>>>>>> What makes the solutions with groupings or extensions different? >>>>>>>>> >>>>>>>>> I agree that groupings are misleading. But using an extension wo= uld >>>>>>>>> be different, b/c the extension defines the semantics - this is n= ot >>>>>>>>> config or oper state, but something else. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I do not understand why these are special or misleading groupings. >>>>>>>> I cannot find any text in any RFC that says a YANG module with >>>>>>>> just groupings in it is invalid, improper, or even discouraged. >>>>>>>> >>>>>>>> I am already using 1 of these groupings in a logging model. >>>>>>>> Please explain why these are special groupings that cannot >>>>>>>> be used in a normal data model in another module. >>>>>>>> >>>>>>>> That is why I prefer solution S2-B >>>>>>>> >>>>>>>> rc:structure errors { >>>>>>>> uses errors; >>>>>>>> } >>>>>>>> >>>>>>>> This assigns a module-name and a namespace and does not >>>>>>>> preclude re-usage of the data within a larger data structure. >>>>>>> >>>>>>> I don't want to block the resolution of this issue, so I propose th= at you >>>>>>> write a concrete definition of the extension, and I will then comme= nt on >>>>>>> that. >>>>>>> >>>>>>> Lada >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> In >>>>>>>>>> any case, the module description has to state very clearly that = it is >>>>>>>>>> a strawman module that=E2=80=99s not supposed to be used in the = normal >>>>>>>>>> NETCONF/RESTCONF way. But if you above that deviate from YANG >>>>>>>>>> semantics, as the groupings do, you cannot even use standard YAN= G >>>>>>>>>> tools because they would produce wrong results. >>>>>>>>>> >>>>>>>>>> If the module is as I proposed, I can still use pyang for genera= ting >>>>>>>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>>>>>> >>>>>>>>>> And if a server implementor likes the module and decides to impl= ement >>>>>>>>>> it as if it was a normal module, so what? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> S3 should IMO be fine, too, the structures aren't that complic= ated. >>>>>>>>>>> >>>>>>>>>>> I can see only drawbacks compared to S2. Whatever we do in tex= t it >>>>>>>>>>> will be less precise than an extension. >>>>>>>>>> >>>>>>>>>> I prefer less precise to precise but wrong. >>>>>>>>> >>>>>>>>> An extension is in no way wrong. >>>>>>>>> >>>>>>>> >>>>>>>> agreed >>>>>>>> >>>>>>>>>> Keep in mind that you are >>>>>>>>>> a YANG designer so you are not as likely to get confused by lang= uage >>>>>>>>>> anomalies as an average reader of the RESTCONF document. >>>>>>>>> >>>>>>>>> >>>>>>>>> /martin >>>>>>>> >>>>>>>> Andy >>>>>>> >>>>>>> -- >>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>> PGP Key ID: E74E8C0C >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Mon Jan 5 07:20:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDFE1A00CD for ; Mon, 5 Jan 2015 07:20: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, 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 IeE3B_J0Lrb7 for ; Mon, 5 Jan 2015 07:20:16 -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 51A5D1A00B0 for ; Mon, 5 Jan 2015 07:20:16 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 15:19:52 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) with mapi id 15.01.0049.002; Mon, 5 Jan 2015 15:19:52 +0000 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Andy Bierman Thread-Topic: [Netconf] zerotouch-02 configuration server issues Thread-Index: AQHQG6Q3gpbv6DaYike6abV9cnW8wZyXC26AgABck4CAGQIpgIABANOA Date: Mon, 5 Jan 2015 15:19:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(479174004)(164054003)(51704005)(189002)(24454002)(199003)(377454003)(4396001)(68736005)(86362001)(97736003)(107046002)(36756003)(105586002)(101416001)(92566001)(106116001)(106356001)(2656002)(77156002)(62966003)(99286002)(87936001)(122556002)(19580405001)(19580395003)(99396003)(83506001)(2950100001)(21056001)(102836002)(66066001)(31966008)(54356999)(76176999)(46102003)(40100003)(93886004)(15975445007)(20776003)(50986999)(64706001)(120916001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 05 Jan 2015 15:19:52.0475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yfDyKryyMtmAEWYibyPbPUXm1wA Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch-02 configuration server issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 15:20:22 -0000 Hi Mehmet, The other reason was to assert the use of XML (not JSON) and thus clear the way to using the XMLSIG and XMLENC standards. That said, I'm beginning to think that maybe we should NOT use the XML* standards, as they don't seem to be very popular in my reading of online forums, and also because they are significantly more complicated to implement (requiring XML libraries). A much simpler solution would be one that could be implemented via a shell script making calls to the `openssl` command line utility (of course we wouldn't require the use of `openssl`, the draft would define it using PKCS terms, with maybe a non-normative example using the `openssl` utility) Do you think we should open one issue for moving back to YANG and another for swapping for signing/encryption occurs? Thanks, Kent On 1/4/15, 2:00 PM, "Ersue, Mehmet (NSN - DE/Munich)" wrote: >Hi Kent, > >is there a strong reason for not using YANG (instead of XSD)? >I assume we can solve the "container" issue raised for YANG usage. > >Cheers,=20 >Mehmet=20 > > >> -----Original Message----- >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy >>Bierman >> Sent: Friday, December 19, 2014 10:06 PM >> To: Kent Watsen >> Cc: Netconf >> Subject: Re: [Netconf] zerotouch-02 configuration server issues >>=20 >> On Fri, Dec 19, 2014 at 12:36 PM, Kent Watsen >>wrote: >> > Hi Andy, >> > >> > >> > >> >>The configuration server described in sec. 2 is going to be >> >>an important system component if it is successfully standardized. >> > >> > True. >> > >> > >> > >> >>I do not like the XSD for the configlet. >> >>It reminds me why we invented YANG in the first place. >> >>(Oh yeah, XSD is unreadable. Almost forgot ;-) >> > >> > We had YANG in the -00 version of this draft, it changed to XSD in the >> > -01 version. Btw, -02 hasn't been posted yet, though you reference >>it >> > in the subject line. >> > >>=20 >> typo on my part. >>=20 >>=20 >> > In addition to side-stepping the whole debate regarding the use of a >>YANG >> > "container", the draft simultaneously moved to definitively using >>XML, due >> > to the use of the XMLSIG and XMLENC standards. Do you think this is >>too >> > onerous? Should we track this as an issue? >> > >> > >>=20 >> I guess XSD is OK. It avoids the YANG data structure controversy an >> excludes JSON (which nay be a new controversy ;-) >>=20 >>=20 >> > >> >>The configlets are completely opaque, except there are 2 header fields >> >>"unique-identifier" and "software-version". There is nothing >>identifying >> >>the configuration blob. I think "configuration-identifier" and >> >>"configuration-version" fields are also needed. >> >> >>=20 >>=20 >> Do you agree these extra fields are useful? >> IMO they could be optional. >>=20 >> Some use cases: >> - the identified device may have different config setups, based >> on factors such as licenses, device capabilities, etc. so >> "config-identifier" could identify the config variant >> - cache IDs such as "config-id" (defined in NETCONF-EX) could be mapped >> to the "config-version" field, or a revision-date could be used >>instead. >>=20 >>=20 >> >>I would prefer a more direct mapping to YANG for the "configuration" >> >>element. >> >>It should be possible to have a "vendor-opaque" section, >> >>but it would be nice to know if subtrees in the configlet >> >>actually show up in the running config after booting. >> >>The description in the XSD implies that, but nothing normative. >> > >> > We had something like this back in Feb when the draft was still an >>I.D. >> > [1]. See how the YANG imports "ietf-netconf-server" and copies >>selected >> > parts of the "ietf-system" module? But you're saying that it's OK for >> > there to be vendor-opqaue values - so do you want the draft to say the >> > content of the Configlet MUST/SHOULD have a configuration that maps to >> > these ietf-netconf-server and ietf-system models? >> > >>=20 >>=20 >>=20 >> I would prefer if the configuration element was equivalent to >> the element in a operation. >> There is no constraint on what YANG modules are present. >> Whatever config is present must match YANG module schema >> supported by the server. >>=20 >> I do not know if there is a need for additional XML in the configlet >> that does not map to any advertised YANG module. Phil mentioned >> a need for this sort of bootstrap data at IETF #91. This should >> go in a different element within the configlet. >>=20 >>=20 >> > [1] https://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01 >> > >> > >> > >> > Thanks, >> > Kent >> > >> > >>=20 >>=20 >>=20 >> Andy >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jan 5 07:24:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642E11A00AE for ; Mon, 5 Jan 2015 07:24:01 -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 cLMfrK2yiUvR for ; Mon, 5 Jan 2015 07:23:59 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E98D1A009E for ; Mon, 5 Jan 2015 07:23:59 -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.49.12; Mon, 5 Jan 2015 15:23:58 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) with mapi id 15.01.0049.002; Mon, 5 Jan 2015 15:23:57 +0000 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Andy Bierman , "Reinaldo Penno (repenno)" Thread-Topic: [Netconf] call-home#6: Too busy with all the NETCONF/RESTCONF and SSH/TLS switches? Thread-Index: AQHQGK4ZMVLZeaH6bke4DK+bIvTIApyRLVwAgAACcACAAAmuAIAEVqeAgBq/YgCAASKLgA== Date: Mon, 5 Jan 2015 15:23:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(199003)(24454002)(164054003)(189002)(377454003)(51704005)(76176999)(54356999)(97736003)(4396001)(120916001)(99286002)(122556002)(50986999)(40100003)(21056001)(46102003)(2900100001)(68736005)(99396003)(2950100001)(36756003)(93886004)(102836002)(87936001)(83506001)(2656002)(92566001)(86362001)(77156002)(62966003)(31966008)(64706001)(106116001)(66066001)(106356001)(101416001)(107046002)(20776003)(105586002)(19580395003)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 05 Jan 2015 15:23:57.3512 (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: http://mailarchive.ietf.org/arch/msg/netconf/OVbXQ8J02O_GHa5qwykT9sk0CB4 Cc: Netconf Subject: Re: [Netconf] call-home#6: Too busy with all the NETCONF/RESTCONF and SSH/TLS switches? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 15:24:01 -0000 On 1/4/15, 2:01 PM, "Ersue, Mehmet (NSN - DE/Munich)" wrote: >Hi Kent, All, > >as I stated on Github I am against splitting the draft into two. >I believe we can improve the readability, e.g. by writing >Restconf-related statements in separate sentences or collecting Restconf >text in a subsection. > >That said I do not see consensus on the maillist for splitting the >call-home draft. Agreed, no consensus to split the draft. But there does seem to be consensus that the current draft is hard to read. Making it easier to read is the only significant open issue currently... Thanks, Kent From nobody Mon Jan 5 07:34:45 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BD21A005E for ; Mon, 5 Jan 2015 07:34: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 y6sMVlZH7oyU for ; Mon, 5 Jan 2015 07:34:41 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E8A1A00FF for ; Mon, 5 Jan 2015 07:34:40 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 15:34:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) with mapi id 15.01.0049.002; Mon, 5 Jan 2015 15:34:38 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] server-model #18: how to configure trust-anchors for SSH X.509-based client certs? Thread-Index: AQHQGKPzk1Sq1rK1okK6CUcPscsM05yROciAgAQLQICAAF9cgP//6KmAgABjoICAG4RvAA== Date: Mon, 5 Jan 2015 15:34:38 +0000 Message-ID: References: <20141215222153.GA63558@elstar.local> <20141218174831.GA28619@elstar.local> 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.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(377454003)(479174004)(164054003)(51704005)(83506001)(2950100001)(66066001)(102836002)(21056001)(122556002)(87936001)(99396003)(19580405001)(19580395003)(120916001)(2900100001)(46102003)(40100003)(54356999)(76176999)(93886004)(31966008)(50986999)(64706001)(20776003)(15975445007)(101416001)(92566001)(105586002)(106356001)(106116001)(97736003)(107046002)(36756003)(4396001)(68736005)(86362001)(110136001)(99286002)(2656002)(62966003)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <8EAE45699FED224A80AB00C84E5CDC4D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2015 15:34:38.2622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/v8T_BpPPX5v-OvnVUSkYLz_9ENg Cc: NetConf Subject: Re: [Netconf] server-model #18: how to configure trust-anchors for SSH X.509-based client certs? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 15:34:43 -0000 >From both Juergen's and Andy's comments, the consensus appears to be to close #21 with a "WG consensus NOT granted". As these comments were made more then two weeks ago, I'll plan to do this during today's virtual interim meeting. Thanks, Kent On 12/18/14, 5:21 PM, "Andy Bierman" wrote: >On Thu, Dec 18, 2014 at 1:24 PM, Kent Watsen wrote: >> >> >>>Are there implementations that do not have these timeouts? That is, >>>are there servers that wait forever if a client connects and simply >>>does nothing? >>> >>>I understand that making everything optional features is great because >>>then there is not much left to implement but then if almost everybody >>>implements a certain feature, it might be easier to simply make things >>>mandatory. >> >> >> So this is what issue #21 is about: >> https://github.com/netconf-wg/server-model/issues/21 >> > >The comment cited in the issue tracker does not give a reason >why servers should not have to implement these timeouts. > >> I agree that it seems that servers would always implement these timeouts >> and thus having no if-feature statement would be OK. It is what I had >> originally after all. But the issue was raise at the IETF 91 meeting >>and >> is now being confirmed on the list (see email with subject "server-model >> #21: Add a feature around the global-params section"). So far there has >> been no response to that email, though I think you have just now raise >> some skepticism towards needing to do it. > >We should always justify YANG features wrt/ large resource requirement >or related to an optional protocol, etc. If we do not think it is an >implementation >burden then make it part of the base module. More importantly, if lack >of implementation can disrupt operations, then it has to be part of the >base >module. > >In this case, lack of timeouts can disrupt the server if there is a >maximum >number of sessions allowed. Without timeouts, some app can intentionally >or accidentally lock out other apps by using up all the allowed admin >sessions. > > > >> >> Kent > > >Andy > >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jan 5 08:09:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819D1A1A3E for ; Mon, 5 Jan 2015 08:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 GeDwCZXfGsTT for ; Mon, 5 Jan 2015 08:09:11 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA911A1A42 for ; Mon, 5 Jan 2015 08:09:07 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t05G94RP010051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jan 2015 16:09:05 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t05G94U8011599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 17:09:04 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 17:09:03 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Kent Watsen , ext Andy Bierman Thread-Topic: [Netconf] zerotouch-02 configuration server issues Thread-Index: AQHQG6Q28nAoW9Pevk+8t4ynBsdkz5yXTvAAgAAITYCAGQRY8IABUnkAgAAeUsA= Date: Mon, 5 Jan 2015 16:09:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5671 X-purgate-ID: 151667::1420474145-00002DC5-A9ADCA5A/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8BmII17YYjokD9mt2Ie7kmUzLDE Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch-02 configuration server issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:09:15 -0000 Hi Kent, let's discuss these issues today in the virtual meeting. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Kent Watsen [mailto:kwatsen@juniper.net] > Sent: Monday, January 05, 2015 4:20 PM > To: Ersue, Mehmet (NSN - DE/Munich); ext Andy Bierman > Cc: netconf@ietf.org > Subject: Re: [Netconf] zerotouch-02 configuration server issues >=20 >=20 > Hi Mehmet, >=20 > The other reason was to assert the use of XML (not JSON) and thus clear > the way to using the XMLSIG and XMLENC standards. That said, I'm > beginning to think that maybe we should NOT use the XML* standards, as > they don't seem to be very popular in my reading of online forums, and > also because they are significantly more complicated to implement > (requiring XML libraries). A much simpler solution would be one that > could be implemented via a shell script making calls to the `openssl` > command line utility (of course we wouldn't require the use of `openssl`, > the draft would define it using PKCS terms, with maybe a non-normative > example using the `openssl` utility) >=20 > Do you think we should open one issue for moving back to YANG and another > for swapping for signing/encryption occurs? >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 > On 1/4/15, 2:00 PM, "Ersue, Mehmet (NSN - DE/Munich)" > wrote: >=20 > >Hi Kent, > > > >is there a strong reason for not using YANG (instead of XSD)? > >I assume we can solve the "container" issue raised for YANG usage. > > > >Cheers, > >Mehmet > > > > > >> -----Original Message----- > >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy > >>Bierman > >> Sent: Friday, December 19, 2014 10:06 PM > >> To: Kent Watsen > >> Cc: Netconf > >> Subject: Re: [Netconf] zerotouch-02 configuration server issues > >> > >> On Fri, Dec 19, 2014 at 12:36 PM, Kent Watsen > >>wrote: > >> > Hi Andy, > >> > > >> > > >> > > >> >>The configuration server described in sec. 2 is going to be > >> >>an important system component if it is successfully standardized. > >> > > >> > True. > >> > > >> > > >> > > >> >>I do not like the XSD for the configlet. > >> >>It reminds me why we invented YANG in the first place. > >> >>(Oh yeah, XSD is unreadable. Almost forgot ;-) > >> > > >> > We had YANG in the -00 version of this draft, it changed to XSD in t= he > >> > -01 version. Btw, -02 hasn't been posted yet, though you reference > >>it > >> > in the subject line. > >> > > >> > >> typo on my part. > >> > >> > >> > In addition to side-stepping the whole debate regarding the use of a > >>YANG > >> > "container", the draft simultaneously moved to definitively using > >>XML, due > >> > to the use of the XMLSIG and XMLENC standards. Do you think this is > >>too > >> > onerous? Should we track this as an issue? > >> > > >> > > >> > >> I guess XSD is OK. It avoids the YANG data structure controversy an > >> excludes JSON (which nay be a new controversy ;-) > >> > >> > >> > > >> >>The configlets are completely opaque, except there are 2 header fiel= ds > >> >>"unique-identifier" and "software-version". There is nothing > >>identifying > >> >>the configuration blob. I think "configuration-identifier" and > >> >>"configuration-version" fields are also needed. > >> >> > >> > >> > >> Do you agree these extra fields are useful? > >> IMO they could be optional. > >> > >> Some use cases: > >> - the identified device may have different config setups, based > >> on factors such as licenses, device capabilities, etc. so > >> "config-identifier" could identify the config variant > >> - cache IDs such as "config-id" (defined in NETCONF-EX) could be mapp= ed > >> to the "config-version" field, or a revision-date could be used > >>instead. > >> > >> > >> >>I would prefer a more direct mapping to YANG for the "configuration" > >> >>element. > >> >>It should be possible to have a "vendor-opaque" section, > >> >>but it would be nice to know if subtrees in the configlet > >> >>actually show up in the running config after booting. > >> >>The description in the XSD implies that, but nothing normative. > >> > > >> > We had something like this back in Feb when the draft was still an > >>I.D. > >> > [1]. See how the YANG imports "ietf-netconf-server" and copies > >>selected > >> > parts of the "ietf-system" module? But you're saying that it's OK f= or > >> > there to be vendor-opqaue values - so do you want the draft to say t= he > >> > content of the Configlet MUST/SHOULD have a configuration that maps = to > >> > these ietf-netconf-server and ietf-system models? > >> > > >> > >> > >> > >> I would prefer if the configuration element was equivalent to > >> the element in a operation. > >> There is no constraint on what YANG modules are present. > >> Whatever config is present must match YANG module schema > >> supported by the server. > >> > >> I do not know if there is a need for additional XML in the configlet > >> that does not map to any advertised YANG module. Phil mentioned > >> a need for this sort of bootstrap data at IETF #91. This should > >> go in a different element within the configlet. > >> > >> > >> > [1] https://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01 > >> > > >> > > >> > > >> > Thanks, > >> > Kent > >> > > >> > > >> > >> > >> > >> Andy > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jan 5 08:23:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2351A1A9F for ; Mon, 5 Jan 2015 08:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8sE1SDIYaf0n for ; Mon, 5 Jan 2015 08:23:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8881A0047 for ; Mon, 5 Jan 2015 08:23:02 -0800 (PST) Received: from [192.168.131.143] ([80.92.122.140]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lbuo0-1XR6RA1xa8-00jKTf; Mon, 05 Jan 2015 17:22:56 +0100 Message-ID: <54AABA5F.6000002@gmx.net> Date: Mon, 05 Jan 2015 17:22:55 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , ext Andy Bierman References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BMHCGkD3rd1uwVa3qITNKHkKippKbXhMQ" X-Provags-ID: V03:K0:HeBxwsVbF+HJlTSysUZ0bBwD7o982B3dQMdDvLmkjEm9YraeYDD KQ7CKVnz8dSgqAhszO+NFanpUnYM7rmFnNVbC/dnfEJQ/AnUD2sXuO8/BdgXCNqISewwVLq 5z58fUVfZXSWK2B3izunUzkilSMzxPnF5O8g0pB8pg5l5oqmIHW3lDMPxgur4/LHxopRAKr /8UECBZHz+EbJkXo390vQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/n1t-0IX5aybMn7dI5GyR98NBoPc Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch-02 configuration server issues X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 16:23:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BMHCGkD3rd1uwVa3qITNKHkKippKbXhMQ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable There are two issues: 1) What is the schema language used to describe the data model? There are many choices and today you are using the XML schema. The XML schema also happens to be encoded in XML. Another option is also not to have a formal language at all. Just describe it in words. 2) What is the encoding of the data sent over the wire? Currently you are using XML for that purpose. XML-DSIG and XML-ENC is relevant for this part. I am not sure how Yang, OpenSSL, and some of the other things you mention below fit into the bigger picture. Ciao Hannes On 01/05/2015 04:19 PM, Kent Watsen wrote: >=20 > Hi Mehmet, >=20 > The other reason was to assert the use of XML (not JSON) and thus clear= > the way to using the XMLSIG and XMLENC standards. That said, I'm > beginning to think that maybe we should NOT use the XML* standards, as > they don't seem to be very popular in my reading of online forums, and > also because they are significantly more complicated to implement > (requiring XML libraries). A much simpler solution would be one that > could be implemented via a shell script making calls to the `openssl` > command line utility (of course we wouldn't require the use of `openssl= `, > the draft would define it using PKCS terms, with maybe a non-normative > example using the `openssl` utility) >=20 > Do you think we should open one issue for moving back to YANG and anoth= er > for swapping for signing/encryption occurs? >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 > On 1/4/15, 2:00 PM, "Ersue, Mehmet (NSN - DE/Munich)" > wrote: >=20 >> Hi Kent, >> >> is there a strong reason for not using YANG (instead of XSD)? >> I assume we can solve the "container" issue raised for YANG usage. >> >> Cheers,=20 >> Mehmet=20 >> >> >>> -----Original Message----- >>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy= >>> Bierman >>> Sent: Friday, December 19, 2014 10:06 PM >>> To: Kent Watsen >>> Cc: Netconf >>> Subject: Re: [Netconf] zerotouch-02 configuration server issues >>> >>> On Fri, Dec 19, 2014 at 12:36 PM, Kent Watsen >>> wrote: >>>> Hi Andy, >>>> >>>> >>>> >>>>> The configuration server described in sec. 2 is going to be >>>>> an important system component if it is successfully standardized. >>>> >>>> True. >>>> >>>> >>>> >>>>> I do not like the XSD for the configlet. >>>>> It reminds me why we invented YANG in the first place. >>>>> (Oh yeah, XSD is unreadable. Almost forgot ;-) >>>> >>>> We had YANG in the -00 version of this draft, it changed to XSD in t= he >>>> -01 version. Btw, -02 hasn't been posted yet, though you reference= >>> it >>>> in the subject line. >>>> >>> >>> typo on my part. >>> >>> >>>> In addition to side-stepping the whole debate regarding the use of a= >>> YANG >>>> "container", the draft simultaneously moved to definitively using >>> XML, due >>>> to the use of the XMLSIG and XMLENC standards. Do you think this is= >>> too >>>> onerous? Should we track this as an issue? >>>> >>>> >>> >>> I guess XSD is OK. It avoids the YANG data structure controversy an >>> excludes JSON (which nay be a new controversy ;-) >>> >>> >>>> >>>>> The configlets are completely opaque, except there are 2 header fie= lds >>>>> "unique-identifier" and "software-version". There is nothing >>> identifying >>>>> the configuration blob. I think "configuration-identifier" and >>>>> "configuration-version" fields are also needed. >>>>> >>> >>> >>> Do you agree these extra fields are useful? >>> IMO they could be optional. >>> >>> Some use cases: >>> - the identified device may have different config setups, based >>> on factors such as licenses, device capabilities, etc. so >>> "config-identifier" could identify the config variant >>> - cache IDs such as "config-id" (defined in NETCONF-EX) could be map= ped >>> to the "config-version" field, or a revision-date could be used >>> instead. >>> >>> >>>>> I would prefer a more direct mapping to YANG for the "configuration= " >>>>> element. >>>>> It should be possible to have a "vendor-opaque" section, >>>>> but it would be nice to know if subtrees in the configlet >>>>> actually show up in the running config after booting. >>>>> The description in the XSD implies that, but nothing normative. >>>> >>>> We had something like this back in Feb when the draft was still an >>> I.D. >>>> [1]. See how the YANG imports "ietf-netconf-server" and copies >>> selected >>>> parts of the "ietf-system" module? But you're saying that it's OK f= or >>>> there to be vendor-opqaue values - so do you want the draft to say t= he >>>> content of the Configlet MUST/SHOULD have a configuration that maps = to >>>> these ietf-netconf-server and ietf-system models? >>>> >>> >>> >>> >>> I would prefer if the configuration element was equivalent to >>> the element in a operation. >>> There is no constraint on what YANG modules are present. >>> Whatever config is present must match YANG module schema >>> supported by the server. >>> >>> I do not know if there is a need for additional XML in the configlet >>> that does not map to any advertised YANG module. Phil mentioned >>> a need for this sort of bootstrap data at IETF #91. This should >>> go in a different element within the configlet. >>> >>> >>>> [1] https://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01 >>>> >>>> >>>> >>>> Thanks, >>>> Kent >>>> >>>> >>> >>> >>> >>> Andy >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 --BMHCGkD3rd1uwVa3qITNKHkKippKbXhMQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUqrpfAAoJEGhJURNOOiAtpuIH/Aqj43H35xfEgiI1N7f0mxeF xDOziIC4acec52+rZt5KtZM/X4mtY/Qa0U8EeGf744klqpYgJ6iMvkssGUS0B38E pHUCXe8dBkc/aFtAE8LTixYyPLzIkOyw8YFw2vkRE0Y1cxvkNSp7TsEgeABAwWEL rs6ZZ2UPTTp63oVFVznff9C+qnzzCwGrXB6/UX/OtZf9H3mbNQgLpQ5G1O2t5gQQ 2LD9clstkdLlAenE4DEPpWNZfmtFYphn0f7xgxdmI/7MhL2Pqlm2Yzn83poiTk+0 MEiI216TVUXv3mzxrrV06qCaIqLUFqGiLqpVLtfgMN1JYU7w77h1I/dc9U2FKjQ= =TNoa -----END PGP SIGNATURE----- --BMHCGkD3rd1uwVa3qITNKHkKippKbXhMQ-- From nobody Mon Jan 5 09:14:14 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9791A6FDB for ; Mon, 5 Jan 2015 09:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 3srG8D7AB84R for ; Mon, 5 Jan 2015 09:14: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 42E221A7030 for ; Mon, 5 Jan 2015 09:14: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 0E94AA8E for ; Mon, 5 Jan 2015 18:14: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 RP5h5YX0vfc2 for ; Mon, 5 Jan 2015 18:14: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 for ; Mon, 5 Jan 2015 18:14:09 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B3132002C for ; Mon, 5 Jan 2015 18:14:09 +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 wpjpjgqvmY54; Mon, 5 Jan 2015 18:14:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6104320017; Mon, 5 Jan 2015 18:14:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 41ACF304FD33; Mon, 5 Jan 2015 18:14:08 +0100 (CET) Date: Mon, 5 Jan 2015 18:14:08 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20150105171408.GA8394@elstar.local> Mail-Followup-To: netconf@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: http://mailarchive.ietf.org/arch/msg/netconf/9o3KYk6vZg6brV5n21vgIWrpums Subject: [Netconf] netconf call home term 'tcp session' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:14:12 -0000 Hi, looking at draft-ietf-netconf-call-home-02.txt section 2.1, I see this: o The TCP connection is accepted and a TCP session is established. Similar in 3.1, I see this: o The NETCONF/RESTCONF client accepts an incoming TCP connection and a TCP session is established. I am not sure what this "TCP session" is - I think RFC 793 never talks about a session. Why can we not simply talk about the TCP connection, thereby eliminating this TCP session term / step? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 5 11:57:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066F71A8987 for ; Mon, 5 Jan 2015 11:56:52 -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 tqs7F9KgDqR0 for ; Mon, 5 Jan 2015 11:56:46 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136281A89F5 for ; Mon, 5 Jan 2015 11:39:50 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 19:39:49 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) with mapi id 15.01.0049.002; Mon, 5 Jan 2015 19:39:49 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] netconf call home term 'tcp session' Thread-Index: AQHQKQsNS/cpmIkWS06aUXE6uabINpyxmNGA Date: Mon, 5 Jan 2015 19:39:48 +0000 Message-ID: References: <20150105171408.GA8394@elstar.local> In-Reply-To: <20150105171408.GA8394@elstar.local> 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.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB457; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(51704005)(24454002)(479174004)(199003)(189002)(36756003)(31966008)(87936001)(101416001)(62966003)(2656002)(4396001)(15975445007)(68736005)(102836002)(54356999)(76176999)(2950100001)(2900100001)(77156002)(86362001)(92566001)(21056001)(50986999)(40100003)(2501002)(105586002)(106356001)(106116001)(97736003)(107046002)(107886001)(99396003)(122556002)(99286002)(120916001)(46102003)(19580395003)(19580405001)(83506001)(20776003)(64706001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 05 Jan 2015 19:39:48.4089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/sKWvxuO-TYILQ_UIzIDbl8hT6XI Subject: Re: [Netconf] netconf call home term 'tcp session' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 19:56:52 -0000 True, RFC 793 does not use the term "tcp session", but other RFCs do: https://www.google.com/search?&q=3D%22tcp+session%22+site:ietf.org The reason is because of comments received regarding which TCP connection/session was being used. The current text uses these different terms in trying to be more clear (perhaps not). As currently written, the term "connection" only appears once, in a desperate attempt to put an end to how many connections there are ;) You still think it should be changed? Thanks, Kent On 1/5/15, 12:14 PM, "Juergen Schoenwaelder" wrote: >Hi, > >looking at draft-ietf-netconf-call-home-02.txt section 2.1, I see this: > > o The TCP connection is accepted and a TCP session is established. > >Similar in 3.1, I see this: > > o The NETCONF/RESTCONF client accepts an incoming TCP connection and > a TCP session is established. > >I am not sure what this "TCP session" is - I think RFC 793 never talks >about a session. Why can we not simply talk about the TCP connection, >thereby eliminating this TCP session term / step? > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jan 5 12:35:16 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92F11A898E for ; Mon, 5 Jan 2015 12:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 52ltLg0chEX9 for ; Mon, 5 Jan 2015 12:35:11 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF671A88B1 for ; Mon, 5 Jan 2015 12:35:09 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t05KYrPK004277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 Jan 2015 12:34:53 -0800 (PST) Message-ID: <54AAF56F.3040606@isi.edu> Date: Mon, 05 Jan 2015 12:34:55 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kent Watsen , Juergen Schoenwaelder , "netconf@ietf.org" References: <20150105171408.GA8394@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/F0jTtKM4q_4DQ_TO8oc9uFEXjeM Subject: Re: [Netconf] netconf call home term 'tcp session' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:35:13 -0000 On 1/5/2015 11:39 AM, Kent Watsen wrote: > > True, RFC 793 does not use the term "tcp session", but other RFCs do: > > https://www.google.com/search?&q=%22tcp+session%22+site:ietf.org EPP refers to a session, and then goes on to refer (IMO incorrectly) to TCP sessions. That's the primary BCP/standard doc series that does so. NAT and STUN refer to sessions to include associations over non-connection protocols. SIP's and RTP's brief of the term is likely related to other parts of the protocol being called "session". Others are Historic. IMO, it ought to be referred to as a TCP connection. A session is an association which may or may not involve a TCP connection. > The reason is because of comments received regarding which TCP > connection/session was being used. The current text uses these different > terms in trying to be more clear (perhaps not). As currently written, the > term "connection" only appears once, in a desperate attempt to put an end > to how many connections there are ;) > > You still think it should be changed? FWIW, I do. Overall, the TCP language needs cleaning. E.g.: > o The NETCONF/RESTCONF server initiates a TCP connection to the a TCP connection request (SYN) > NETCONF/RESTCONF client on one of the IANA-assigned ports for call > home (PORT-X for netconf-ch-ssh, PORT-Y for netconf-ch-tls, or > PORT-Z for restconf-ch-tls). > > o The TCP connection is accepted and a TCP session is established. The TCP connection request is accepted and a TCP connection is established. > o Using this TCP session, the NETCONF/RESTCONF server immediately TCP connection > starts either the SSH-server or the TLS-server protocol, depending > on which port is connected. The server MUST start the SSH-server depending on which port is used in the connection. [note - ports aren't "connected"; they're only 1/4 of a TCP connection identifier] > protocol when port PORT-X is connected or the TLS-server protocol > when either port PORT-Y or PORT-Z is connected. The SSH-server > and TLS-server protocols are described by [RFC4253] and [RFC5246] > respectively. I'm not sure why you're mandating when the server must be started. That's an implementation issue, and when it starts depends on how incoming connection requests are handled. However, the server must be started before *user data* is exchanged. AFAICT there is no requirement that the service be started before a port is used in a TCP connection in the ESTABLISHED state. I think what you mean to say here can be sufficiently indicated as: o Using this TCP connection, the NETCONF/RESTCONF server MUST immediately start using either the SSH-server or the TLS-server protocol, depending on which port receives the connection request. The SSH-server and TLS-server protocols are described by [RFC4253] and [RFC5246] respectively. Joe From nobody Mon Jan 5 12:46:18 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE461A8A49 for ; Mon, 5 Jan 2015 12:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 B0fDBe8TvTOP for ; Mon, 5 Jan 2015 12:46:14 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4D21A8A48 for ; Mon, 5 Jan 2015 12:46:13 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t05KkAj4020793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jan 2015 20:46:10 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t05KkA7p025173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 21:46:10 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 5 Jan 2015 21:46:10 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 21:46:10 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AdApKKHQsmh1voQ5Sgudn5IwYOG+2Q== Date: Mon, 5 Jan 2015 20:46:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.107] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8195A73B5DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3470 X-purgate-ID: 151667::1420490771-00001177-9BA13C97/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/TVqltBBUlgSC3FsTEJFQaJUr7K0 Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:46:17 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195A73B5DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF Members, we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. The document can be found at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 Please review and send your comments to the WG mailing list by January 19, = 2015 EOB PT. The document is planned to publish as a standard track document. As a minimum please state that you have read/reviewed and whether you suppo= rt the publication. Please indicate also if you plan to implement or have already implementatio= n experience with the rfc5539bis draft. Thank you. Mehmet and Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F8195A73B5DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF Members,
 
we hereby issue a WG Last Call for draft-ietf-= netconf-rfc5539bis-07.
 
The document can be found at:
 
Please review and send your comments to the WG= mailing list by January 19, 2015 EOB PT.
 
The document is planned to publish as a standa= rd track document.
As a minimum please state that you have read/r= eviewed and whether you support the publication.
 
Please indicate also if you plan to implement = or have already implementation experience with the rfc5539bis draft.=
 
Thank you.
Mehmet and Mahesh
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195A73B5DEMUMBX005nsnin_-- From nobody Mon Jan 5 13:24:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76361A8AAF for ; Mon, 5 Jan 2015 13:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 8JRNrOfQdmzJ for ; Mon, 5 Jan 2015 13: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 C496D1A8AAC for ; Mon, 5 Jan 2015 13:24: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 391F272D; Mon, 5 Jan 2015 22:24: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 Sb5Z6aGBttci; Mon, 5 Jan 2015 22:24: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; Mon, 5 Jan 2015 22:24:37 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F29F2002C; Mon, 5 Jan 2015 22:24:37 +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 YtuyHSMz9w8k; Mon, 5 Jan 2015 22: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 5B55120017; Mon, 5 Jan 2015 22:24:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 76DAD304FF32; Mon, 5 Jan 2015 22:24:37 +0100 (CET) Date: Mon, 5 Jan 2015 22:24:36 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150105212436.GA8900@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20150105171408.GA8394@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: http://mailarchive.ietf.org/arch/msg/netconf/ymXiu_DHxRsPNapW1FVaYiCMy7M Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf call home term 'tcp session' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 21:24:42 -0000 On Mon, Jan 05, 2015 at 07:39:48PM +0000, Kent Watsen wrote: > > True, RFC 793 does not use the term "tcp session", but other RFCs do: > > https://www.google.com/search?&q=%22tcp+session%22+site:ietf.org > > The reason is because of comments received regarding which TCP > connection/session was being used. The current text uses these different > terms in trying to be more clear (perhaps not). As currently written, the > term "connection" only appears once, in a desperate attempt to put an end > to how many connections there are ;) > > You still think it should be changed? > Yes, since as far as I can tell, there are only TCP connections. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 5 13:43:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F421A8AF7 for ; Mon, 5 Jan 2015 13:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 q7DJKbzagjDN for ; Mon, 5 Jan 2015 13:43:41 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5CB1A8ACE for ; Mon, 5 Jan 2015 13:43:41 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t05Lh5Us019692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 Jan 2015 13:43:06 -0800 (PST) Message-ID: <54AB0569.5070701@isi.edu> Date: Mon, 05 Jan 2015 13:43:05 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" References: <20150105171408.GA8394@elstar.local> <20150105212436.GA8900@elstar.local> In-Reply-To: <20150105212436.GA8900@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-OglVBIOlRW1wVAlY4IcOThe3fU Subject: Re: [Netconf] netconf call home term 'tcp session' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 21:43:46 -0000 On 1/5/2015 1:24 PM, Juergen Schoenwaelder wrote: > On Mon, Jan 05, 2015 at 07:39:48PM +0000, Kent Watsen wrote: >> >> True, RFC 793 does not use the term "tcp session", but other RFCs do: >> >> https://www.google.com/search?&q=%22tcp+session%22+site:ietf.org >> >> The reason is because of comments received regarding which TCP >> connection/session was being used. The current text uses these different >> terms in trying to be more clear (perhaps not). As currently written, the >> term "connection" only appears once, in a desperate attempt to put an end >> to how many connections there are ;) >> >> You still think it should be changed? >> > > Yes, since as far as I can tell, there are only TCP connections. TCP's API (as per RFC793) allows for more than just connections, e.g., associations between userland and a socket (i.e., addr/port pair, not the Unix thing). Those are local within a machine, though. I don't think that matters much for this doc, though. Joe From nobody Mon Jan 5 19:55:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE101A0E10 for ; Mon, 5 Jan 2015 19:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.304 X-Spam-Level: X-Spam-Status: No, score=-95.304 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_46=0.256, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 xggVkot0tWln for ; Mon, 5 Jan 2015 19:55:37 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4601A07BC for ; Mon, 5 Jan 2015 19:55:37 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 31ED45CC056F1 for ; Tue, 6 Jan 2015 11:55:32 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id E6BF0731922BF for ; Tue, 6 Jan 2015 11:55:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t063tNu5090439 for ; Tue, 6 Jan 2015 11:55:23 +0800 (GMT-8) (envelope-from chen.qiaogang@zte.com.cn) In-Reply-To: References: To: netconf@ietf.org MIME-Version: 1.0 X-KeepSent: 89848A2E:807A50AD-48257DC5:00152B0F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: chen.qiaogang@zte.com.cn Date: Tue, 6 Jan 2015 11:55:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-01-06 11:55:07, Serialize complete at 2015-01-06 11:55:07 Content-Type: multipart/related; boundary="=_related 00158A1948257DC5_=" X-MAIL: mse01.zte.com.cn t063tNu5090439 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FoQUKk4gGOvGICyP_shGcH7gnis Subject: [Netconf] =?gb2312?b?tPC4tDogTmV0Y29uZiBEaWdlc3QsIFZvbCA4MywgSXNz?= =?gb2312?b?dWUgOA==?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 03:55:41 -0000 This is a multipart message in MIME format. --=_related 00158A1948257DC5_= Content-Type: multipart/alternative; boundary="=_alternative 00158A2148257DC5_=" --=_alternative 00158A2148257DC5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VG8gbXkgdW5kZXJzdGFuZGluZywgdXNpbmcgdGhlc2UgdHdvIHdvcmRzIGF0IHRoZSBzYW1lIGNv bnRleHQgd2lsbCBiZSANCmNvbmZ1c2luZy4gT3IgeW91IHByb3ZpZGUgYSBwcmVjaXNlIGRlZmlu aXRpb24gdG8gY2xhcmlmeSB0aGVtLg0KDQp0aGFua3MuDQoNCg0KDQoNCg0KDQpDSEVOIFFpYW9n YW5nIA0Ks8LHzrjWDQpOZXR3b3JrIE1hbmFnZW1lbnQgU3lzdGVtIERlcGFydG1lbnQgDQrN+Lnc xr3MqM+1zbOyvw0KV2lyZWxpbmUgQWNhZGFteSANCtPQz9/Uug0KDQoNClByb2R1Y3QgUiZEIFN5 c3RlbSANCrL6xrfR0LeizOXPtQ0KUiZEIEJ1aWxkaW5nIDMsIFpURSBJbmR1c3RyaWFsIFBhcmsg DQpMaXV4aWFuIFJvYWQsIFhpbGksIE5hbnNoYW4gRGlzdHJpY3QsIFNoZW56aGVuLCBQLlIuQ2hp bmENCsnu29rEz8m9zvfA9sH0z8m087XA1tDQy82o0ba5pNK11LDR0LeiM7rFwqXN+Lncz7XNs7K/ DQpQb3N0OjUxODA1NQ0KVGVsOis4Ni03NTUtMjY3NzM3MTENCkZheDorODYtNzU1LTI2NzczNTgz DQpFbWFpbDpjaGVuLnFpYW9nYW5nQHp0ZS5jb20uY24gDQoNCg0KDQoNCg0KbmV0Y29uZi1yZXF1 ZXN0QGlldGYub3JnIA0Kt6K8/sjLOiAgIk5ldGNvbmYiIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5v cmc+DQoyMDE1LTAxLTA2IDA0OjAxDQrH67TwuLQguPgNCm5ldGNvbmZAaWV0Zi5vcmcNCg0KDQrK 1bz+yMsNCm5ldGNvbmZAaWV0Zi5vcmcsIA0Ks63LzQ0KDQrW98ziDQpOZXRjb25mIERpZ2VzdCwg Vm9sIDgzLCBJc3N1ZSA4DQoNCg0KDQoNCg0KDQpTZW5kIE5ldGNvbmYgbWFpbGluZyBsaXN0IHN1 Ym1pc3Npb25zIHRvDQogICAgICAgICAgICAgICAgIG5ldGNvbmZAaWV0Zi5vcmcNCg0KVG8gc3Vi c2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQogICAg ICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u Zg0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hl bHAnIHRvDQogICAgICAgICAgICAgICAgIG5ldGNvbmYtcmVxdWVzdEBpZXRmLm9yZw0KDQpZb3Ug Y2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCiAgICAgICAgICAgICAg ICAgbmV0Y29uZi1vd25lckBpZXRmLm9yZw0KDQpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5 b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQp0aGFuICJSZTogQ29udGVu dHMgb2YgTmV0Y29uZiBkaWdlc3QuLi4iDQoNCg0KVG9kYXkncyBUb3BpY3M6DQoNCiAgIDEuIG5l dGNvbmYgY2FsbCBob21lIHRlcm0gJ3RjcCBzZXNzaW9uJyAoSnVlcmdlbiBTY2hvZW53YWVsZGVy KQ0KICAgMi4gUmU6IG5ldGNvbmYgY2FsbCBob21lIHRlcm0gJ3RjcCBzZXNzaW9uJyAoS2VudCBX YXRzZW4pDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNZXNzYWdlOiAxDQpEYXRlOiBNb24sIDUgSmFu IDIwMTUgMTg6MTQ6MDggKzAxMDANCkZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KVG86IG5ldGNvbmZAaWV0Zi5vcmcNClN1 YmplY3Q6IFtOZXRjb25mXSBuZXRjb25mIGNhbGwgaG9tZSB0ZXJtICd0Y3Agc2Vzc2lvbicNCk1l c3NhZ2UtSUQ6IDwyMDE1MDEwNTE3MTQwOC5HQTgzOTRAZWxzdGFyLmxvY2FsPg0KQ29udGVudC1U eXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXVzLWFzY2lpDQoNCkhpLA0KDQpsb29raW5nIGF0IGRy YWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMDIudHh0IHNlY3Rpb24gMi4xLCBJIHNlZSB0aGlz Og0KDQogICBvICBUaGUgVENQIGNvbm5lY3Rpb24gaXMgYWNjZXB0ZWQgYW5kIGEgVENQIHNlc3Np b24gaXMgZXN0YWJsaXNoZWQuDQoNClNpbWlsYXIgaW4gMy4xLCBJIHNlZSB0aGlzOg0KDQogICBv ICBUaGUgTkVUQ09ORi9SRVNUQ09ORiBjbGllbnQgYWNjZXB0cyBhbiBpbmNvbWluZyBUQ1AgY29u bmVjdGlvbiBhbmQNCiAgICAgIGEgVENQIHNlc3Npb24gaXMgZXN0YWJsaXNoZWQuDQoNCkkgYW0g bm90IHN1cmUgd2hhdCB0aGlzICJUQ1Agc2Vzc2lvbiIgaXMgLSBJIHRoaW5rIFJGQyA3OTMgbmV2 ZXIgdGFsa3MNCmFib3V0IGEgc2Vzc2lvbi4gV2h5IGNhbiB3ZSBub3Qgc2ltcGx5IHRhbGsgYWJv dXQgdGhlIFRDUCBjb25uZWN0aW9uLA0KdGhlcmVieSBlbGltaW5hdGluZyB0aGlzIFRDUCBzZXNz aW9uIHRlcm0gLyBzdGVwPw0KDQovanMNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAg ICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAw IDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCkZheDog ICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1lc3NhZ2U6IDIN CkRhdGU6IE1vbiwgNSBKYW4gMjAxNSAxOTozOTo0OCArMDAwMA0KRnJvbTogS2VudCBXYXRzZW4g PGt3YXRzZW5AanVuaXBlci5uZXQ+DQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+LA0KICAgICAgICAgICAgICAgICAibmV0Y29u ZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIG5l dGNvbmYgY2FsbCBob21lIHRlcm0gJ3RjcCBzZXNzaW9uJw0KTWVzc2FnZS1JRDogPEQwRDA0RDVG LjhFMjExJWt3YXRzZW5AanVuaXBlci5uZXQ+DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNo YXJzZXQ9InVzLWFzY2lpIg0KDQoNClRydWUsIFJGQyA3OTMgZG9lcyBub3QgdXNlIHRoZSB0ZXJt ICJ0Y3Agc2Vzc2lvbiIsIGJ1dCBvdGhlciBSRkNzIGRvOg0KDQogICAgaHR0cHM6Ly93d3cuZ29v Z2xlLmNvbS9zZWFyY2g/JnE9JTIydGNwK3Nlc3Npb24lMjIrc2l0ZTppZXRmLm9yZw0KDQpUaGUg cmVhc29uIGlzIGJlY2F1c2Ugb2YgY29tbWVudHMgcmVjZWl2ZWQgcmVnYXJkaW5nIHdoaWNoIFRD UA0KY29ubmVjdGlvbi9zZXNzaW9uIHdhcyBiZWluZyB1c2VkLiAgVGhlIGN1cnJlbnQgdGV4dCB1 c2VzIHRoZXNlIGRpZmZlcmVudA0KdGVybXMgaW4gdHJ5aW5nIHRvIGJlIG1vcmUgY2xlYXIgKHBl cmhhcHMgbm90KS4gIEFzIGN1cnJlbnRseSB3cml0dGVuLCB0aGUNCnRlcm0gImNvbm5lY3Rpb24i IG9ubHkgYXBwZWFycyBvbmNlLCBpbiBhIGRlc3BlcmF0ZSBhdHRlbXB0IHRvIHB1dCBhbiBlbmQN CnRvIGhvdyBtYW55IGNvbm5lY3Rpb25zIHRoZXJlIGFyZSAgOykNCg0KWW91IHN0aWxsIHRoaW5r IGl0IHNob3VsZCBiZSBjaGFuZ2VkPw0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQoNCk9uIDEvNS8x NSwgMTI6MTQgUE0sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiDQo8ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPkhpLA0KPg0KPmxvb2tpbmcgYXQgZHJhZnQt aWV0Zi1uZXRjb25mLWNhbGwtaG9tZS0wMi50eHQgc2VjdGlvbiAyLjEsIEkgc2VlIHRoaXM6DQo+ DQo+ICAgbyAgVGhlIFRDUCBjb25uZWN0aW9uIGlzIGFjY2VwdGVkIGFuZCBhIFRDUCBzZXNzaW9u IGlzIGVzdGFibGlzaGVkLg0KPg0KPlNpbWlsYXIgaW4gMy4xLCBJIHNlZSB0aGlzOg0KPg0KPiAg IG8gIFRoZSBORVRDT05GL1JFU1RDT05GIGNsaWVudCBhY2NlcHRzIGFuIGluY29taW5nIFRDUCBj b25uZWN0aW9uIGFuZA0KPiAgICAgIGEgVENQIHNlc3Npb24gaXMgZXN0YWJsaXNoZWQuDQo+DQo+ SSBhbSBub3Qgc3VyZSB3aGF0IHRoaXMgIlRDUCBzZXNzaW9uIiBpcyAtIEkgdGhpbmsgUkZDIDc5 MyBuZXZlciB0YWxrcw0KPmFib3V0IGEgc2Vzc2lvbi4gV2h5IGNhbiB3ZSBub3Qgc2ltcGx5IHRh bGsgYWJvdXQgdGhlIFRDUCBjb25uZWN0aW9uLA0KPnRoZXJlYnkgZWxpbWluYXRpbmcgdGhpcyBU Q1Agc2Vzc2lvbiB0ZXJtIC8gc3RlcD8NCj4NCj4vanMNCj4NCj4tLSANCj5KdWVyZ2VuIFNjaG9l bndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPlBob25l OiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBH ZXJtYW55DQo+RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNv YnMtdW5pdmVyc2l0eS5kZS8+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5OZXRjb25mIG1haWxpbmcgbGlzdA0KPk5ldGNvbmZAaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTdWJqZWN0OiBEaWdlc3QgRm9vdGVyDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25m IG1haWxpbmcgbGlzdA0KTmV0Y29uZkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCkVuZCBvZiBOZXRjb25mIERpZ2VzdCwgVm9sIDgzLCBJc3N1ZSA4DQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBh dHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRl bnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVz c2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xv c3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBv ciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk LiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRl IGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkg YXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlk ZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJl c3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Ns b3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24g b3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0 ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 00158A2148257DC5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRvIG15IHVuZGVyc3RhbmRpbmcsIHVzaW5n IHRoZXNlIHR3byB3b3Jkcw0KYXQgdGhlIHNhbWUgY29udGV4dCB3aWxsIGJlIGNvbmZ1c2luZy4g T3IgeW91IHByb3ZpZGUgYSBwcmVjaXNlIGRlZmluaXRpb24NCnRvIGNsYXJpZnkgdGhlbS48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoYW5rcy48YnI+ DQo8L2ZvbnQ+DQo8dGFibGU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPWNlbnRlcj48aW1nIHNy Yz1jaWQ6XzJfMERGNzFBRDgwREY3MTcwNDAwMTU4QTEzNDgyNTdEQzU+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xPjxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyPg0KPHRkIGNv bHNwYW49Mj48Zm9udCBzaXplPTE+PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+Q0hFTiBRaWFvZ2FuZyA8L2I+PC9mb250Pg0KPHRk Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+s8LHzrjWPC9iPjwvZm9udD4NCjx0cj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPk5ldHdvcmsgTWFuYWdlbWVudCBTeXN0ZW0gRGVw YXJ0bWVudCA8L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj7N+Lncxr3MqM+1 zbOyvzwvZm9udD4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPldpcmVsaW5l IEFjYWRhbXkgPC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+09DP39S6PC9m b250PjwvdGFibGU+DQo8YnI+DQo8dHI+DQo8dGQgcm93c3Bhbj0yPjxpbWcgc3JjPWNpZDpfMl8w REY3NUFDQzBERjc1NkY4MDAxNThBMTM0ODI1N0RDNT4NCjx0ZD48Zm9udCBzaXplPTIgY29sb3I9 IzhmOGY4ZiBmYWNlPSJBcmlhbCI+PGI+UHJvZHVjdCBSJmFtcDtEIFN5c3RlbSA8L2I+PC9mb250 Pg0KPHRyPg0KPHRkPjxmb250IHNpemU9MiBjb2xvcj0jOGY4ZjhmIGZhY2U9IkFyaWFsIj48Yj6y +sa30dC3oszlz7U8L2I+PC9mb250Pg0KPHRyPg0KPHRkIGNvbHNwYW49Mj48Zm9udCBzaXplPTEg ZmFjZT0iQXJpYWwiPlImYW1wO0QgQnVpbGRpbmcgMywgWlRFIEluZHVzdHJpYWwNClBhcmsgPGJy Pg0KTGl1eGlhbiBSb2FkLCBYaWxpLCBOYW5zaGFuIERpc3RyaWN0LCBTaGVuemhlbiwgUC5SLkNo aW5hPGJyPg0Kye7b2sTPyb3O98D2wfTPybTztcDW0NDLzajRtrmk0rXUsNHQt6IzusXCpc34udzP tc2zsr88YnI+DQpQb3N0OjUxODA1NTxicj4NClRlbDorODYtNzU1LTI2NzczNzExPGJyPg0KRmF4 Ois4Ni03NTUtMjY3NzM1ODM8YnI+DQpFbWFpbDpjaGVuLnFpYW9nYW5nQHp0ZS5jb20uY24gPC9m b250PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDAlPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5uZXRjb25mLXJlcXVlc3RAaWV0Zi5vcmc8L2I+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7JnF1 b3Q7TmV0Y29uZiZxdW90Ow0KJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDs8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNS0wMS0wNiAwNDowMTwvZm9u dD4NCjx0YWJsZSBib3JkZXI+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCBiZ2NvbG9yPXdoaXRlPg0K PGRpdiBhbGlnbj1jZW50ZXI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsfrtPC4tCC4 +Dxicj4NCm5ldGNvbmZAaWV0Zi5vcmc8L2ZvbnQ+PC9kaXY+PC90YWJsZT4NCjxicj4NCjx0ZCB3 aWR0aD01OSU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5uZXRjb25mQGlldGYu b3JnLCA8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPk5ldGNvbmYgRGlnZXN0LCBWb2wgODMsIElzc3VlIDg8L2ZvbnQ+PC90YWJsZT4NCjxi cj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlNlbmQgTmV0Y29uZiBtYWls aW5nIGxpc3Qgc3VibWlzc2lvbnMgdG88YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxicj4N ClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNp dDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQo8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxi cj4NCm9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdo ZWxwJyB0bzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQpuZXRjb25mLXJlcXVlc3RAaWV0Zi5vcmc8YnI+DQo8YnI+DQpZb3UgY2Fu IHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQ8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KbmV0Y29uZi1vd25l ckBpZXRmLm9yZzxicj4NCjxicj4NCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3Vi amVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWM8YnI+DQp0aGFuICZxdW90O1JlOiBDb250 ZW50cyBvZiBOZXRjb25mIGRpZ2VzdC4uLiZxdW90Ozxicj4NCjxicj4NCjxicj4NClRvZGF5J3Mg VG9waWNzOjxicj4NCjxicj4NCiAmbmJzcDsgMS4gbmV0Y29uZiBjYWxsIGhvbWUgdGVybSAndGNw IHNlc3Npb24nIChKdWVyZ2VuIFNjaG9lbndhZWxkZXIpPGJyPg0KICZuYnNwOyAyLiBSZTogbmV0 Y29uZiBjYWxsIGhvbWUgdGVybSAndGNwIHNlc3Npb24nIChLZW50IFdhdHNlbik8YnI+DQo8YnI+ DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KTWVzc2FnZTogMTxicj4NCkRhdGU6IE1v biwgNSBKYW4gMjAxNSAxODoxNDowOCArMDEwMDxicj4NCkZyb206IEp1ZXJnZW4gU2Nob2Vud2Fl bGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0Ozxicj4NClRv OiBuZXRjb25mQGlldGYub3JnPGJyPg0KU3ViamVjdDogW05ldGNvbmZdIG5ldGNvbmYgY2FsbCBo b21lIHRlcm0gJ3RjcCBzZXNzaW9uJzxicj4NCk1lc3NhZ2UtSUQ6ICZsdDsyMDE1MDEwNTE3MTQw OC5HQTgzOTRAZWxzdGFyLmxvY2FsJmd0Ozxicj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsg Y2hhcnNldD11cy1hc2NpaTxicj4NCjxicj4NCkhpLDxicj4NCjxicj4NCmxvb2tpbmcgYXQgZHJh ZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9tZS0wMi50eHQgc2VjdGlvbiAyLjEsIEkgc2VlIHRoaXM6 PGJyPg0KPGJyPg0KICZuYnNwOyBvICZuYnNwO1RoZSBUQ1AgY29ubmVjdGlvbiBpcyBhY2NlcHRl ZCBhbmQgYSBUQ1Agc2Vzc2lvbiBpcyBlc3RhYmxpc2hlZC48YnI+DQo8YnI+DQpTaW1pbGFyIGlu IDMuMSwgSSBzZWUgdGhpczo8YnI+DQo8YnI+DQogJm5ic3A7IG8gJm5ic3A7VGhlIE5FVENPTkYv UkVTVENPTkYgY2xpZW50IGFjY2VwdHMgYW4gaW5jb21pbmcgVENQIGNvbm5lY3Rpb24NCmFuZDxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2EgVENQIHNlc3Npb24gaXMgZXN0YWJsaXNoZWQuPGJy Pg0KPGJyPg0KSSBhbSBub3Qgc3VyZSB3aGF0IHRoaXMgJnF1b3Q7VENQIHNlc3Npb24mcXVvdDsg aXMgLSBJIHRoaW5rIFJGQyA3OTMgbmV2ZXINCnRhbGtzPGJyPg0KYWJvdXQgYSBzZXNzaW9uLiBX aHkgY2FuIHdlIG5vdCBzaW1wbHkgdGFsayBhYm91dCB0aGUgVENQIGNvbm5lY3Rpb24sPGJyPg0K dGhlcmVieSBlbGltaW5hdGluZyB0aGlzIFRDUCBzZXNzaW9uIHRlcm0gLyBzdGVwPzxicj4NCjxi cj4NCi9qczxicj4NCjxicj4NCi0tIDxicj4NCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEphY29icyBVbml2ZXJzaXR5DQpCcmVtZW4gZ0dt Ykg8YnI+DQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgQ2FtcHVzIFJpbmcgMSwgMjg3NTkNCkJyZW1lbiwgR2VybWFueTxicj4NCkZheDogJm5ic3A7 ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8L2ZvbnQ+ PC90dD48YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyI+PHR0Pjxmb250 IHNpemU9Mj5odHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvZm9udD48L3R0PjwvYT48 dHQ+PGZvbnQgc2l6ZT0yPiZndDs8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpNZXNzYWdlOiAyPGJyPg0KRGF0ZTogTW9uLCA1 IEphbiAyMDE1IDE5OjM5OjQ4ICswMDAwPGJyPg0KRnJvbTogS2VudCBXYXRzZW4gJmx0O2t3YXRz ZW5AanVuaXBlci5uZXQmZ3Q7PGJyPg0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0Oyw8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJnF1b3Q7bmV0Y29u ZkBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQpTdWJqZWN0OiBS ZTogW05ldGNvbmZdIG5ldGNvbmYgY2FsbCBob21lIHRlcm0gJ3RjcCBzZXNzaW9uJzxicj4NCk1l c3NhZ2UtSUQ6ICZsdDtEMEQwNEQ1Ri44RTIxMSVrd2F0c2VuQGp1bmlwZXIubmV0Jmd0Ozxicj4N CkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0mcXVvdDt1cy1hc2NpaSZxdW90Ozxi cj4NCjxicj4NCjxicj4NClRydWUsIFJGQyA3OTMgZG9lcyBub3QgdXNlIHRoZSB0ZXJtICZxdW90 O3RjcCBzZXNzaW9uJnF1b3Q7LCBidXQgb3RoZXINClJGQ3MgZG86PGJyPg0KPGJyPg0KICZuYnNw OyAmbmJzcDs8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwczovL3d3dy5nb29nbGUuY29tL3NlYXJj aD8mYW1wO3E9JTIydGNwK3Nlc3Npb24lMjIrc2l0ZTppZXRmLm9yZyI+PHR0Pjxmb250IHNpemU9 Mj5odHRwczovL3d3dy5nb29nbGUuY29tL3NlYXJjaD8mYW1wO3E9JTIydGNwK3Nlc3Npb24lMjIr c2l0ZTppZXRmLm9yZzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4N ClRoZSByZWFzb24gaXMgYmVjYXVzZSBvZiBjb21tZW50cyByZWNlaXZlZCByZWdhcmRpbmcgd2hp Y2ggVENQPGJyPg0KY29ubmVjdGlvbi9zZXNzaW9uIHdhcyBiZWluZyB1c2VkLiAmbmJzcDtUaGUg Y3VycmVudCB0ZXh0IHVzZXMgdGhlc2UgZGlmZmVyZW50PGJyPg0KdGVybXMgaW4gdHJ5aW5nIHRv IGJlIG1vcmUgY2xlYXIgKHBlcmhhcHMgbm90KS4gJm5ic3A7QXMgY3VycmVudGx5IHdyaXR0ZW4s DQp0aGU8YnI+DQp0ZXJtICZxdW90O2Nvbm5lY3Rpb24mcXVvdDsgb25seSBhcHBlYXJzIG9uY2Us IGluIGEgZGVzcGVyYXRlIGF0dGVtcHQgdG8NCnB1dCBhbiBlbmQ8YnI+DQp0byBob3cgbWFueSBj b25uZWN0aW9ucyB0aGVyZSBhcmUgJm5ic3A7Oyk8YnI+DQo8YnI+DQpZb3Ugc3RpbGwgdGhpbmsg aXQgc2hvdWxkIGJlIGNoYW5nZWQ/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCktlbnQ8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiAxLzUvMTUsIDEyOjE0IFBNLCAmcXVvdDtKdWVyZ2Vu IFNjaG9lbndhZWxkZXImcXVvdDs8YnI+DQombHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlJmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7SGksPGJyPg0KJmd0Ozxicj4NCiZn dDtsb29raW5nIGF0IGRyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMDIudHh0IHNlY3Rpb24g Mi4xLCBJIHNlZSB0aGlzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyBvICZuYnNwO1RoZSBU Q1AgY29ubmVjdGlvbiBpcyBhY2NlcHRlZCBhbmQgYSBUQ1Agc2Vzc2lvbiBpcw0KZXN0YWJsaXNo ZWQuPGJyPg0KJmd0Ozxicj4NCiZndDtTaW1pbGFyIGluIDMuMSwgSSBzZWUgdGhpczo8YnI+DQom Z3Q7PGJyPg0KJmd0OyAmbmJzcDsgbyAmbmJzcDtUaGUgTkVUQ09ORi9SRVNUQ09ORiBjbGllbnQg YWNjZXB0cyBhbiBpbmNvbWluZyBUQ1ANCmNvbm5lY3Rpb24gYW5kPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2EgVENQIHNlc3Npb24gaXMgZXN0YWJsaXNoZWQuPGJyPg0KJmd0Ozxicj4N CiZndDtJIGFtIG5vdCBzdXJlIHdoYXQgdGhpcyAmcXVvdDtUQ1Agc2Vzc2lvbiZxdW90OyBpcyAt IEkgdGhpbmsgUkZDIDc5Mw0KbmV2ZXIgdGFsa3M8YnI+DQomZ3Q7YWJvdXQgYSBzZXNzaW9uLiBX aHkgY2FuIHdlIG5vdCBzaW1wbHkgdGFsayBhYm91dCB0aGUgVENQIGNvbm5lY3Rpb24sPGJyPg0K Jmd0O3RoZXJlYnkgZWxpbWluYXRpbmcgdGhpcyBUQ1Agc2Vzc2lvbiB0ZXJtIC8gc3RlcD88YnI+ DQomZ3Q7PGJyPg0KJmd0Oy9qczxicj4NCiZndDs8YnI+DQomZ3Q7LS0gPGJyPg0KJmd0O0p1ZXJn ZW4gU2Nob2Vud2FlbGRlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEphY29i cyBVbml2ZXJzaXR5DQpCcmVtZW4gZ0dtYkg8YnI+DQomZ3Q7UGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbXB1cyBSaW5nIDEsDQoyODc1OSBCcmVt ZW4sIEdlcm1hbnk8YnI+DQomZ3Q7RmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAgMzEwMyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93d3cu amFjb2JzLXVuaXZlcnNpdHkuZGUvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuamFjb2Jz LXVuaXZlcnNpdHkuZGUvPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+Jmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7TmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7TmV0Y29uZkBpZXRm Lm9yZzxicj4NCiZndDs8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6 ZT0yPjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCjxicj4NClN1YmplY3Q6IERpZ2VzdCBGb290ZXI8YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGlu ZyBsaXN0PGJyPg0KTmV0Y29uZkBpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPjx0dD48Zm9udCBzaXpl PTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9mb250Pjwv dHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KRW5kIG9mIE5ldGNvbmYgRGlnZXN0LCBWb2wgODMs IElzc3VlIDg8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4N CjwvZm9udD48L3R0Pg0KPGJyPg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMg cHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1 c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVk IHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9y IG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBp biBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8 L2ZvbnQ+PC9wcmU+PGJyPg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJp dmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2 ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJl Y2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90 aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBl cnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2Zv bnQ+PC9wcmU+PGJyPg0K --=_alternative 00158A2148257DC5_=-- --=_related 00158A1948257DC5_= Content-Type: image/jpeg Content-ID: <_2_0DF71AD80DF7170400158A1348257DC5> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEB9AH0AAD/4Q4sRXhpZgAATU0AKgAAAAgACwEPAAIAAAASAAAAkgEQAAIA AAAMAAAApAESAAMAAAABAAEAAAEaAAUAAAABAAAAsAEbAAUAAAABAAAAuAEoAAMAAAABAAIAAAEx AAIAAAAbAAAAwAEyAAIAAAAUAAAA3AITAAMAAAABAAIAAIdpAAQAAAABAAAA8IglAAQAAAABAAAD gAAAA5ROSUtPTiBDT1JQT1JBVElPTgBOSUtPTiBEMzEwMAAAAAH0AAAAAQAAAfQAAAABQWRvYmUg UGhvdG9zaG9wIENTIFdpbmRvd3MAADIwMTE6MDQ6MjIgMjE6MTI6NDEAACeCmgAFAAAAAQAAAsqC nQAFAAAAAQAAAtKIIgADAAAAAQABAACIJwADAAAAAQDIAACQAAAHAAAABDAyMjGQAwACAAAAFAAA AtqQBAACAAAAFAAAAu6RAQAHAAAABAECAwCRAgAFAAAAAQAAAwKSBAAKAAAAAQAAAwqSBQAFAAAA AQAAAxKSBwADAAAAAQADAACSCAADAAAAAQAAAACSCQADAAAAAQAAAACSCgAFAAAAAQAAAxqShgAH AAAALAAAAyKSkAACAAAAAzEwAACSkQACAAAAAzEwAACSkgACAAAAAzEwAACgAAAHAAAABDAxMDCg AQADAAAAAQABAACgAgAEAAAAAQAAA+ygAwAEAAAAAQAAA+ygBQAEAAAAAQAAA06iFwADAAAAAQAC AACjAAAHAAAAAQMAAACjAQAHAAAAAQEAAACjAgAHAAAACAAAA26kAQADAAAAAQAAAACkAgADAAAA AQABAACkAwADAAAAAQAAAACkBAAFAAAAAQAAA3akBQADAAAAAQBIAACkBgADAAAAAQAAAACkBwAD AAAAAQAAAACkCAADAAAAAQAAAACkCQADAAAAAQAAAACkCgADAAAAAQAAAACkDAADAAAAAQAAAAAA AAAAAAAACgAAA+gAAABkAAAACjIwMTE6MDQ6MjIgMjE6MDg6MTkAMjAxMTowNDoyMiAyMTowODox OQAAAAAEAAAAAQAAAAAAAAAGAAAAMQAAAAoAAAHgAAAACkFTQ0lJAAAAICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgAAIAAQACAAAABFI5OAAAAgAHAAAABDAxMDAAAAAAAAAAAgAC AQIAAQAAAAEAAAABAAAAAQAAAAEAAAAEAgIAAAAAAAAAAAAGAQMAAwAAAAEABgAAARoABQAAAAEA AAPiARsABQAAAAEAAAPqASgAAwAAAAEAAgAAAgEABAAAAAEAAAPyAgIABAAAAAEAAAoxAAAAAAAA AEgAAAABAAAASAAAAAH/2P/bAEMACAYGBwYFCAcHBwkJCAoMFA0MCwsMGRITDxQdGh8eHRocHCAk LicgIiwjHBwoNyksMDE0NDQfJzk9ODI8LjM0Mv/bAEMBCQkJDAsMGA0NGDIhHCEyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMv/AABEIAHgAeAMBIQACEQED EQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0B AgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEB AQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFR B2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/APf6KACigAoo AOlQfbbXzxB9ph84jIj8wbj+HWgCeigAooAKKACigAooAKKAEd1jRndgqqMkk4AFeVeK/jNaWFw1 joMAvbjo0zHCKfYd6TY0rnmV9qfijxHI39o6peyxuc+UshWMf8BGB+lV7TwbNcTkZkUdd2e9ZSqW OiNK50ul+IvGXgwCKGd9Q0+P/lhcDdtH+yeo/lXpvhX4o6L4jIt5n+w3nA8uZsBj6A1cJpoyqU3F nc9aKszCigAooAKKACigDw74w+Nrlr8+HNNuNqLgT+UxyzH+En09qxvDngyKKzWa7YtO/Lf4VjVn ZHRQhzO519tpMEKjEYOBir8duka/KoH4VxuR6CikQXVskyYZQa4Txb4cjUf2lYqI54+W2jrV052Z nWgmj0z4WeNj4k0o2F4QL+0UAnPMidM8969CruR5j0CimIKKACigApsjbI2b0BPTNAHyvdW7XXje 5eVW3i4YkMuDnPcdq9TtV/dpxjAFclfc7sMtDSjIC4NOIGOO9c52EEn3eBWRqkBltJUA5Kmhbils cp8MjJYfEq0hR3TzVkV1XoRjOCO44/TNfRlejHY8ie4UVRIUUAFFABRQB88R2qN8TdYRowuyd3C5 zjnv71uX1/qkE6xWNksi93ZwK5aiTlqdtJtQ0Llrq+ppiO80tB6vHLn9MVsi5j+ziUIc4ztNZuMb 6G8ZStqYN7d65cuUsktIIh/FLkk/rVWzXVUnYXk8E0R/udVPt7U7RtYi873KWiWoHxe01Y1K7fnJ U4/hP+fx/Gve66qfwnFV+JhRVmYUUAFFABVTVLh7TS7meMZkSMlfrSbsioq8kjx2TT1i8UW19nMt zE5lbPLHg5PvWjcaabp0yX2KclVbAP5VxSk9GekopNpFXT9DlsZ5c3lzOGcMvmHiNR/CPX6n0FbG StpIO4OKUnd6DhGysZGpaGmpxGOWWdNzKwaNsEY7ehBz6VZt9IS1cugKrgDbnjihy92wKGtzNeFF 1+6nXiZYUKOOo69DXsemTSXGl2s0v+seJS31xW9F6nNiIrkT8y3RXQcYUUAFFABTJolmheJ/uupU /jQCdjzG8s2ttQaOZP3sJ2g+g9foeKs2rgnDdK4ZLoetF3d0S3EiRx4UZLcc9qoC6tjaPJ9oTAJ3 HNTYpvUsWcySpg4bgEMvQiluXVUwOtK2o76GZBp732rRJEvzy4j/AA7k+wGa9ZijWGJIkGFRQoHs K6qK3Zw4mWkUPorc5AooAKKACigDH13SYL22kuCpE8aEqynrjnBriIsgZFctZWdztw8m1Z9CtPqa K5jkKovfdVf7XYsmTJEfrwazSOlJyFttUhRtsTI2TggHmrkjeYoJ6HnBqWtQ12Ow8J6fBHYLelP3 75Xcf7ue1dHXbTVoo82q25sKKszCigAooAKKAEIDKQRkEYNed6naNpupSQN90Hch9VPSsa6vG50Y aVpWKVxbQ3ibXA9QcdKqHSnXAWSIr6mLJ/nXNGTR3p2JIdNt7U+YQHc/xEYqVS9zOkMS5kdgige9 LVsUnZXPTLG1WysobdeRGoGfU1YrvSsjym7u4UUxBRQAUUAFFABXBeKZvO1l+MCNAg98E/1JrKr8 JtQ+Iw97qDtOfaozJcg7gvHpurm0Oy7GmeVxhhtrQ0OVYNZtJGGR5gB/HinHRoUruLPT6K7Tzgoo AKKACigApks0cKbpHCr6k0AZd1raKfLt0Z2P8ZGAP61h3Vn9shJP+tBJBPf2qJrmVjSm+WSZzskB jmKsCPbpT/syEcyMPauQ9CyIhbAt3x71o6dY/ObhhgAYjH9aqCvJEVHywZ1mn6yNvk3SsCgH7wcg j3rYjlSVA0bhlPcGutO557Vh1FMQUUAFQT3kFvnzJBu/ujk0AZsuqzSsREBGvbPJIqjPK78ysWbt k5qb3KSsRZLTRqQMZxVxotuCOlCGylfaal4oYYWUdG9fY1ivA0LtHICrDqDXPUjZ3OuhPmXKyxZ6 cZsSycQnoO7/AP1q1VizwBgDoKunGyuZ1p3dkIwEcpXHO0UtvI8TvsdkIPGDWmtzHSxqW+rFSFuF 4/vAfzFaiOsihkYMp6EVSdyGrDqKYjGvNUZy0VscL0L9z9Kyg5EjAgknuT3qWUkPTLckk0hG6UAd BzSKEcEFmHVTn8q1AQyg9iM00JlS/v7bToPNuGxlgqKOrMegFUpIbq4IeWON2yPlI4UDtQ1cE2ti 5DNHPkD5WXgr6VMfl6DihAym5LXEmOxA/QUkuY3SQdM7WpDJHkXacjn1p9tO9u26J+O6+v4UCsbV nfx3Xy/dkAyVP9KKsgwgpGMcg9KiAyGbvuIFQ9zRbE6ptUD0/wDrU2Fern+I5/ChAwAxET3IJp5v DHFHHGheXaM56L9TQLcpvZCdzLOd8hIwSOF5HQVspGqKAAPypoGZ91bq1wzglWB+8v0FJHcvEAty Mr2cD+dADQQbqfByMjn8KldA8bIejL/Q0hkERLoCwwV4PuR/+qkZSq55HakMmVjG4wSGHQg9DRTR LVxbdw8YjPXoPrTIV+Xn++SfzoAkkPy4HVuBTiNsRx9B+ZoQ2CjoPYfyFGMkf57CmIMblx2//VV4 HoP89qEJlOb/AFr0xlG3mgYbABx1pR936D+lIBhUCZ1/vfMKjmOwR+pbP9aBj1GHbP8ACKKGJH// 2QD/7RU0UGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAAAAAAAAAAAAAAOEJJTQPtAAAA AAAQAfQAAAABAAIB9AAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAAOEJJTQQNAAAAAAAE AAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJTQQKAAAAAAABAAA4 QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgAB AKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4AAAA AABwAAD/////////////////////////////A+gAAAAA/////////////////////////////wPo AAAAAP////////////////////////////8D6AAAAAD/////////////////////////////A+gA ADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4AAAAAAAQAAAAAOEJJTQQaAAAAAANF AAAABgAAAAAAAAAAAAAD7AAAA+wAAAAIAEQAUwBDAF8AMQAwADMAMgAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAQAAAAAAAAAAAAAD7AAAA+wAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA AAAQAAAAAQAAAAAAAG51bGwAAAACAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAA VG9wIGxvbmcAAAAAAAAAAExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAA+wAAAAAUmdodGxvbmcA AAPsAAAABnNsaWNlc1ZsTHMAAAABT2JqYwAAAAEAAAAAAAVzbGljZQAAABIAAAAHc2xpY2VJRGxv bmcAAAAAAAAAB2dyb3VwSURsb25nAAAAAAAAAAZvcmlnaW5lbnVtAAAADEVTbGljZU9yaWdpbgAA AA1hdXRvR2VuZXJhdGVkAAAAAFR5cGVlbnVtAAAACkVTbGljZVR5cGUAAAAASW1nIAAAAAZib3Vu ZHNPYmpjAAAAAQAAAAAAAFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAA AAAAQnRvbWxvbmcAAAPsAAAAAFJnaHRsb25nAAAD7AAAAAN1cmxURVhUAAAAAQAAAAAAAG51bGxU RVhUAAAAAQAAAAAAAE1zZ2VURVhUAAAAAQAAAAAABmFsdFRhZ1RFWFQAAAABAAAAAAAOY2VsbFRl eHRJc0hUTUxib29sAQAAAAhjZWxsVGV4dFRFWFQAAAABAAAAAAAJaG9yekFsaWduZW51bQAAAA9F U2xpY2VIb3J6QWxpZ24AAAAHZGVmYXVsdAAAAAl2ZXJ0QWxpZ25lbnVtAAAAD0VTbGljZVZlcnRB bGlnbgAAAAdkZWZhdWx0AAAAC2JnQ29sb3JUeXBlZW51bQAAABFFU2xpY2VCR0NvbG9yVHlwZQAA AABOb25lAAAACXRvcE91dHNldGxvbmcAAAAAAAAACmxlZnRPdXRzZXRsb25nAAAAAAAAAAxib3R0 b21PdXRzZXRsb25nAAAAAAAAAAtyaWdodE91dHNldGxvbmcAAAAAADhCSU0EKAAAAAAADAAAAAE/ 8AAAAAAAADhCSU0EFAAAAAAABAAAAAI4QklNBAwAAAAAD4EAAAABAAAAoAAAAKAAAAHgAAEsAAAA D2UAGAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAf/uAA5BZG9iZQBkgAAAAAH/ 2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAKAAoAMBIgACEQEDEQH/3QAEAAr/xAE/AAABBQEBAQEB AQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIE AgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRai soMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dn d4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi 4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl 9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APVUkkklKSSSSUpJJJJSkklXzM/C wa/VzL68ev8AescGj/pJKbCS896h/japBczpXT336ey293piZH+BZ6j9v9utYeV/jI+uVp/RNox2 kahlRdz4Ote9Cwmi+vJLyLE/xlfW/FAORVTmMETvrLHx/XoLW+7/AIpdn0P/ABjfV3qoFd1h6fkw N1WRDWz/ACMn+Zd/b9Kz/g0rUQQ9UkmBDhLTI8QnRQpJJJJSkkkklKSSSSU//9D1VJJJJSkkkklK SSWH9cett6N0S28W+jkWkV45ABduP0y2f3a93vSU531v+veJ0Rj8XCcy/qLSA9jgXMr4dFu1zPe9 p/NXmF93U+vZbs3Ptfc6YDnmdsmfTpHtZWz+ohYWLb1jqO15JbJda88xP/fl3uJ0rDoqYxtbQWCA YUc51ozY8fFq8zj9Cc7bHtngfBaTPq+XN2wfifBdFXjta0BoiNAitr5lQnIWwMQDk19Fqbj+nA4O vJ+MlY3U/qvS6XtJZaOHNHP9YLsS3wQbWA9kBMgpOMEPHdM+sv1i+q2XXTe59+K0bRjuP6Mt1+i7 3em9rnf6s9i9Q+rn1ixevYf2ilpptZAtocZc2eHfyq3/AJj1xvVunU5uK6p41Alp81y3Q+s5v1Z6 wHVOd6O+MimYbY39107v+tvU8J21cmPh1D7ikg4mVRmY1eVjuD6bmh7HDwKMpGJSSSSSlJJJJKf/ 0fVUkkklKSSSSUpeaf413udlYtR2ENr9jZcXe4nc5zSfRY13p/mfpf0f6T/Br0tec/41cWup2HlM axj7nuFjxJseWhoG7Tb6VNf8v6diSQ8/9UsdtVhcfpO7rr2DWVh/V3E9PFFzu/0VsPy8WghttjWO P5vf5/uqrPWTcx0I6t1kQPE+KnAP+xDx3U3Nmt4cPIgogY7WOybR6hkBB2LF0cwh2EQYRnMgbnEA eZWbl9b6PjOLLMqv1B+Y07iP622UhEnYKMojcsrWyD5riOu4x+22cDwJ4XV19c6fkXClr9r3fQJ+ i7yDgs36yYTH4zskaFoh0eB0T4XGWrFkqUdHsP8AFxk23/VmoWWeoKnurYDo5gGvpP8A87ex3+js XUrjf8Vrnf8AN+xjmRtudtsA0c0/ml/5z6nte3Z/g/0a7JWQ0ypJJJJSkkkklP8A/9L1VJJJJSkk kklKXA/41K2PxsRzJfbW524TIYyNXbZ9vq/1f8D/AJ/fLis2s5GZ1B13LnvaQeNrJqqr/wA1iZOX CB4smLHxk61Qczop3dHxXD86sa+ap5fSujC/1ct7y6w/R3kkk+AV7oNWzpOPX+6NvjwSrgwQbhc1 g9QGQ7v8lCZUWyIggX0cWvB+rDng4r9jh4OIMglrv6217fetzBY6kljXlzDwPNVq+i4mPl35ONj+ nflgi5+hBDjus2tfuZV6jvp+mxXG1Cp1bWjRsN+5KR7EnzVGNdAPJjm1m32vJEhY91n1dwQRkMa9 8lxG3cTEB7mta130N3uW3dJvGkgCSDwVUyOlYmTVXjZWO3IoqdvqbYA4NcfpObp+f+f++hE9yfom Ue1fVpV/sq2wMZjilzgHta5m3R3vre3QfSTfWBh/YmURrDB8fpNC1nYYc/e7U8zyqfXGN/ZWUDpF fPwIKQl6kGPpdL/FyacXphwbCWZj3uuLHaS0RX7P6m1diuG6Y4/tXp9lZguePjD2OFrV3KnxyJBv oWvmxiBFdRakkkk9iUkkkkp//9P1VJJJJSkkkklKXMddofRnPewe3IAe2P3m+y1o/lfQeunVTqeA zOxXVGA8e6px7OH/AH1ybONhkxT4ZWdjoXkaK6aWFlOlbXaDw8VdpIcIKDkY2RjO25FZrc6SJjWN HEFqVbiFXI7tuJGtNkitgLidBqVWaXWWNgEAn2TyZU3vYRtcZ8B5qk+kvuY8X2gsBDWsdFceN1P0 bXoAJJbNwex4IEkdkao12MkaeIPYrOfTd6ldzr7AWztbWdtZ/wCObDnW/wBRW8dzQ0+6Xky48a/B IhQkneAGmVnZjW202VvG5rxtI8ZIVq18iO6HTRdkXNopG61/0QdOPd3/AJLUo+CpFs/VjEdb1Btj xIw2Ek8gPf8Ao2M/ss3rrlT6V09uBiCrR1rjuteO7j/31v0VcVmEaj+LTzT4530GgUkkknMakkkk lP8A/9T1VJJJJSkkkklKSSSSU431lpmmm8f4N5afg8f+SYsVsSAuty8ZmVjWY79BYInwPLXf2XLk HB9VjmP+nW4tcBxIO1yhyx1ts4JaV2auWzJr3WNaLmtJO0HaY7fvKvXmZ1jiWUMcG/mhwkfetXeH fxQX4FDzuBcx3i0j+IKjB7s4oNG3KzQwuGMxrRzL4E99Pco492Ve/Wksj6VgcI+TVdb0+uZufY8z wSI/BrUctbSIrG0JEjoFGixLXNa0OMujVXvq/V6nU9/aljnH4n9GP+/rNdYZMnhdL9XsI4+H67/5 3Jh5Hgz/AATf+/8A9tOxC5eTFmlUSO+jqpJJKw1FJJJJKUkkkkp//9X1VJJJJSkkkklKSSSSUsSA CToBqSuMy7Bbk3Wt0a+xzh8CV1XUMhtVDmcvsG0N8jy5c3m4prs3t/m7fwf3b/b/AJxijy7Blw7k d9mmHPaZGqg7IPGpM9lIhwMd0/vGu0lRNjVGMwjQyPONUxvc8Q1TcLHD6BUNjuAIKCtVQS09zBhd 1ivrsxqn1mWOY0tPlC4gUvc5tTNX2GB8+/8AZXV9JyGCsYhMGsfoyfzm/wDkmqXF1Yc40DopJJKV gUkkkkpSSSSSn//W9VSSUXvZW0ueQ1o7lJTJJUrupMHtobvd+8dG/wDklUL7biTa8uI/NGgj4fQQ tNOhdmU1j2n1H9mtP5T+aqNmblWy1rhWD2bqf84/99QyAyZIiNFAOdt3TDZmPKEiUgBhUwkFzjLn GXOmTpp9Iozq2vY6t4BadCD5fRP9hPiDR0n3MdBPxAc0/wDSRSyDpp4eUcj+z/57S/arr5OHm4j6 HBx1aTDXHv8AyH/8K3/wRDrMDQ6+BW8+tr2Fj27mOEOYdZA7f16/zFm5OCcYeo330/vHls/R3/yP 3bP+3FDKFbNjHkEtDu1XlxHMSoBrWN3HQfedUVwaBqDqYaBqXE/mtH5yvY2D6LhbdBvH0WjVtf8A 5O3+X/1utNAJ2XzkI7/YjxcQ0zZaIucILf3Af8H/AMZ/pf8AttTtrLmGNHDVpHII9wc1WAwk8eQ+ KexkVPI8Ib/a9oUwjQprSkZGykZn5NLQXRYzSd2hH9tX6s3Htgbtrv3XaLKLt7ToCHNiPgEqoNcH kaEFG1pDuJLJqyb6YDTuZ+47Uf2XK/j5dV+jfa8csPP/AJkjaKTpJJIof//X9Mys1lB2NG+z90cD +ssu+2159S1xLuQOw/qj81PGp7uOpPmf/JJrI9oHBn7o/wC+oErgF9/G35lJs6FxMkCD8QohsAN7 nT5CCijt4e1AJR2cBo5cR+ISc32hvaQPuanb7rZ7MDf7k7hLmt+Z+5yXZXfyZY525Dm9rGyPMtHH 9qtytR4HXSD5/mO/tNVUaXU9jvgH4tVkkQS72tA93kO//bb0R2QehWhs+E/eOw/zHe1Ur8t7nvx8 YS1pLci4ahh/Px6fperf+/8AmUf8YoZWRfl7qcVxqqeC2zIGh1aR+ru/9GJ+j4bMbBqx69G0ksGm pO90ucf5SXZXdbFdRXkveaW18NZa3UCR7mj83c3/AIL+2rgaDr4x8vD/ADGohorsAY8e0wNNNCTP 9X+ys+l19DWCPUrLRxyJSqvoqyW7AGgEdvmf/MEPIcPTEfnPYPvOn/RYpVXVXtJrdLgSHN7hx02/ 2UPL0qa7sLGH8Yb/ANFqHRXXyYsB48f7io7iy/xbaJA8C0e5FbyP9eyhewupJGjq/cPkG7ku/mnt 5JJa4wdDyR/uUNu4l3Zp0I5HzCjIcwPGu8CP7XuSggjx5J/6RSVTdx85zAG3+5vZ/cf1v3lfa5rm hzSHNPBGoWHvLiJbJ79pMcBWMe52O4lvuqJ97fDtub/KRBWkP//Q7xoD2B4Gse4f9Whv/nax47if iB/376SemzYD4tOo8f8AzlSsaBkNjVpaS3/X5pp2XjQrtE3E+B0/InBAbJ4AE/ekwQZ+H5VGzUNr H5w1+AKXVXRVTfZJ5dqfvT82H+T7f+qU40J7DdHyKgzufEj8pSUpzS5zCDG0g/OEOyuy+yb3bmTu bU3RvB91n+kcjt/N+X8QmaNR8v4o90dlmt0Hy/IjYx/RaeI/6ooTNY+X5EbHgM04kffJS7K7pG8t +I/K5Um6MaR2A/IVcaeD5jX/ADlUb/Nj4f8AfUj1UOiM0CQ5h9N4iHD4JWm+7HaxzRva8OMd4GiM Rp/r4JNH5T+RDsnuxGhHw/76pcT4R/AJo1H+v5qc/RJ8v4Jd1dkFVfpmxh19Nzg34GPT/wCipxJJ 8R+U7VJ/tva7tadjvi33s/78nDdf838m9JSNsCxxH5g0/rOTt1dDeDz/AFQP9XKFJL3vjUbiT5kB Er/my46iSPiR9JJT/9kAOEJJTQQhAAAAAABTAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQA bwBzAGgAbwBwAAAAEgBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAAAAEAOEJJ TQQGAAAAAAAHAAgAAAABAQD/4SB8aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNr ZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pg0KPHg6eG1wbWV0 YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iWE1QIHRvb2xraXQgMy4wLTI4LCBm cmFtZXdvcmsgMS42Ij4NCgk8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiIHhtbG5zOmlYPSJodHRwOi8vbnMuYWRvYmUuY29tL2lY LzEuMC8iPg0KCQk8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0idXVpZDoxZDhhNTlkOS02Y2M4 LTExZTAtOTA1ZS1lZWU2M2UzOTIxNmQiIHhtbG5zOmV4aWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20v ZXhpZi8xLjAvIj4NCgkJCTxleGlmOkdQU1ZlcnNpb25JRD4yLjIuMC4wPC9leGlmOkdQU1ZlcnNp b25JRD4NCgkJCTxleGlmOkV4cG9zdXJlVGltZT4xMC8xMDAwPC9leGlmOkV4cG9zdXJlVGltZT4N CgkJCTxleGlmOkZOdW1iZXI+MTAwLzEwPC9leGlmOkZOdW1iZXI+DQoJCQk8ZXhpZjpFeHBvc3Vy ZVByb2dyYW0+MTwvZXhpZjpFeHBvc3VyZVByb2dyYW0+DQoJCQk8ZXhpZjpJU09TcGVlZFJhdGlu Z3M+DQoJCQkJPHJkZjpTZXE+DQoJCQkJCTxyZGY6bGk+MjAwPC9yZGY6bGk+DQoJCQkJPC9yZGY6 U2VxPg0KCQkJPC9leGlmOklTT1NwZWVkUmF0aW5ncz4NCgkJCTxleGlmOkV4aWZWZXJzaW9uPjAy MjE8L2V4aWY6RXhpZlZlcnNpb24+DQoJCQk8ZXhpZjpEYXRlVGltZU9yaWdpbmFsPjIwMTEtMDQt MjJUMjE6MDg6MTkrMDg6MDA8L2V4aWY6RGF0ZVRpbWVPcmlnaW5hbD4NCgkJCTxleGlmOkRhdGVU aW1lRGlnaXRpemVkPjIwMTEtMDQtMjJUMjE6MDg6MTkrMDg6MDA8L2V4aWY6RGF0ZVRpbWVEaWdp dGl6ZWQ+DQoJCQk8ZXhpZjpDb21wb25lbnRzQ29uZmlndXJhdGlvbj4NCgkJCQk8cmRmOlNlcT4N CgkJCQkJPHJkZjpsaT4xPC9yZGY6bGk+DQoJCQkJCTxyZGY6bGk+MjwvcmRmOmxpPg0KCQkJCQk8 cmRmOmxpPjM8L3JkZjpsaT4NCgkJCQkJPHJkZjpsaT4wPC9yZGY6bGk+DQoJCQkJPC9yZGY6U2Vx Pg0KCQkJPC9leGlmOkNvbXBvbmVudHNDb25maWd1cmF0aW9uPg0KCQkJPGV4aWY6Q29tcHJlc3Nl ZEJpdHNQZXJQaXhlbD40LzE8L2V4aWY6Q29tcHJlc3NlZEJpdHNQZXJQaXhlbD4NCgkJCTxleGlm OkV4cG9zdXJlQmlhc1ZhbHVlPjAvNjwvZXhpZjpFeHBvc3VyZUJpYXNWYWx1ZT4NCgkJCTxleGlm Ok1heEFwZXJ0dXJlVmFsdWU+NDkvMTA8L2V4aWY6TWF4QXBlcnR1cmVWYWx1ZT4NCgkJCTxleGlm Ok1ldGVyaW5nTW9kZT4zPC9leGlmOk1ldGVyaW5nTW9kZT4NCgkJCTxleGlmOkxpZ2h0U291cmNl PjA8L2V4aWY6TGlnaHRTb3VyY2U+DQoJCQk8ZXhpZjpGbGFzaCByZGY6cGFyc2VUeXBlPSJSZXNv dXJjZSI+DQoJCQkJPGV4aWY6RmlyZWQ+RmFsc2U8L2V4aWY6RmlyZWQ+DQoJCQkJPGV4aWY6UmV0 dXJuPjA8L2V4aWY6UmV0dXJuPg0KCQkJCTxleGlmOk1vZGU+MDwvZXhpZjpNb2RlPg0KCQkJCTxl eGlmOkZ1bmN0aW9uPkZhbHNlPC9leGlmOkZ1bmN0aW9uPg0KCQkJCTxleGlmOlJlZEV5ZU1vZGU+ RmFsc2U8L2V4aWY6UmVkRXllTW9kZT4NCgkJCTwvZXhpZjpGbGFzaD4NCgkJCTxleGlmOkZvY2Fs TGVuZ3RoPjQ4MC8xMDwvZXhpZjpGb2NhbExlbmd0aD4NCgkJCTxleGlmOlVzZXJDb21tZW50Pg0K CQkJCTxyZGY6QWx0Pg0KCQkJCQk8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPg0KCQkJCQk8 L3JkZjpsaT4NCgkJCQk8L3JkZjpBbHQ+DQoJCQk8L2V4aWY6VXNlckNvbW1lbnQ+DQoJCQk8ZXhp ZjpGbGFzaHBpeFZlcnNpb24+MDEwMDwvZXhpZjpGbGFzaHBpeFZlcnNpb24+DQoJCQk8ZXhpZjpD b2xvclNwYWNlPjE8L2V4aWY6Q29sb3JTcGFjZT4NCgkJCTxleGlmOlBpeGVsWERpbWVuc2lvbj4x MDA0PC9leGlmOlBpeGVsWERpbWVuc2lvbj4NCgkJCTxleGlmOlBpeGVsWURpbWVuc2lvbj4xMDA0 PC9leGlmOlBpeGVsWURpbWVuc2lvbj4NCgkJCTxleGlmOlNlbnNpbmdNZXRob2Q+MjwvZXhpZjpT ZW5zaW5nTWV0aG9kPg0KCQkJPGV4aWY6RmlsZVNvdXJjZT4zPC9leGlmOkZpbGVTb3VyY2U+DQoJ CQk8ZXhpZjpTY2VuZVR5cGU+MTwvZXhpZjpTY2VuZVR5cGU+DQoJCQk8ZXhpZjpDdXN0b21SZW5k ZXJlZD4wPC9leGlmOkN1c3RvbVJlbmRlcmVkPg0KCQkJPGV4aWY6RXhwb3N1cmVNb2RlPjE8L2V4 aWY6RXhwb3N1cmVNb2RlPg0KCQkJPGV4aWY6V2hpdGVCYWxhbmNlPjA8L2V4aWY6V2hpdGVCYWxh bmNlPg0KCQkJPGV4aWY6RGlnaXRhbFpvb21SYXRpbz4xLzE8L2V4aWY6RGlnaXRhbFpvb21SYXRp bz4NCgkJCTxleGlmOkZvY2FsTGVuZ3RoSW4zNW1tRmlsbT43MjwvZXhpZjpGb2NhbExlbmd0aElu MzVtbUZpbG0+DQoJCQk8ZXhpZjpTY2VuZUNhcHR1cmVUeXBlPjA8L2V4aWY6U2NlbmVDYXB0dXJl VHlwZT4NCgkJCTxleGlmOkdhaW5Db250cm9sPjA8L2V4aWY6R2FpbkNvbnRyb2w+DQoJCQk8ZXhp ZjpDb250cmFzdD4wPC9leGlmOkNvbnRyYXN0Pg0KCQkJPGV4aWY6U2F0dXJhdGlvbj4wPC9leGlm OlNhdHVyYXRpb24+DQoJCQk8ZXhpZjpTaGFycG5lc3M+MDwvZXhpZjpTaGFycG5lc3M+DQoJCQk8 ZXhpZjpTdWJqZWN0RGlzdGFuY2VSYW5nZT4wPC9leGlmOlN1YmplY3REaXN0YW5jZVJhbmdlPg0K CQk8L3JkZjpEZXNjcmlwdGlvbj4NCgkJPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9InV1aWQ6 MWQ4YTU5ZDktNmNjOC0xMWUwLTkwNWUtZWVlNjNlMzkyMTZkIiB4bWxuczpwZGY9Imh0dHA6Ly9u cy5hZG9iZS5jb20vcGRmLzEuMy8iPg0KCQk8L3JkZjpEZXNjcmlwdGlvbj4NCgkJPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9InV1aWQ6MWQ4YTU5ZDktNmNjOC0xMWUwLTkwNWUtZWVlNjNlMzky MTZkIiB4bWxuczpwaG90b3Nob3A9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGhvdG9zaG9wLzEuMC8i Pg0KCQkJPHBob3Rvc2hvcDpIaXN0b3J5PjwvcGhvdG9zaG9wOkhpc3Rvcnk+DQoJCTwvcmRmOkRl c2NyaXB0aW9uPg0KCQk8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0idXVpZDoxZDhhNTlkOS02 Y2M4LTExZTAtOTA1ZS1lZWU2M2UzOTIxNmQiIHhtbG5zOnRpZmY9Imh0dHA6Ly9ucy5hZG9iZS5j b20vdGlmZi8xLjAvIj4NCgkJCTx0aWZmOk1ha2U+TklLT04gQ09SUE9SQVRJT048L3RpZmY6TWFr ZT4NCgkJCTx0aWZmOk1vZGVsPk5JS09OIEQzMTAwPC90aWZmOk1vZGVsPg0KCQkJPHRpZmY6T3Jp ZW50YXRpb24+MTwvdGlmZjpPcmllbnRhdGlvbj4NCgkJCTx0aWZmOlhSZXNvbHV0aW9uPjUwMC8x PC90aWZmOlhSZXNvbHV0aW9uPg0KCQkJPHRpZmY6WVJlc29sdXRpb24+NTAwLzE8L3RpZmY6WVJl c29sdXRpb24+DQoJCQk8dGlmZjpSZXNvbHV0aW9uVW5pdD4yPC90aWZmOlJlc29sdXRpb25Vbml0 Pg0KCQkJPHRpZmY6WUNiQ3JQb3NpdGlvbmluZz4yPC90aWZmOllDYkNyUG9zaXRpb25pbmc+DQoJ CTwvcmRmOkRlc2NyaXB0aW9uPg0KCQk8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0idXVpZDox ZDhhNTlkOS02Y2M4LTExZTAtOTA1ZS1lZWU2M2UzOTIxNmQiIHhtbG5zOnhhcD0iaHR0cDovL25z LmFkb2JlLmNvbS94YXAvMS4wLyI+DQoJCQk8eGFwOkNyZWF0ZURhdGU+MjAxMS0wNC0yMlQyMTow ODoxOSswODowMDwveGFwOkNyZWF0ZURhdGU+DQoJCQk8eGFwOk1vZGlmeURhdGU+MjAxMS0wNC0y MlQyMToxMjo0MSswODowMDwveGFwOk1vZGlmeURhdGU+DQoJCQk8eGFwOk1ldGFkYXRhRGF0ZT4y MDExLTA0LTIyVDIxOjEyOjQxKzA4OjAwPC94YXA6TWV0YWRhdGFEYXRlPg0KCQkJPHhhcDpDcmVh dG9yVG9vbD5BZG9iZSBQaG90b3Nob3AgQ1MgV2luZG93czwveGFwOkNyZWF0b3JUb29sPg0KCQk8 L3JkZjpEZXNjcmlwdGlvbj4NCgkJPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9InV1aWQ6MWQ4 YTU5ZDktNmNjOC0xMWUwLTkwNWUtZWVlNjNlMzkyMTZkIiB4bWxuczp4YXBNTT0iaHR0cDovL25z LmFkb2JlLmNvbS94YXAvMS4wL21tLyI+DQoJCQk8eGFwTU06RG9jdW1lbnRJRD5hZG9iZTpkb2Np ZDpwaG90b3Nob3A6MWQ4YTU5ZDYtNmNjOC0xMWUwLTkwNWUtZWVlNjNlMzkyMTZkPC94YXBNTTpE b2N1bWVudElEPg0KCQk8L3JkZjpEZXNjcmlwdGlvbj4NCgkJPHJkZjpEZXNjcmlwdGlvbiByZGY6 YWJvdXQ9InV1aWQ6MWQ4YTU5ZDktNmNjOC0xMWUwLTkwNWUtZWVlNjNlMzkyMTZkIiB4bWxuczpk Yz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPg0KCQkJPGRjOmZvcm1hdD5pbWFn ZS9qcGVnPC9kYzpmb3JtYXQ+DQoJCTwvcmRmOkRlc2NyaXB0aW9uPg0KCTwvcmRmOlJERj4NCjwv eDp4bXBtZXRhPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPD94cGFj a2V0IGVuZD0ndyc/Pv/iDFhJQ0NfUFJPRklMRQABAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfO AAIACQAGADEAAGFjc3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAg IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQ AAAAM2Rlc2MAAAGEAAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoA AAIsAAAAFGJYWVoAAAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZp ZXcAAAPUAAAAJGx1bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAI DGdUUkMAAAQ8AAAIDGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xl dHQtUGFja2FyZCBDb21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAA AAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFla IAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbP ZGVzYwAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93 d3cuaWVjLmNoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRl c2MAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAA AAAAAAAAAAAALklFQyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAA AAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRp b24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9u IGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRf LgAQzxQAA+3MAAQTCwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkA HgAjACgALQAyADcAOwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACp AK4AsgC3ALwAwQDGAMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUB TAFSAVkBYAFnAW4BdQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQIm Ai8COAJBAksCVAJdAmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MD TwNaA2YDcgN+A4oDlgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2 BMQE0wThBPAE/gUNBRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoG ewaMBp0GrwbABtEG4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiC CJYIqgi+CNII5wj7CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK 8wsLCyILOQtRC2kLgAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2p DcMN3g34DhMOLg5JDmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ 1xD1ERMRMRFPEW0RjBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJ FGoUixStFM4U8BUSFTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsY QBhlGIoYrxjVGPoZIBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7 HKMczBz1HR4dRx1wHZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwh SCF1IaEhziH7IiciVSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZX JocmtyboJxgnSSd6J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9Es BSw5LG4soizXLQwtQS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHy MioyYzKbMtQzDTNGM38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4 jDjIOQU5Qjl/Obw5+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9h P6I/4kAjQGRApkDnQSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG 8Ec1R3tHwEgFSEtIkUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63 TwBPSU+TT91QJ1BxULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdX RFeSV+BYL1h9WMtZGllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AF YFdgqmD8YU9homH1YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNp mmnxakhqn2r3a09rp2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNd c7h0FHRwdMx1KHWFdeF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+ AX5ifsJ/I3+Ef+WAR4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjO iTOJmYn+imSKyoswi5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCU ipT0lV+VyZY0lp+XCpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBp oNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCt RK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7 urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/I Pci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV 1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5Pzl hOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC 9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23////bAEMAAgEBAgEBAgICAgIC AgIDBQMDAwMDBgQEAwUHBgcHBwYHBwgJCwkICAoIBwcKDQoKCwwMDAwHCQ4PDQwOCwwMDP/bAEMB AgICAwMDBgMDBgwIBwgMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDP/AABEIAIYAhgMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJ Cgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQz YnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm 5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIE BAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZ GiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SV lpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4 +fr/2gAMAwEAAhEDEQA/AP38ooooAKKKKACiis7xb4w0nwF4eu9X1zUrHSNLsInnubu8nWGGBEUs zMzEAAKCST2BoA0aK/Jn9uf/AIOgPCXhVtT8L/ADSJvGXiS3kMP9v6nZsujqBt3PDGJEllIBOGcI uVHDq2a/PL4jf8FMv2tf2nrp21X40eJtEjCGNLTQNukRAMCefsojZ+G4JLEYUg5ArGpXhDdnRSwt Sp8KP6c6K/lc+E+m/tF3fjC91jw98XviTaa1Eu2bUE1++WWdcEANIZMyLgkBWJ4Jr69/Zp/4OEP2 gP2Lha+Hvjf4ctfir4as98P9tpL9k1eLbwFeVVMcu04BMiBz3kYms4YylJ8qeptUy6vCPO46H7zU V4D+xn/wU3+Df7d9jGPAPiu2n1loDdSaLebYNShjDMu4x5Ib7uTsZsBlJwGGffq6U7nE1YKKKKYg ooooAKKKKACiiigAooooAwvif8R9K+EHw81nxRrcssOk6FaPeXTRRmSTYozhVHLMegHqa/m2/wCC nv8AwVU+Jn/BVH43R+A/DsUmneCLa/LaTo1vlGO35ftFwx5aYDfzwqAkKMli36e/8HOPx98Q/DL9 i/TPC2hXN/p9v4yv2j1O5ht22SQRKGW3MuQql3IbbyzCIjGOv5ef8Ee/hBBBr2reIL6INezjbGzq N6KDkjPrnr9B6VwY/FexpOaPTyvBrEVlB7HbfAH/AIJeXHgqKzfUhayO+Gml3sXlJIOegwB6c/Xu fprwV+x9omgwMjQIH37lWNNhI3cD8vTGefw9b8M24ndFbIXIAXtXZQ6JG0I2hpOeSBkBh2zXxFfH 1akrtn6bhcto0opJHn/hT4J6N4St5Db2Ma78ktgbiT1P1rlvir8BNG8U6ZLGLK2BnO2TMQYHr19+ efWvap7QrCQzKrZ6dz71jazZRiEuewJHbpXGsRU5r3O94Wm48tj8vv2s/wBiLWf2XtWh+IXwt1LW NI+ysr3FtZXDQyQtjHmK68rkZyBxX60f8EK/+Cr1p+3J8Il8FeLNQuR8UfCkBM4uxmTVbRSFWbzM /vJVJxJlVPIOD8xrwf4qaGureHL+2eNZIp42QoRkHivzJ/Zw+JGr/sY/t8+GvF3h1Z400zxDFE8M cq2/2mJ5drwb3VlTejvHkggbjwc8/W5NmEql4Td7HwHEWUwpWqU1a5/VdRUGlaguraXbXaxzRLcx LKEljaORAwBwysAysM8ggEHggVPX0p8eFFFFABRRRQAUUUUAFFFFAH5af8HS3w9W6/Zi8GeLDJeS S6bra6aiSXiJZwLKrSNiEDfJLI0UZ3ZKqlueAWBPyz/wTi+Fr+Hvhjb61cgILzKxHu656+wHAA9q +2f+DkbR4fiP+yLpnhnTDPqPiqz1JNaj0yFmYpaIkkcl0UHBZSQik9pJR0LEfMP7IkUfiH9j3wbt aVFudLVJGjYqwPIY5HIOR1r5/O6icOVPrr5H1XDtGUZ+0lF7XXn6HtGkfELw9ZayNOk1nT4ryPG6 IyguhJ6H0P15r0ePS3W0jkilEkcmCMcjnuDX59a38Hfgb8PrzWtR8QaH4h1bTtL2y6hevc3L2dkJ JViVnkYlQN7qCT90EknAJHpn7Nfh/wABahpNlrXw+1HXLPTtRRrqxld5jBcRo5iYxeYBlFkUqcDG R3618/LA0eTnTl620PraWPxHtOSSj6X1+4+wZtLup42VhtKjuQBXm/xT+M/gT4WQIviPxZoOlTuC UhuL+JJXx6KTkj3rd8W3k+q+C90lwVjmUKWDkMT3/X0xXyl8ddR+FHwI0/UfEvizwleeI0+1RWU9 9JbK9vHPIrSRxPLJiNSVDHMjKOVGeQKyoYWlUklK78kdGLxlanBuNl5voeiaX+0x4G+JeuvpOk61 bSX7J5kUTnZ9oT+9GejdO1fDP/BQj4NP8OPiZpWq2KRzW+r36SpASFEjh1yhOQADkckgYXtgV9Ze BbHwdruuae9t8OR4SubuCHU7PNpGjRLLGrplo/uSbWAZCdynIOOM8F/wUU+Eeo/EzxR8LdL0+Bpn l1S4aZQVVgiRxuxy3HC7vXHoa7sE6dHEe5dLqmeRmMatfC2mlJu1mutz95vhXqS6x8MfDl2sF7ar daXbSiG8EguIt0SnbIJAH3jODvAbIOec1vV53+yr8WdB+MXwQ0bUPDxuEtNPjGlywTgia1mgVUaN 8k5OApBycqynvXolfaU5xnFSi7pn53WpTpTdOorNaNBRRRVmYUUUUAFFFFABRRRQB8H/ALdHhSU/ tQa1d6ttks77Rbb7H2McS7kwPcTGVvxFfNX7JXhI6D8D9F0yWKS2e0MsZRgFMY3sVBx/skD3r9A/ +CgPwWm8efD6HxHYQtPe+HY5BcxJw81oxVnIODzGyK/Ixt318d211KkpeV43Z5Sdy/LuGBgn3xXx uZ0HCtOL+1qj9KyrExrYSjUW8fdflZfrZMv/APCm9PNncLPHaTw3sTRSwzWyyxTIwwVZehBGQQeD mo9E+Etp4Q09diWltDHD9kto4IfLjtoccqg5CrjsuAB26V2XhXXkTTVjZA7Dngcj/PrWB8V/FckF vvnjuf7PiR5FitVBlupAOI1yQMnoASAT3AryIKVuW+h9BKnFe9YztUUz+BreFnUr5oZ+P4N2SB6H FMf4epfStOvks8gUXBMQPn4xg5xk9B19KwNZ+NWlp4CiJ0TxGdU8sF9NS233uSfu+WOAQOC28rn+ LFdj8KfFL3Mc8MRmubKJFZGnXbJGxHzRtnuOMjt0pyhKGq0CMoTdmQv8PrG1L3LKTKcEkgAg14x8 fFNt8TPh3fJbia3stTu1nkP3ER7N1BOevUY9x9K978X6+lvpsmxcFhj1xXl2t+G5vGeoWNrbRSXl 3PP5dtbRqS1xM7IETjnBOOOM8UsOmpOT1JrKClGL7o+xP+CT+iXGnfCjxhcyK62914iZIgTkMY7a BGYfUgD6g+lfVNcR+zl8Jh8EPgvoPhtnSW7soDJeSryJbmRjJK2e43swGewFdvX3+BoulQjB7pf8 E/Ks4xaxONqV47N6ei0X4IKKKK6jzAooooAKKKKACiiigBHQSIVYBlYYIIyCK+Lf26/g3pPw18W6 Dd6Hp0OnWOsRzCWKHIjEqMpyAeFBWQAAYHy8CvtOvLv2vPhJL8WvhBcx2ab9V0aT+0LNR1lKKQ8f 1ZCwA/vBa4sww/taMklr0PSyrFuhiIyb91vX+vI+GrnU7jRtKuLq2jeZoI92xOWPqMV5tq37Rdhp tzdW2s301rcJwtssUnnbeRk7uNp7HJzivRNI1iOGRt5JEo6joPes7xp8LtO+IUiSs62d3D/q50Ul hzkDjH1r4WFRQnaSP1CCU7O+hw0n7QnhJ9H2NqyNEy+X5Jhk3Lgls5BPdTkdareFv2l9MfUobbTd SjmmkYILaVTHLJyfmUMcEYx349K6a5+EPiFblEbXbMW+0/vzpxMp4xjPmenOdua1PDfwm0r4dwm5 Cm/upBh5ZF2k5POM9j9a2rVadtL/ADNJU6bX7vR+RdubuXVdOgmnjaEzrv2EH8x/P6V9Gf8ABNbw HY6pqXinXbzTra5msJbeCwuJYg7WzlZDIUJGVYqY8kYOOK+Y9Y8Ub5nwqgxDaAvbiv0K/ZD+EM3w Y+B+m6fexmPVtQZtR1BT1jmkA+Q+6IqIfdSe9d2Q0Oetz20R83xNiuTD+zvrLT7t/wCvM9Nooor7 M/PQooooAKKKKACiiigAooooAKyPHviiHwV4L1PVbhDJHY27ybAMmRsfKn1ZsD8a0NS1S20aze5v LmC0t4xlpZpBGi/UngV4x8Z/jdYeNdMGj6JM1zaNOovLnYVRtpDBEzyecEnGOABnJxMpWRUY3Z8J XAZII8OMlBg9m4qOXxHfWNuqsryLn70a7s/lyD/nNei/GP4NyeE9TeW1jI0y9YyW23kQPzvh/A8r 6rgfwnPnNjpUty+BMkTZxhwcfn3r4WdPlm4zWqP0yhJ1KaqUno/6sZ58f6tZuz/Y78xMxIBUMFHr wc5+vpUc3j681aJokjkQvhiZBjA/x57Cumk8F6xNASZrMRjvk56emOKwz4UnmujCJRId2GZBgLWc mnujaMJrZkvgm/g0vxNpt7fBpYLa9hmmRQCzIsilgAepKjoa/WK3uEu7eOWNg8cqh1b1BGQa/L/4 b/DBvE3jC1tlUvY6cVubxznDAHKx59XYY+gY9q+4fgL8ftPfSbTw/rt3HZ6hbKY7SWVdkVzCgAAL /dDqCAQ2NwwRuO7Hv5HK0ZN6J7HyvEsF7SEVq0m38z2KigEEAggg0V9CfKhRRRQAUUUUAFFZHjDx zpngXTjc6lcrEGB8uIfNLMR2Ve56ewzyRXjfiT49az4q1Fre1kbRrV1OxImBlb3Zzz/3yBjPfFTK aW5cYOWx6/4v+Iuk+CFC31zm5dd6W0S75nHrtHQcHk4HvXC67+0RPdAw6Zp/2VpV/dy3Lhnx6hBw fqC30PSvKhcRtckoJZ7lpNzTOQSXBUZyc5+9+h5rQ1HU5FtpXaOOJFUyf3iGCg5yfx65P06VhKq/ Q6IUVp1/Ir6vdHXdXabUrq4vZyVAMrGR8E9ucKuewIH4c1F4F0BNQsRJAjFI3crk8lt7DGT3x3Pc rVSGOQ6XLO2DNcSAgnkjLEKfwHNdH8KpFjn1Wx2hjHIk8a55KugUqPqUP4stTDV2fUuatFNdNRt/ oFrrely2V5DFNbSLhkfO0gdDxyMeo5AwQQUrwH4nfBa/+H/iA3luJLnSZ22pMRzE2fuTADCtnA3D 5W4IwWAr6oudLWVtwbkncHHrjOf+BDn6hh/FVPU7K1tdPmmvDbCwETm583BhWIL8xbdxtVSTzwUJ B6Vy4zBRrR5no1/X9eZ35Xmc8LOy1i+n9fgfJZ01mgIMYO4dAflH4U/wr4NvvEmsfYNPgRrnG+SW T5YLGPP+skI6Dg4UcsQccAle0vfC+i69rtq2h6xHpuk6tc7LJr+JjiMrnzE5BKE7ghl25VQxY5AP rmg+A7LwdpSadpkbC3iPmSzPhpbqQgEySH+JiNpx0HyKAAMV41LLKkp2qaL8/Q+lxee0I070dZPu tvXz9DlPDPgq18JaWmn2Su6jLSyuuJbhyMNI+P4jjoPugBR9wVcfw5GL+wll8tCsxCFgCNxjkz2P bjgcjFdjZ+HI7ZyXYLI3vnknA/AEE/8AAQe9YnjxoheabBGQpKSXCBc5BDRKOP8AddR+de/Ciox5 Y7LRHx9StKc+ebu3qyXwl461fwFrcUWm3h+y3abktnJkiVgeV2ZypIBPy4bg16t4Y/aCsrpkh1iH +z5HHE8ZMkDfX+Jf1H+1XiGsIItLXUIYjLJZjzlVQMsNylhz/vZ/CtqyFtrVoZoplkaUb/Tj1OeT 9Tn6inTnNbEVqUfQ+lbW6ivrdJoJY5oZRuR0YMrD1BHBFPr508N+NNW+HOqlLGVWVlLTWsuTE3uV HKt/tcfiOvsngD4qaf47hWNR9jvwPmtnbJOOpVuNw6+hGOQK6oVVI5J0nE6eiiitDM+YdX1C68Ua xJe6jcG4upfvb+VgXPCgdABkHHoSeuaxNZshLqvyRlXgK7vfKvkfmB+Qro7KzXUrBLyJV3SKDMh5 Ctk5P03Ej/db2rJ04j+1dY2biEEUaBuvKjB+uGAPutcNVv7z0KKXzRJo1qPtM5PKQ5jU+pDJk0a5 GZEgtYztNzKI/oDvFaOmWf2XS4gAdzRsxPckhD/OmwxC78SSNgMlmQinsZDIQfyBotv6/wCZSe3p /kQXkCpFbQxj/XOir9FCn+tXfDKLY+NLJlLKZ7aeJ9vVlCxSZ+oCkj3FMeMNqdugBP2eIMfq3lil EU0GrWWowOgeyjdlUjhmMaA59sA05R39RRlqvQ63X9ds/DWkXF5qFxFZWsCEvITwvPUAckhyCAOS GAANeCeKNY8T/GT4peFxMkem/D6OWdptKlUCbWZ0hZ4HmJBxCp+YR4wSi7t3yhe4TwxcarqpvNau v7RuoG2woAVtrMYkH7pDnBwFG9ssQBzjit3TrSK21ywLKG3PJtyMkHyO34Zq5Sbu/wCuhFOCTVtS 0PhRYagu65gjaYFsMrsVR+VLjtuxkZwTg8EVykfiDU/hjrFzZXom1HTYp8R3Ea5aEFUdQV643OvO Sfl6GvX7mQmd8gY3t0/32/8Ar1w3iCMPrt2wAJWWM89/kh/wrSaSt6foZU23e5d0zUrLxRprXFlc xzxZKvtPzRHGwBh1DBASQeRmua8VKB460xZAwD2UwAPY+bE5/Lp/wGqQ8KvpWL/SJRYXjIGYBf3U 5KEkOo65zyevNWNRW+8Q+I9Hv54oohaWrQzhGyPMZ2LN75YH8MVin8K+Zu425n8jQ0+1VYYAUG0v tI7EfuhWB4btJLGS50pjsOmugiYHB8pgGQ59lD10unAtCoz8yt+XzR1jeItIZ/EGmXiuyR3qGwnA 4Lt5StHz9PMH4ispX5Fb+tjWLTm79iOHUrpiJ0fic4RGGVIyDyO33u2Mbalg1hb28txCtzDKm1t0 f/LNsjbg5B3dDkcjPSp7qMSXCuF2CLcyjGABhv6Fags4ktdZuVUnbaKIlI6l3GCfwRfzIqne78tD NJWV15nq/wANvjYLTThaeIZ2Yxg+RfBS4nUY+VgozuAI5xyOuDyxXmGm2w1KN45eLRTuHoHJY4X2 AOPwB7iitlVa0Od0U9SHwdrJ02T7Myl0S4MLDjDqeG/End+lWrTTRZ67q0GQypdhQe5GIjz+LH86 KKzbvF/I3taSt5ly5m+xaSZcZCQHAHr5Y/wpfD1qIo4mJy8n79z6lmjb+uKKKJ9fUIP4fQit/nvr t+4bYPoGjxVtkH2UAAABWH/jjf4UUVU936/5hDZeg2TEQlYdQwx+ZH/s1W9NjX7fZ5AYsXC57Hyl Ofyz+dFFOT1l/XVExWkfU6qa5D3kqjcGTex9DzL/AIVyWsoW12/Gc4lxz7AD/wBlooq5/oZU1oVx EFsVAHACj/yGtEEa/ZwSOSFP6uaKKzjvH0f6m0tpeq/QW0gEExAxgk5/OOoNctvN8O3u0gSWafao Sf4XiRGU/mv5E0UVKWiXn/kEnZt+Q22CX0dtIFISeNSAeo3GIfyrD8P+ZrGua06sEEM7oP8AeCp8 3/j3/joooo6/P/Mb2t5fqjRsp/L8MWEyRQyNdJ5oVwdqjnjjuPX39hRRRWVR7eiLh19T/9k= --=_related 00158A1948257DC5_= Content-Type: image/jpeg Content-ID: <_2_0DF75ACC0DF756F800158A1348257DC5> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAIgBjAwERAAIRAQMRAf/EAJQAAAIDAQEBAAAAAAAAAAAA AAYHAAUIAQQDAQEAAwEBAAAAAAAAAAAAAAAAAwQFAgEQAAEDAgQDBAYDEQEAAAAAAAIBAwQFBgAR EgchExQxQSIIUXGBMrIVUiMXkaFCcjNTczR0tDV1hcUWRjdjEQABAwQBAwMFAAAAAAAAAAAAAQID ETESBCFBgQVxwROxIoJDNP/aAAwDAQACEQMRAD8AOL4uneOJdlRjURqYVKbcRIhNwhdBR0Cq5Hyy 1eLPvxq68UCsRXUy9SrI5+XFis283Qvyr3rTKZUKjzoj7jgvsoy0KrpaMu0QRUyIcSbWpG2NVROT mKVyuopV1PczeKlqK1F+RCB1SRlZENttC09unU2meWeJWa0Drc9zlZXpcILRvbdSW1UplVKQlObp MuXElHFBtpXgb1MkLiAiF6UTPjivsQQpRG3yTqdse+62oDdN3L3hqiH8tlSZqtZc3p4jTunVnlq0 trlnliw/VgbfjuRpK9bDbsK7KjFs4qnf00aZIWYbIv1Llwk0qiK2PjRsePiy9OMrbaxH0ZahaiVy pyL/AMxO+J0W26XI2/uiC5UHZihMSG5FmFyeUS+IF5ulNSJxyxWJRl0HdSwXqNTnJl1UnrnYzJSR KbGEuaTYqaKOtMl1d2WAKir70Q4e6S7ddEcefJhK7TalJXTHemGCmy0iJxVskRU15+8mnLvwAPbI by1e5LPuubdhNjWLZefemCAo2IR+WTgCgp9AmjHjmvBM1zwBeeXvcu49wLIdq1djMsyo0o4gyGMx F9AADU+WuelU15LkuXqwAyKo641TZbrZaXG2XCAvQQgqouAM/faXfXyXqPmznN+UdVq5bX5b5r0/ M/J/m+GWAG9uhcf+P2VUJjZ6ZTwdLD9PNe8KKn4o5l7MT6kWciJ0I5XYtFh5dra51Rn3E8OYRB6S Iq/nHEQnST8UMk9uNHykvCMT1INZt1LHzK/qtv8A6ST8LeOPFXd2PdmyBbD/AOIj/IS/dlxVX+j8 vcl/X2FDtJuJSbNWprUY8h/rkZ5XToC5crXnq1kP0+GNTd1XS0x6VKsMqNue3zL3TBunYiPV4TTj MdyrsgIPIKHm2Lwr7qkn38Yk0SxuxUusfklRJ7kbOUm1NsLUvCLUH5Mq4hYJ+K6II23zo3PXQo+J cl4ccRnR9t39nKTYFJtCowqhImncAK682+ICLagDJ5Dp/TL24AZ/mbrVmTrpttyl1+PTrxt2e3Hm k6D6dOyuT4OmQtkhIyYouQKq+LAAHeNy2jQ2twajbNzR6m9e7vTs0qIxIDkx3nuofedN0GxT8NsQ HPgeeeAND+W2q2V9nkC3bfqbVQn0pgHq0jQOjokSyNwkVXADVkWoUVPo4AZ9Z/hE79nd+BcAZb/1 7+gf3rABf5h7kWVW4Nvx1Uggh1EgE733uAD60D4sbXjIqNV6lPZdzQbe3lt/45aNPphDpkC3zZa+ l93xuZ+pV0+zGXsy/I9XFmNuLUQXPmV/VbfX/wBZPwt4v+Ku7sQbVkC2H/w8f5CX7suKrv6Py9yT 9fYWextnW5chVlK3CSYkVI/I1EY6eZzNXuEPbpTGh5Cd7McVpcrwMR1al55htuZL+z6UKzqW490s 9qZ0EfU65o+sRwgElIyXU4i5JjGdI561dcutaiJRDNG4txbtv2XQrdvCjPUyhUhW2aW4/CcjERMs q0Iq4eSGvL7fu45PS0u09979gUCNV7WnOQKQKJTnI1OfBFbcFsdSlkSEii2PHADF801pbXUFXa6+ 3IlXtX3m3W4iSFFsWm9Iuum2iZiKiGgePvLw7FwBXbv7M7d2htlCuumUOorLnHE5zEmTwiC+iOGj yCPbw5XDsJfZgB2bD2TtrSLfW47FN8odfaZJ9JD3OUCZ1fVqmSaTAnCEsAMas/wid+zu/AuAMt/6 9/QP71gAvvLZy/qlddTqcXkSWZcgnmHieRs0FfcFRVOCgiInsxsQb0bWIi9Cm+ByrU9FpbZboU+6 aXOqL6lBjSAckp1pOZgnb4FXxerHOxtQuYqInPoesieioqhZvRY1w3WxSW6M224UM3if5riN5I4I IOWfb7q4raOw2JVy6kk8auRKBHTrbnJtw1bshRZnLTVhOEi6wFxWlDPNO1EXELpU+XNLZVJEb9tB Jx9ld04ikkXls6uBKzM5aFl2Z6dOftxrrvwrf6FT4HpYcW1Vv3DQrZODXzU5yyXHEJXVf+rJBQfG vqXhjJ25GPfVlqFqJqonIHeZrba7L9tik06247ciTEmrIfF10GUQOSQZopqmfEsVyQalvxH4dBps OQiC/GisMvCi5ohttiJIip28UwAo5Pl4bq29k6+q9M62jCTMinU1wicJXwBE0uauCMtGOoQTt7Ox OIDbuK36XcFFm0aqMo/T57RMyWl7xLvRe4hXiK9y8cALjYjZuobbFcTD9SKbBnSQWmNoRIKMgK/W G37ovEpaSy7hTADPqjZuUyW22Kk4bLggKdqqoKiJgDO/2f3r8k5HyWRzfk3T6PDnzvm3P0e928vx YA0lgCYA5gDuAJgCYAmAJgCYAmAJgCYAmAP/2Q== --=_related 00158A1948257DC5_=-- From nobody Tue Jan 6 01:50:42 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9CE1A9122 for ; Tue, 6 Jan 2015 01:50:40 -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_29=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 hbeFYvNwCVUs for ; Tue, 6 Jan 2015 01:50:38 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 907981A1BB7 for ; Tue, 6 Jan 2015 01:50:36 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8F3741CC089C; Tue, 6 Jan 2015 10:50:41 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> <27E3CF22-5D4C-4AB3-AB2A-97C93843B9E7@nic.cz> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 06 Jan 2015 10:50:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yKwzBRNZyIzXEgTym1tqtYBc_0c Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 09:50:41 -0000 Andy Bierman writes: > On Mon, Jan 5, 2015 at 6:28 AM, Ladislav Lhotka wrote: >> >>> On 05 Jan 2015, at 14:59, Andy Bierman wrote: >>> >>> On Mon, Jan 5, 2015 at 5:46 AM, Ladislav Lhotka wrote: >>>> >>>>> On 05 Jan 2015, at 14:20, Andy Bierman wrote: >>>>> >>>>> On Mon, Jan 5, 2015 at 1:23 AM, Ladislav Lhotka wrote: >>>>>> >>>>>>> On 22 Dec 2014, at 18:09, Andy Bierman wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I updated the issue tracker with the concrete proposal for >>>>>>> ietf-restconf groupings. >>>>>> >>>>>> I=E2=80=99d rather like to see the definition of the proposed extens= ion, and I will comment on that. >>>>>> >>>>> >>>>> https://github.com/netconf-wg/restconf/issues/15 >>>> >>>> The ietf-restconf module imports ietf-yang-types. How can an implement= or figure out which revision of ietf-yang-types to use? >>>> >>> >>> >>> Either the server advertises it or the ietf-netconf-monitoring >>> module contains that data. >> >> IMO schemas outside the data and operation resources have to be fixed fo= r the given RESTconf version. >> > > OK -- but the restconf-resource extension is on github > and the ietf-restconf module in draft-03 that does not > have an import-by-revision is not related to this issue. It is related to that issue in the sense that it is IMO impossible to pretend that YANG can be turned into a general-purpose schema language just by wrapping a schema in an extension. RFC 6020 is too NETCONF-centric and several things are undefined or ill-defined if used outside the NETCONF context (or considerably more text is needed in the definition of the restconf-resource extension): - If a list is present, is it required to have keys or not? - What would if-feature mean inside rc:restconf-resource? - If "must" and "when" expressions are used, the accessible tree for their XPath expressions is undefined - sections 7.5.3 and 7.19.5 only deal with config and state data, notifications, and RPC input/output. - What is the accessible tree for the "path" statement in leafref type? According to sec. 9.9.2 it could be "all state data on the device, and the datastore", but it doesn't make sense. - If the identityref type is used, how can one determine the set of permitted values? > > However, I share concerns raised by Balazs that the increased complexity > and confusion that can result from trying to follow all the revision-spec= ific > differences may be unacceptable. (The solution is worse than the > original problem.) It might work if the revision-date was the min-revisi= on > instead of the exact revision, but we should debate Y45 on the NETMOD > list. It makes no sense to me to discuss conformance issues here because what you want to do is to define certain fixed schemas as a part of the RESTCONF spec. Lada > >>> >>> How does this have anything to do with the restconf-resource extension? >> >> This has to do with using YANG as a general schema language, i.e. outsid= e the normal NETCONF context. >> > > Do you have any objections to the resource-identifier definition? > > >> Lada >> > > Andy > >> >>> >>> >>>> Lada >>>> >>> >>> Andy >>> >>>>> >>>>> >>>>>> Lada >>>>> >>>>> Andy >>>>> >>>>>> >>>>>>> >>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>> >>>>>>> I forgot to mention that ietf-yang-patch.yang already uses the "err= ors" grouping >>>>>>> within the rpc output parameters, so removing it will break YANG Pa= tch. >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> >>>>>>> On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka w= rote: >>>>>>>> Andy Bierman writes: >>>>>>>> >>>>>>>>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund wrote: >>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>> >>>>>>>>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund wr= ote: >>>>>>>>>>>> >>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>> Andy Bierman writes: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> A new issue has been added to the tracker: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are 3 solutions mentioned. >>>>>>>>>>>>>> The default solution is S1, which will be implemented >>>>>>>>>>>>>> unless there is WG consensus demonstrated to >>>>>>>>>>>>>> do something else. >>>>>>>>>>>>> >>>>>>>>>>>>> The biggest problem with S1 is that it may mislead readers in= to >>>>>>>>>>>>> thinking: "Hey, now I understand how namespaces work in group= ings!" >>>>>>>>>>>>> >>>>>>>>>>>>> I also don't like the idea of defining an ad hoc extension. >>>>>>>>>>>> >>>>>>>>>>>> I disagree. I think an extension is the best solution in this= case. >>>>>>>>>>>> However, we can use a different name than 'structure'. 'struc= ture' >>>>>>>>>>>> was originally my proposal for a built-in statement (YANG 1.1)= for >>>>>>>>>>>> this purpose. We can call it 'restconf-structure' or 'restcon= f-data' >>>>>>>>>>>> or something. >>>>>>>>>>> >>>>>>>>>>> So another document that wants to do the same should define its= own ad >>>>>>>>>>> hoc extension? Or import the ietf-restconf module? >>>>>>>>>> >>>>>>>>>> Suppose we make a new document that defines a new RESTCONF resou= rce >>>>>>>>>> type, and we need a structure for it, then that document would i= mport >>>>>>>>>> and use 'restconf-structure'. >>>>>>>>>> >>>>>>>>>>>>> If we want >>>>>>>>>>>>> to turn YANG into a general schema language, it should be done >>>>>>>>>>>>> properly. >>>>>>>>>>>>> >>>>>>>>>>>>> I think the simplest solution would be to remove the grouping= s and >>>>>>>>>>>>> have >>>>>>>>>>>>> "errors", "restconf", "collection" and "notification" as top-= level >>>>>>>>>>>>> containers. The namespace assignment then follows YANG rules. >>>>>>>>>>>> >>>>>>>>>>>> This is also _very_ misleading, b/c then it looks like a norma= l config >>>>>>>>>>>> or state module, which one would expect a server to implement = in the >>>>>>>>>>>> normal way. >>>>>>>>>>> >>>>>>>>>>> What makes the solutions with groupings or extensions different? >>>>>>>>>> >>>>>>>>>> I agree that groupings are misleading. But using an extension w= ould >>>>>>>>>> be different, b/c the extension defines the semantics - this is = not >>>>>>>>>> config or oper state, but something else. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I do not understand why these are special or misleading groupings. >>>>>>>>> I cannot find any text in any RFC that says a YANG module with >>>>>>>>> just groupings in it is invalid, improper, or even discouraged. >>>>>>>>> >>>>>>>>> I am already using 1 of these groupings in a logging model. >>>>>>>>> Please explain why these are special groupings that cannot >>>>>>>>> be used in a normal data model in another module. >>>>>>>>> >>>>>>>>> That is why I prefer solution S2-B >>>>>>>>> >>>>>>>>> rc:structure errors { >>>>>>>>> uses errors; >>>>>>>>> } >>>>>>>>> >>>>>>>>> This assigns a module-name and a namespace and does not >>>>>>>>> preclude re-usage of the data within a larger data structure. >>>>>>>> >>>>>>>> I don't want to block the resolution of this issue, so I propose t= hat you >>>>>>>> write a concrete definition of the extension, and I will then comm= ent on >>>>>>>> that. >>>>>>>> >>>>>>>> Lada >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> In >>>>>>>>>>> any case, the module description has to state very clearly that= it is >>>>>>>>>>> a strawman module that=E2=80=99s not supposed to be used in the= normal >>>>>>>>>>> NETCONF/RESTCONF way. But if you above that deviate from YANG >>>>>>>>>>> semantics, as the groupings do, you cannot even use standard YA= NG >>>>>>>>>>> tools because they would produce wrong results. >>>>>>>>>>> >>>>>>>>>>> If the module is as I proposed, I can still use pyang for gener= ating >>>>>>>>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>>>>>>> >>>>>>>>>>> And if a server implementor likes the module and decides to imp= lement >>>>>>>>>>> it as if it was a normal module, so what? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> S3 should IMO be fine, too, the structures aren't that compli= cated. >>>>>>>>>>>> >>>>>>>>>>>> I can see only drawbacks compared to S2. Whatever we do in te= xt it >>>>>>>>>>>> will be less precise than an extension. >>>>>>>>>>> >>>>>>>>>>> I prefer less precise to precise but wrong. >>>>>>>>>> >>>>>>>>>> An extension is in no way wrong. >>>>>>>>>> >>>>>>>>> >>>>>>>>> agreed >>>>>>>>> >>>>>>>>>>> Keep in mind that you are >>>>>>>>>>> a YANG designer so you are not as likely to get confused by lan= guage >>>>>>>>>>> anomalies as an average reader of the RESTCONF document. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /martin >>>>>>>>> >>>>>>>>> Andy >>>>>>>> >>>>>>>> -- >>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>> PGP Key ID: E74E8C0C >>>>>> >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 6 06:54:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB891A70E1 for ; Tue, 6 Jan 2015 06:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 U6h-_mliDcaJ for ; Tue, 6 Jan 2015 06:54:34 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36C91A6F21 for ; Tue, 6 Jan 2015 06:54:33 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id hv19so20247573lab.28 for ; Tue, 06 Jan 2015 06:54: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 :content-transfer-encoding; bh=hG6p1BL7AfzK4aak6a6PqSLtmEZLibW8Pj4hgeSdjEM=; b=DKV6HvoPSzKgatFYz43xJ0M4tmBx2ci38jr6kJ7pelQKmoeabtRfAx0Hz1/Fx6OS0N xKRnVs6tB2ksaFTiqGgNq5dSRsthP9pjnLe7wMQ6xjJGvJUYeb1N3bxPfcW/YuICluUA Ee0rctIm9VWMZPTK7yLHfKL6FKT1N7pTcJ9ad+PYaljkq/tyVxn9KPlHsXwvwonll3yv KgS9lJfrOeOHTpfIxANy74/xfFexVXitLExFXxl05SxF+/SAqTCcva7i7Hqt8FxJEwt7 Z5I7VrxkYeADFY178bxQdupnqbpCtIRkvZ3sRu6GjoPqN9Z3oKu/N9I0SHTPWhGHTdKp ZJLQ== X-Gm-Message-State: ALoCoQnHE1rG6eWG51kl2rF4g+DKRRg33KvxaPRvuJ63OzmUfDE1W5K0MojcTSPa4GsXK5UDO6hb MIME-Version: 1.0 X-Received: by 10.112.85.11 with SMTP id d11mr100242942lbz.100.1420556071935; Tue, 06 Jan 2015 06:54:31 -0800 (PST) Received: by 10.112.77.231 with HTTP; Tue, 6 Jan 2015 06:54:31 -0800 (PST) In-Reply-To: References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> <27E3CF22-5D4C-4AB3-AB2A-97C93843B9E7@nic.cz> Date: Tue, 6 Jan 2015 06:54:31 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/B4ZJzH0aDl0Nc01xZDJGTLX6S2U Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 14:54:37 -0000 On Tue, Jan 6, 2015 at 1:50 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> On Mon, Jan 5, 2015 at 6:28 AM, Ladislav Lhotka wrote: >>> >>>> On 05 Jan 2015, at 14:59, Andy Bierman wrote: >>>> >>>> On Mon, Jan 5, 2015 at 5:46 AM, Ladislav Lhotka wrote: >>>>> >>>>>> On 05 Jan 2015, at 14:20, Andy Bierman wrote: >>>>>> >>>>>> On Mon, Jan 5, 2015 at 1:23 AM, Ladislav Lhotka wrot= e: >>>>>>> >>>>>>>> On 22 Dec 2014, at 18:09, Andy Bierman wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I updated the issue tracker with the concrete proposal for >>>>>>>> ietf-restconf groupings. >>>>>>> >>>>>>> I=E2=80=99d rather like to see the definition of the proposed exten= sion, and I will comment on that. >>>>>>> >>>>>> >>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>> >>>>> The ietf-restconf module imports ietf-yang-types. How can an implemen= tor figure out which revision of ietf-yang-types to use? >>>>> >>>> >>>> >>>> Either the server advertises it or the ietf-netconf-monitoring >>>> module contains that data. >>> >>> IMO schemas outside the data and operation resources have to be fixed f= or the given RESTconf version. >>> >> >> OK -- but the restconf-resource extension is on github >> and the ietf-restconf module in draft-03 that does not >> have an import-by-revision is not related to this issue. > > It is related to that issue in the sense that it is IMO impossible to > pretend that YANG can be turned into a general-purpose schema language > just by wrapping a schema in an extension. RFC 6020 is too > NETCONF-centric and several things are undefined or ill-defined if used > outside the NETCONF context (or considerably more text is needed in the > definition of the restconf-resource extension): > > - If a list is present, is it required to have keys or not? > > - What would if-feature mean inside rc:restconf-resource? > > - If "must" and "when" expressions are used, the accessible tree for > their XPath expressions is undefined - sections 7.5.3 and 7.19.5 only > deal with config and state data, notifications, and RPC input/output. > > - What is the accessible tree for the "path" statement in leafref type? > According to sec. 9.9.2 it could be "all state data on the device, and > the datastore", but it doesn't make sense. > > - If the identityref type is used, how can one determine the set of > permitted values? This is determined by the identity base and not a problem > These are valid questions and the restconf-resource extension would have to specify these details. The short answer is that all the datastore specific statements would be ignored and have no affect: So what is your solution proposal instead? What are the options? 1) XSD Pros: it exists and can specify syntax Cons: Not widely liked or easy to learn. No JSON support so RESTCONF support for JSON would have to be removed, or wait for a JSON schema language to be standardized. 2) Plain text Pros: plain text is always allowed in an RFC Cons: all tools must be hand-coded and plain text can be interpreted very loosely, leading to poor interoperability. Do you have a solution proposal? I completely agree that YANG is being used here in a manner different than NETCONF. YANG does not even completely work for RESTCONF, let alone resource abstractions or a new datastore for I2RS. We are using YANG as a low-level info model here. We do not want to tightly couple the protocol messages to a specific syntax= . IMO this is a big weakness with NETCONF and YANG. The message encoding could be XML, JSON, CBOR, EXI, who cares. But YANG is tightly coupled to NETCONF and XML and that isn't changing in YANG 1.1. >> >> However, I share concerns raised by Balazs that the increased complexity >> and confusion that can result from trying to follow all the revision-spe= cific >> differences may be unacceptable. (The solution is worse than the >> original problem.) It might work if the revision-date was the min-revis= ion >> instead of the exact revision, but we should debate Y45 on the NETMOD >> list. > > It makes no sense to me to discuss conformance issues here because what > you want to do is to define certain fixed schemas as a part of the > RESTCONF spec. You brought up import-by-revision. I agree it is irrelevant to this issue. > > Lada > Andy >> >>>> >>>> How does this have anything to do with the restconf-resource extension= ? >>> >>> This has to do with using YANG as a general schema language, i.e. outsi= de the normal NETCONF context. >>> >> >> Do you have any objections to the resource-identifier definition? >> >> >>> Lada >>> >> >> Andy >> >>> >>>> >>>> >>>>> Lada >>>>> >>>> >>>> Andy >>>> >>>>>> >>>>>> >>>>>>> Lada >>>>>> >>>>>> Andy >>>>>> >>>>>>> >>>>>>>> >>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>> >>>>>>>> I forgot to mention that ietf-yang-patch.yang already uses the "er= rors" grouping >>>>>>>> within the rpc output parameters, so removing it will break YANG P= atch. >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka = wrote: >>>>>>>>> Andy Bierman writes: >>>>>>>>> >>>>>>>>>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund wrote: >>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund w= rote: >>>>>>>>>>>>> >>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>> Andy Bierman writes: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A new issue has been added to the tracker: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There are 3 solutions mentioned. >>>>>>>>>>>>>>> The default solution is S1, which will be implemented >>>>>>>>>>>>>>> unless there is WG consensus demonstrated to >>>>>>>>>>>>>>> do something else. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The biggest problem with S1 is that it may mislead readers i= nto >>>>>>>>>>>>>> thinking: "Hey, now I understand how namespaces work in grou= pings!" >>>>>>>>>>>>>> >>>>>>>>>>>>>> I also don't like the idea of defining an ad hoc extension. >>>>>>>>>>>>> >>>>>>>>>>>>> I disagree. I think an extension is the best solution in thi= s case. >>>>>>>>>>>>> However, we can use a different name than 'structure'. 'stru= cture' >>>>>>>>>>>>> was originally my proposal for a built-in statement (YANG 1.1= ) for >>>>>>>>>>>>> this purpose. We can call it 'restconf-structure' or 'restco= nf-data' >>>>>>>>>>>>> or something. >>>>>>>>>>>> >>>>>>>>>>>> So another document that wants to do the same should define it= s own ad >>>>>>>>>>>> hoc extension? Or import the ietf-restconf module? >>>>>>>>>>> >>>>>>>>>>> Suppose we make a new document that defines a new RESTCONF reso= urce >>>>>>>>>>> type, and we need a structure for it, then that document would = import >>>>>>>>>>> and use 'restconf-structure'. >>>>>>>>>>> >>>>>>>>>>>>>> If we want >>>>>>>>>>>>>> to turn YANG into a general schema language, it should be do= ne >>>>>>>>>>>>>> properly. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think the simplest solution would be to remove the groupin= gs and >>>>>>>>>>>>>> have >>>>>>>>>>>>>> "errors", "restconf", "collection" and "notification" as top= -level >>>>>>>>>>>>>> containers. The namespace assignment then follows YANG rules= . >>>>>>>>>>>>> >>>>>>>>>>>>> This is also _very_ misleading, b/c then it looks like a norm= al config >>>>>>>>>>>>> or state module, which one would expect a server to implement= in the >>>>>>>>>>>>> normal way. >>>>>>>>>>>> >>>>>>>>>>>> What makes the solutions with groupings or extensions differen= t? >>>>>>>>>>> >>>>>>>>>>> I agree that groupings are misleading. But using an extension = would >>>>>>>>>>> be different, b/c the extension defines the semantics - this is= not >>>>>>>>>>> config or oper state, but something else. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I do not understand why these are special or misleading grouping= s. >>>>>>>>>> I cannot find any text in any RFC that says a YANG module with >>>>>>>>>> just groupings in it is invalid, improper, or even discouraged. >>>>>>>>>> >>>>>>>>>> I am already using 1 of these groupings in a logging model. >>>>>>>>>> Please explain why these are special groupings that cannot >>>>>>>>>> be used in a normal data model in another module. >>>>>>>>>> >>>>>>>>>> That is why I prefer solution S2-B >>>>>>>>>> >>>>>>>>>> rc:structure errors { >>>>>>>>>> uses errors; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> This assigns a module-name and a namespace and does not >>>>>>>>>> preclude re-usage of the data within a larger data structure. >>>>>>>>> >>>>>>>>> I don't want to block the resolution of this issue, so I propose = that you >>>>>>>>> write a concrete definition of the extension, and I will then com= ment on >>>>>>>>> that. >>>>>>>>> >>>>>>>>> Lada >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> In >>>>>>>>>>>> any case, the module description has to state very clearly tha= t it is >>>>>>>>>>>> a strawman module that=E2=80=99s not supposed to be used in th= e normal >>>>>>>>>>>> NETCONF/RESTCONF way. But if you above that deviate from YANG >>>>>>>>>>>> semantics, as the groupings do, you cannot even use standard Y= ANG >>>>>>>>>>>> tools because they would produce wrong results. >>>>>>>>>>>> >>>>>>>>>>>> If the module is as I proposed, I can still use pyang for gene= rating >>>>>>>>>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>>>>>>>> >>>>>>>>>>>> And if a server implementor likes the module and decides to im= plement >>>>>>>>>>>> it as if it was a normal module, so what? >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> S3 should IMO be fine, too, the structures aren't that compl= icated. >>>>>>>>>>>>> >>>>>>>>>>>>> I can see only drawbacks compared to S2. Whatever we do in t= ext it >>>>>>>>>>>>> will be less precise than an extension. >>>>>>>>>>>> >>>>>>>>>>>> I prefer less precise to precise but wrong. >>>>>>>>>>> >>>>>>>>>>> An extension is in no way wrong. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> agreed >>>>>>>>>> >>>>>>>>>>>> Keep in mind that you are >>>>>>>>>>>> a YANG designer so you are not as likely to get confused by la= nguage >>>>>>>>>>>> anomalies as an average reader of the RESTCONF document. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /martin >>>>>>>>>> >>>>>>>>>> Andy >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>> PGP Key ID: E74E8C0C >>>>>>> >>>>>>> -- >>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>> PGP Key ID: E74E8C0C >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Tue Jan 6 07:49:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEDF1A8844 for ; Tue, 6 Jan 2015 07:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 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, J_CHICKENPOX_29=0.6, 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 XUeCkgHNIj54 for ; Tue, 6 Jan 2015 07:49:39 -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 092241A885E for ; Tue, 6 Jan 2015 07:49:33 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:a40f:a932:aa81:d5c2] (unknown [IPv6:2001:718:1a02:1:a40f:a932:aa81:d5c2]) by mail.nic.cz (Postfix) with ESMTPSA id 9ECB3140A50; Tue, 6 Jan 2015 16:49:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1420559371; bh=OH2w8XibcaVV0chENiv2+ZJImJ9F5NW19uWtMMevTKs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=b/FANSny1J6/atLLNl9GS5mYloZZ25VOQAMEeaWtHLg0k9U95iMvI+8JSHSsZt5JV OzxrsnloxKcVvsGDo57CvJd6fhD8xDPDiJZGUAM8LGqKe+t5JKbW3Nr29BmM/7r3Hl KLssi39aGBjLoV5IZRANHtBU37iyHrmZNtxTj8Kk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 6 Jan 2015 16:49:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <838CEF6F-0AB8-49CA-A466-EC9FB50B18F2@nic.cz> References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> <27E3CF22-5D4C-4AB3-AB2A-97C93843B9E7@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Cs8-6Wd6j6bE1_7P2AdxXt8ehpk Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 15:49:42 -0000 > On 06 Jan 2015, at 15:54, Andy Bierman wrote: >=20 > On Tue, Jan 6, 2015 at 1:50 AM, Ladislav Lhotka wrote: >> Andy Bierman writes: >>=20 >>> On Mon, Jan 5, 2015 at 6:28 AM, Ladislav Lhotka = wrote: >>>>=20 >>>>> On 05 Jan 2015, at 14:59, Andy Bierman wrote: >>>>>=20 >>>>> On Mon, Jan 5, 2015 at 5:46 AM, Ladislav Lhotka = wrote: >>>>>>=20 >>>>>>> On 05 Jan 2015, at 14:20, Andy Bierman = wrote: >>>>>>>=20 >>>>>>> On Mon, Jan 5, 2015 at 1:23 AM, Ladislav Lhotka = wrote: >>>>>>>>=20 >>>>>>>>> On 22 Dec 2014, at 18:09, Andy Bierman = wrote: >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> I updated the issue tracker with the concrete proposal for >>>>>>>>> ietf-restconf groupings. >>>>>>>>=20 >>>>>>>> I=E2=80=99d rather like to see the definition of the proposed = extension, and I will comment on that. >>>>>>>>=20 >>>>>>>=20 >>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>=20 >>>>>> The ietf-restconf module imports ietf-yang-types. How can an = implementor figure out which revision of ietf-yang-types to use? >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> Either the server advertises it or the ietf-netconf-monitoring >>>>> module contains that data. >>>>=20 >>>> IMO schemas outside the data and operation resources have to be = fixed for the given RESTconf version. >>>>=20 >>>=20 >>> OK -- but the restconf-resource extension is on github >>> and the ietf-restconf module in draft-03 that does not >>> have an import-by-revision is not related to this issue. >>=20 >> It is related to that issue in the sense that it is IMO impossible to >> pretend that YANG can be turned into a general-purpose schema = language >> just by wrapping a schema in an extension. RFC 6020 is too >> NETCONF-centric and several things are undefined or ill-defined if = used >> outside the NETCONF context (or considerably more text is needed in = the >> definition of the restconf-resource extension): >>=20 >> - If a list is present, is it required to have keys or not? >>=20 >> - What would if-feature mean inside rc:restconf-resource? >>=20 >> - If "must" and "when" expressions are used, the accessible tree for >> their XPath expressions is undefined - sections 7.5.3 and 7.19.5 = only >> deal with config and state data, notifications, and RPC = input/output. >>=20 >> - What is the accessible tree for the "path" statement in leafref = type? >> According to sec. 9.9.2 it could be "all state data on the device, = and >> the datastore", but it doesn't make sense. >>=20 >> - If the identityref type is used, how can one determine the set of >> permitted values? >=20 > This is determined by the identity base and not a problem Sec. 9.10.2: "On a particular server, the valid values are further = restricted to the set of identities defined in the modules supported by = the server.=E2=80=9D But there is no particular server, the schema has to be identical for = all. >=20 >>=20 >=20 > These are valid questions and the restconf-resource extension would = have to > specify these details. The short answer is that all the datastore Then one has to ask whether it is worth the hassle for this ad hoc = purpose. And I don=E2=80=99t think we want to see other people following = this example and defining extensions like this on their own. > specific statements would be ignored and have no affect: >=20 >=20 > So what is your solution proposal instead? >=20 > What are the options? >=20 > 1) XSD > Pros: it exists and can specify syntax > Cons: Not widely liked or easy to learn. No JSON support > so RESTCONF support for JSON would have to be removed, > or wait for a JSON schema language to be standardized. >=20 > 2) Plain text > Pros: plain text is always allowed in an RFC > Cons: all tools must be hand-coded and plain text can be interpreted > very loosely, leading to poor interoperability. I think the schemas are relatively trivial and plain text should do.=20 >=20 >=20 > Do you have a solution proposal? >=20 > I completely agree that YANG is being used here in a manner different > than NETCONF. > YANG does not even completely work for RESTCONF, let alone resource > abstractions or a new datastore for I2RS. >=20 > We are using YANG as a low-level info model here. > We do not want to tightly couple the protocol messages to a specific = syntax. > IMO this is a big weakness with NETCONF and YANG. > The message encoding could be XML, JSON, CBOR, EXI, who cares. > But YANG is tightly coupled to NETCONF and XML and that isn't > changing in YANG 1.1. I have supported, actually proposed, to make YANG into a more general = schema language by removing the dependence on NETCONF (and XML), but I = believe this has to be done by rewriting the spec, and not by bending it = via extension hacks.=20 Lada >=20 >=20 >=20 >>>=20 >>> However, I share concerns raised by Balazs that the increased = complexity >>> and confusion that can result from trying to follow all the = revision-specific >>> differences may be unacceptable. (The solution is worse than the >>> original problem.) It might work if the revision-date was the = min-revision >>> instead of the exact revision, but we should debate Y45 on the = NETMOD >>> list. >>=20 >> It makes no sense to me to discuss conformance issues here because = what >> you want to do is to define certain fixed schemas as a part of the >> RESTCONF spec. >=20 > You brought up import-by-revision. > I agree it is irrelevant to this issue. >=20 >=20 >>=20 >> Lada >>=20 >=20 > Andy >=20 >=20 >>>=20 >>>>>=20 >>>>> How does this have anything to do with the restconf-resource = extension? >>>>=20 >>>> This has to do with using YANG as a general schema language, i.e. = outside the normal NETCONF context. >>>>=20 >>>=20 >>> Do you have any objections to the resource-identifier definition? >>>=20 >>>=20 >>>> Lada >>>>=20 >>>=20 >>> Andy >>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> Lada >>>>>>>=20 >>>>>>> Andy >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>=20 >>>>>>>>> I forgot to mention that ietf-yang-patch.yang already uses the = "errors" grouping >>>>>>>>> within the rpc output parameters, so removing it will break = YANG Patch. >>>>>>>>>=20 >>>>>>>>> Andy >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka = wrote: >>>>>>>>>> Andy Bierman writes: >>>>>>>>>>=20 >>>>>>>>>>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund = wrote: >>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund = wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>>> Andy Bierman writes: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> A new issue has been added to the tracker: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> There are 3 solutions mentioned. >>>>>>>>>>>>>>>> The default solution is S1, which will be implemented >>>>>>>>>>>>>>>> unless there is WG consensus demonstrated to >>>>>>>>>>>>>>>> do something else. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The biggest problem with S1 is that it may mislead = readers into >>>>>>>>>>>>>>> thinking: "Hey, now I understand how namespaces work in = groupings!" >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I also don't like the idea of defining an ad hoc = extension. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I disagree. I think an extension is the best solution in = this case. >>>>>>>>>>>>>> However, we can use a different name than 'structure'. = 'structure' >>>>>>>>>>>>>> was originally my proposal for a built-in statement (YANG = 1.1) for >>>>>>>>>>>>>> this purpose. We can call it 'restconf-structure' or = 'restconf-data' >>>>>>>>>>>>>> or something. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> So another document that wants to do the same should = define its own ad >>>>>>>>>>>>> hoc extension? Or import the ietf-restconf module? >>>>>>>>>>>>=20 >>>>>>>>>>>> Suppose we make a new document that defines a new RESTCONF = resource >>>>>>>>>>>> type, and we need a structure for it, then that document = would import >>>>>>>>>>>> and use 'restconf-structure'. >>>>>>>>>>>>=20 >>>>>>>>>>>>>>> If we want >>>>>>>>>>>>>>> to turn YANG into a general schema language, it should = be done >>>>>>>>>>>>>>> properly. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> I think the simplest solution would be to remove the = groupings and >>>>>>>>>>>>>>> have >>>>>>>>>>>>>>> "errors", "restconf", "collection" and "notification" as = top-level >>>>>>>>>>>>>>> containers. The namespace assignment then follows YANG = rules. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This is also _very_ misleading, b/c then it looks like a = normal config >>>>>>>>>>>>>> or state module, which one would expect a server to = implement in the >>>>>>>>>>>>>> normal way. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> What makes the solutions with groupings or extensions = different? >>>>>>>>>>>>=20 >>>>>>>>>>>> I agree that groupings are misleading. But using an = extension would >>>>>>>>>>>> be different, b/c the extension defines the semantics - = this is not >>>>>>>>>>>> config or oper state, but something else. >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I do not understand why these are special or misleading = groupings. >>>>>>>>>>> I cannot find any text in any RFC that says a YANG module = with >>>>>>>>>>> just groupings in it is invalid, improper, or even = discouraged. >>>>>>>>>>>=20 >>>>>>>>>>> I am already using 1 of these groupings in a logging model. >>>>>>>>>>> Please explain why these are special groupings that cannot >>>>>>>>>>> be used in a normal data model in another module. >>>>>>>>>>>=20 >>>>>>>>>>> That is why I prefer solution S2-B >>>>>>>>>>>=20 >>>>>>>>>>> rc:structure errors { >>>>>>>>>>> uses errors; >>>>>>>>>>> } >>>>>>>>>>>=20 >>>>>>>>>>> This assigns a module-name and a namespace and does not >>>>>>>>>>> preclude re-usage of the data within a larger data = structure. >>>>>>>>>>=20 >>>>>>>>>> I don't want to block the resolution of this issue, so I = propose that you >>>>>>>>>> write a concrete definition of the extension, and I will then = comment on >>>>>>>>>> that. >>>>>>>>>>=20 >>>>>>>>>> Lada >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>> In >>>>>>>>>>>>> any case, the module description has to state very clearly = that it is >>>>>>>>>>>>> a strawman module that=E2=80=99s not supposed to be used = in the normal >>>>>>>>>>>>> NETCONF/RESTCONF way. But if you above that deviate from = YANG >>>>>>>>>>>>> semantics, as the groupings do, you cannot even use = standard YANG >>>>>>>>>>>>> tools because they would produce wrong results. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> If the module is as I proposed, I can still use pyang for = generating >>>>>>>>>>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> And if a server implementor likes the module and decides = to implement >>>>>>>>>>>>> it as if it was a normal module, so what? >>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> S3 should IMO be fine, too, the structures aren't that = complicated. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I can see only drawbacks compared to S2. Whatever we do = in text it >>>>>>>>>>>>>> will be less precise than an extension. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I prefer less precise to precise but wrong. >>>>>>>>>>>>=20 >>>>>>>>>>>> An extension is in no way wrong. >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> agreed >>>>>>>>>>>=20 >>>>>>>>>>>>> Keep in mind that you are >>>>>>>>>>>>> a YANG designer so you are not as likely to get confused = by language >>>>>>>>>>>>> anomalies as an average reader of the RESTCONF document. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> /martin >>>>>>>>>>>=20 >>>>>>>>>>> Andy >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 6 08:33:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2251A8862 for ; Tue, 6 Jan 2015 08:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.56 X-Spam-Level: X-Spam-Status: No, score=-0.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_29=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, THIS_AD=0.819] 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 DiliBhEoRVpf for ; Tue, 6 Jan 2015 08:32:56 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8691A8784 for ; Tue, 6 Jan 2015 08:31:38 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so20317150lab.37 for ; Tue, 06 Jan 2015 08:31: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 :content-transfer-encoding; bh=Hs1zxtbUPAJEG4LS/9aO7RJpEwNaCo7+QtIvikjyl4c=; b=fQAsMXlVfqiXPLLkvSSaLJwY2fpjn7n26VE0hlq72mqQowaGK+b4gL6G9nlyjydpoQ 4e4EZPtvnv5QSGBTHiZsrvFrQuix4CT/8SuFcG28OZhjXRAABcof35iTCE0qT/VMyai0 Seb3zx+tvG9IGo1nzRtcxS3+I+W5bV0Q1mMV3R7f+nA0JlLjz3p3gyGJ+vFQ6Wzq0RrU wIpAU6DgMpW+DqOepn/NSdEf4xgL1aSp4JwNShZqNRe6PW1Najd65cw3Dkcs8odibKSP nfZar8X3u2BNQhMOgold6qsaRcSkXoyNU1N3HlYTdmwVeZZFkCHKXQulmssO4z5kg1Po q8GQ== X-Gm-Message-State: ALoCoQlwGPaBEr5qdDaTDjnKZWHOc4q5Xy4MP/sGwva+ugt9nRDY805t5mIZUWOzPXFIbImQh/CZ MIME-Version: 1.0 X-Received: by 10.112.25.7 with SMTP id y7mr27158403lbf.94.1420561896625; Tue, 06 Jan 2015 08:31:36 -0800 (PST) Received: by 10.112.77.231 with HTTP; Tue, 6 Jan 2015 08:31:36 -0800 (PST) In-Reply-To: <838CEF6F-0AB8-49CA-A466-EC9FB50B18F2@nic.cz> References: <20141211.124922.734445723149087483.mbj@tail-f.com> <20141211.134843.810246336811127833.mbj@tail-f.com> <27E3CF22-5D4C-4AB3-AB2A-97C93843B9E7@nic.cz> <838CEF6F-0AB8-49CA-A466-EC9FB50B18F2@nic.cz> Date: Tue, 6 Jan 2015 08:31:36 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1MmsD8VILzAsarpyppIXxxU79s4 Cc: Netconf Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 16:32:59 -0000 On Tue, Jan 6, 2015 at 7:49 AM, Ladislav Lhotka wrote: > >> On 06 Jan 2015, at 15:54, Andy Bierman wrote: >> >> On Tue, Jan 6, 2015 at 1:50 AM, Ladislav Lhotka wrote: >>> Andy Bierman writes: >>> >>>> On Mon, Jan 5, 2015 at 6:28 AM, Ladislav Lhotka wrote: >>>>> >>>>>> On 05 Jan 2015, at 14:59, Andy Bierman wrote: >>>>>> >>>>>> On Mon, Jan 5, 2015 at 5:46 AM, Ladislav Lhotka wrot= e: >>>>>>> >>>>>>>> On 05 Jan 2015, at 14:20, Andy Bierman wrote: >>>>>>>> >>>>>>>> On Mon, Jan 5, 2015 at 1:23 AM, Ladislav Lhotka wr= ote: >>>>>>>>> >>>>>>>>>> On 22 Dec 2014, at 18:09, Andy Bierman wrot= e: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I updated the issue tracker with the concrete proposal for >>>>>>>>>> ietf-restconf groupings. >>>>>>>>> >>>>>>>>> I=E2=80=99d rather like to see the definition of the proposed ext= ension, and I will comment on that. >>>>>>>>> >>>>>>>> >>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>> >>>>>>> The ietf-restconf module imports ietf-yang-types. How can an implem= entor figure out which revision of ietf-yang-types to use? >>>>>>> >>>>>> >>>>>> >>>>>> Either the server advertises it or the ietf-netconf-monitoring >>>>>> module contains that data. >>>>> >>>>> IMO schemas outside the data and operation resources have to be fixed= for the given RESTconf version. >>>>> >>>> >>>> OK -- but the restconf-resource extension is on github >>>> and the ietf-restconf module in draft-03 that does not >>>> have an import-by-revision is not related to this issue. >>> >>> It is related to that issue in the sense that it is IMO impossible to >>> pretend that YANG can be turned into a general-purpose schema language >>> just by wrapping a schema in an extension. RFC 6020 is too >>> NETCONF-centric and several things are undefined or ill-defined if used >>> outside the NETCONF context (or considerably more text is needed in the >>> definition of the restconf-resource extension): >>> >>> - If a list is present, is it required to have keys or not? >>> >>> - What would if-feature mean inside rc:restconf-resource? >>> >>> - If "must" and "when" expressions are used, the accessible tree for >>> their XPath expressions is undefined - sections 7.5.3 and 7.19.5 only >>> deal with config and state data, notifications, and RPC input/output. >>> >>> - What is the accessible tree for the "path" statement in leafref type? >>> According to sec. 9.9.2 it could be "all state data on the device, and >>> the datastore", but it doesn't make sense. >>> >>> - If the identityref type is used, how can one determine the set of >>> permitted values? >> >> This is determined by the identity base and not a problem > > Sec. 9.10.2: "On a particular server, the valid values are further restri= cted to the set of identities defined in the modules supported by the serve= r.=E2=80=9D > > But there is no particular server, the schema has to be identical for all= . > >> >>> >> >> These are valid questions and the restconf-resource extension would have= to >> specify these details. The short answer is that all the datastore > > Then one has to ask whether it is worth the hassle for this ad hoc purpos= e. And I don=E2=80=99t think we want to see other people following this exa= mple and defining extensions like this on their own. > >> specific statements would be ignored and have no affect: >> >> >> So what is your solution proposal instead? >> >> What are the options? >> >> 1) XSD >> Pros: it exists and can specify syntax >> Cons: Not widely liked or easy to learn. No JSON support >> so RESTCONF support for JSON would have to be removed, >> or wait for a JSON schema language to be standardized. >> >> 2) Plain text >> Pros: plain text is always allowed in an RFC >> Cons: all tools must be hand-coded and plain text can be interpreted >> very loosely, leading to poor interoperability. > > I think the schemas are relatively trivial and plain text should do. > Then please provide the replacement text. IMO it is not simple to write the detailed XML and JSON encoding rules for all the protocol messages. That's why we have schema languages instead. The lack of machine-readable schema is a big step backwards. IMO it would be better to drop JSON support completely, and use XSD. This issue also applies to all the groupings in the YANG Patch document. That document needs to be completely rewritten so the complex YANG data structures are replaced with plain text or XSD as well. So who else wants the ietf-restconf and ietf-yang-patch modules removed and replaced with plain text? Who wants to drop JSON support and use XSD? Andy >> >> >> Do you have a solution proposal? >> >> I completely agree that YANG is being used here in a manner different >> than NETCONF. >> YANG does not even completely work for RESTCONF, let alone resource >> abstractions or a new datastore for I2RS. >> >> We are using YANG as a low-level info model here. >> We do not want to tightly couple the protocol messages to a specific syn= tax. >> IMO this is a big weakness with NETCONF and YANG. >> The message encoding could be XML, JSON, CBOR, EXI, who cares. >> But YANG is tightly coupled to NETCONF and XML and that isn't >> changing in YANG 1.1. > > I have supported, actually proposed, to make YANG into a more general sch= ema language by removing the dependence on NETCONF (and XML), but I believe= this has to be done by rewriting the spec, and not by bending it via exten= sion hacks. > > Lada > >> >> >> >>>> >>>> However, I share concerns raised by Balazs that the increased complexi= ty >>>> and confusion that can result from trying to follow all the revision-s= pecific >>>> differences may be unacceptable. (The solution is worse than the >>>> original problem.) It might work if the revision-date was the min-rev= ision >>>> instead of the exact revision, but we should debate Y45 on the NETMOD >>>> list. >>> >>> It makes no sense to me to discuss conformance issues here because what >>> you want to do is to define certain fixed schemas as a part of the >>> RESTCONF spec. >> >> You brought up import-by-revision. >> I agree it is irrelevant to this issue. >> >> >>> >>> Lada >>> >> >> Andy >> >> >>>> >>>>>> >>>>>> How does this have anything to do with the restconf-resource extensi= on? >>>>> >>>>> This has to do with using YANG as a general schema language, i.e. out= side the normal NETCONF context. >>>>> >>>> >>>> Do you have any objections to the resource-identifier definition? >>>> >>>> >>>>> Lada >>>>> >>>> >>>> Andy >>>> >>>>> >>>>>> >>>>>> >>>>>>> Lada >>>>>>> >>>>>> >>>>>> Andy >>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Lada >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>> >>>>>>>>>> I forgot to mention that ietf-yang-patch.yang already uses the "= errors" grouping >>>>>>>>>> within the rpc output parameters, so removing it will break YANG= Patch. >>>>>>>>>> >>>>>>>>>> Andy >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Dec 15, 2014 at 10:49 AM, Ladislav Lhotka wrote: >>>>>>>>>>> Andy Bierman writes: >>>>>>>>>>> >>>>>>>>>>>> On Thu, Dec 11, 2014 at 4:48 AM, Martin Bjorklund wrote: >>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11 Dec 2014, at 12:49, Martin Bjorklund = wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>>>>>> Andy Bierman writes: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A new issue has been added to the tracker: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://github.com/netconf-wg/restconf/issues/15 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There are 3 solutions mentioned. >>>>>>>>>>>>>>>>> The default solution is S1, which will be implemented >>>>>>>>>>>>>>>>> unless there is WG consensus demonstrated to >>>>>>>>>>>>>>>>> do something else. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The biggest problem with S1 is that it may mislead readers= into >>>>>>>>>>>>>>>> thinking: "Hey, now I understand how namespaces work in gr= oupings!" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I also don't like the idea of defining an ad hoc extension= . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I disagree. I think an extension is the best solution in t= his case. >>>>>>>>>>>>>>> However, we can use a different name than 'structure'. 'st= ructure' >>>>>>>>>>>>>>> was originally my proposal for a built-in statement (YANG 1= .1) for >>>>>>>>>>>>>>> this purpose. We can call it 'restconf-structure' or 'rest= conf-data' >>>>>>>>>>>>>>> or something. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So another document that wants to do the same should define = its own ad >>>>>>>>>>>>>> hoc extension? Or import the ietf-restconf module? >>>>>>>>>>>>> >>>>>>>>>>>>> Suppose we make a new document that defines a new RESTCONF re= source >>>>>>>>>>>>> type, and we need a structure for it, then that document woul= d import >>>>>>>>>>>>> and use 'restconf-structure'. >>>>>>>>>>>>> >>>>>>>>>>>>>>>> If we want >>>>>>>>>>>>>>>> to turn YANG into a general schema language, it should be = done >>>>>>>>>>>>>>>> properly. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think the simplest solution would be to remove the group= ings and >>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>> "errors", "restconf", "collection" and "notification" as t= op-level >>>>>>>>>>>>>>>> containers. The namespace assignment then follows YANG rul= es. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is also _very_ misleading, b/c then it looks like a no= rmal config >>>>>>>>>>>>>>> or state module, which one would expect a server to impleme= nt in the >>>>>>>>>>>>>>> normal way. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What makes the solutions with groupings or extensions differ= ent? >>>>>>>>>>>>> >>>>>>>>>>>>> I agree that groupings are misleading. But using an extensio= n would >>>>>>>>>>>>> be different, b/c the extension defines the semantics - this = is not >>>>>>>>>>>>> config or oper state, but something else. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I do not understand why these are special or misleading groupi= ngs. >>>>>>>>>>>> I cannot find any text in any RFC that says a YANG module with >>>>>>>>>>>> just groupings in it is invalid, improper, or even discouraged= . >>>>>>>>>>>> >>>>>>>>>>>> I am already using 1 of these groupings in a logging model. >>>>>>>>>>>> Please explain why these are special groupings that cannot >>>>>>>>>>>> be used in a normal data model in another module. >>>>>>>>>>>> >>>>>>>>>>>> That is why I prefer solution S2-B >>>>>>>>>>>> >>>>>>>>>>>> rc:structure errors { >>>>>>>>>>>> uses errors; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> This assigns a module-name and a namespace and does not >>>>>>>>>>>> preclude re-usage of the data within a larger data structure. >>>>>>>>>>> >>>>>>>>>>> I don't want to block the resolution of this issue, so I propos= e that you >>>>>>>>>>> write a concrete definition of the extension, and I will then c= omment on >>>>>>>>>>> that. >>>>>>>>>>> >>>>>>>>>>> Lada >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> In >>>>>>>>>>>>>> any case, the module description has to state very clearly t= hat it is >>>>>>>>>>>>>> a strawman module that=E2=80=99s not supposed to be used in = the normal >>>>>>>>>>>>>> NETCONF/RESTCONF way. But if you above that deviate from YAN= G >>>>>>>>>>>>>> semantics, as the groupings do, you cannot even use standard= YANG >>>>>>>>>>>>>> tools because they would produce wrong results. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the module is as I proposed, I can still use pyang for ge= nerating >>>>>>>>>>>>>> correct DSDL schemas, XML-JSON mapping etc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And if a server implementor likes the module and decides to = implement >>>>>>>>>>>>>> it as if it was a normal module, so what? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> S3 should IMO be fine, too, the structures aren't that com= plicated. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can see only drawbacks compared to S2. Whatever we do in= text it >>>>>>>>>>>>>>> will be less precise than an extension. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I prefer less precise to precise but wrong. >>>>>>>>>>>>> >>>>>>>>>>>>> An extension is in no way wrong. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> agreed >>>>>>>>>>>> >>>>>>>>>>>>>> Keep in mind that you are >>>>>>>>>>>>>> a YANG designer so you are not as likely to get confused by = language >>>>>>>>>>>>>> anomalies as an average reader of the RESTCONF document. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> /martin >>>>>>>>>>>> >>>>>>>>>>>> Andy >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>>> PGP Key ID: E74E8C0C >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>> PGP Key ID: E74E8C0C >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Tue Jan 6 09:59:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFC11A1A66 for ; Tue, 6 Jan 2015 09:59: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 Y7fkto8Fmp2G for ; Tue, 6 Jan 2015 09:59:20 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.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 CF3561A1A31 for ; Tue, 6 Jan 2015 09:59:19 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 17:59:17 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.138]) with mapi id 15.01.0049.002; Tue, 6 Jan 2015 17:59:17 +0000 From: Kent Watsen To: Joe Touch , Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] netconf call home term 'tcp session' Thread-Index: AQHQKQsNS/cpmIkWS06aUXE6uabINpyxmNGAgABjOYCAARMFgA== Date: Tue, 6 Jan 2015 17:59:16 +0000 Message-ID: References: <20150105171408.GA8394@elstar.local> <54AAF56F.3040606@isi.edu> In-Reply-To: <54AAF56F.3040606@isi.edu> 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.241.14] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(51704005)(189002)(24454002)(199003)(377454003)(68736005)(4396001)(86362001)(106356001)(105586002)(107046002)(97736003)(36756003)(106116001)(77156002)(62966003)(87936001)(2656002)(99286002)(92566001)(122556002)(19580405001)(19580395003)(99396003)(83506001)(2950100001)(21056001)(102836002)(66066001)(31966008)(20776003)(64706001)(54356999)(50986999)(2501002)(2171001)(40100003)(120916001)(76176999)(15975445007)(46102003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <75E4540262133E4EAE3B21E28392AE78@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2015 17:59:16.5023 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/iIxc9mnbQ3790nnwYCj4kIiUCSg Cc: "chen.qiaogang@zte.com.cn" Subject: Re: [Netconf] netconf call home term 'tcp session' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 17:59:22 -0000 +chen.qiaogang Ok, ok, I'll replace session with connection. Just opened https://github.com/netconf-wg/call-home/issues/9 to track this. Note, issue #9's description contains a link to Joe's email having specific draft text change suggestions, all of which look very good to me (thank you Joe!) Kent On 1/5/15, 3:34 PM, "Joe Touch" wrote: > > >On 1/5/2015 11:39 AM, Kent Watsen wrote: >>=20 >> True, RFC 793 does not use the term "tcp session", but other RFCs do: >>=20 >> https://www.google.com/search?&q=3D%22tcp+session%22+site:ietf.org > >EPP refers to a session, and then goes on to refer (IMO incorrectly) to >TCP sessions. That's the primary BCP/standard doc series that does so. > >NAT and STUN refer to sessions to include associations over >non-connection protocols. SIP's and RTP's brief of the term is likely >related to other parts of the protocol being called "session". > >Others are Historic. > >IMO, it ought to be referred to as a TCP connection. A session is an >association which may or may not involve a TCP connection. > >> The reason is because of comments received regarding which TCP >> connection/session was being used. The current text uses these >>different >> terms in trying to be more clear (perhaps not). As currently written, >>the >> term "connection" only appears once, in a desperate attempt to put an >>end >> to how many connections there are ;) >>=20 >> You still think it should be changed? > >FWIW, I do. Overall, the TCP language needs cleaning. E.g.: > > >> o The NETCONF/RESTCONF server initiates a TCP connection to the > >a TCP connection request (SYN) > >> NETCONF/RESTCONF client on one of the IANA-assigned ports for call >> home (PORT-X for netconf-ch-ssh, PORT-Y for netconf-ch-tls, or >> PORT-Z for restconf-ch-tls). >>=20 >> o The TCP connection is accepted and a TCP session is established. > >The TCP connection request is accepted and a TCP connection is >established. > >> o Using this TCP session, the NETCONF/RESTCONF server immediately > >TCP connection > >> starts either the SSH-server or the TLS-server protocol, depending >> on which port is connected. The server MUST start the SSH-server > >depending on which port is used in the connection. > >[note - ports aren't "connected"; they're only 1/4 of a TCP connection >identifier] > >> protocol when port PORT-X is connected or the TLS-server protocol >> when either port PORT-Y or PORT-Z is connected. The SSH-server >> and TLS-server protocols are described by [RFC4253] and [RFC5246] >> respectively. > >I'm not sure why you're mandating when the server must be started. >That's an implementation issue, and when it starts depends on how >incoming connection requests are handled. > >However, the server must be started before *user data* is exchanged. >AFAICT there is no requirement that the service be started before a port >is used in a TCP connection in the ESTABLISHED state. > >I think what you mean to say here can be sufficiently indicated as: > > o Using this TCP connection, the NETCONF/RESTCONF server MUST >immediately start using either the SSH-server or the TLS-server >protocol, depending on which port receives the connection request. The >SSH-server and TLS-server protocols are described by [RFC4253] and >[RFC5246] respectively. > >Joe > From nobody Tue Jan 6 13:03:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E631A6FEC for ; Tue, 6 Jan 2015 13:03: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 0ajzyNr7j_vD for ; Tue, 6 Jan 2015 13:03:55 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A978D1A0113 for ; Tue, 6 Jan 2015 13:03:54 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id u14so30379lbd.37 for ; Tue, 06 Jan 2015 13:03: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; bh=cQJl/zCax0oWd1yG7/kodN09JXxTh//LUpux185oMbg=; b=eqqz2WTIgNtqgV7MZo1IoulsCmUKO/FwuOox07TEvyOl2jL0gqLCmjYNQxSuc4GEZi 2hpLVa17p2iBNSWdHR5YtoWeE/uf5Xt30PuwymNmgeE4Qyr4gH8uoqMT5ZEV0sZi7B7W 3AIHmUL8i1rRW+keqCk09bt1beu5e8aOUv5l5SFvt5V3iYC78AQR5RhSS+EWHlg6UDMd WD4pmBz7s+0n85ncBSFYBhbOlhCL6hv7PftW0tQFuqcsu9N9v1JSw42Z1AAOaRbfkCm9 TeNY0ogQUbGuWLPZUcd6XyJBU4QzZCNB5hX30vjOSjUABMZbo1kMVbffz0qOc6AL2iLh VsXg== X-Gm-Message-State: ALoCoQmUmJuC/tSL3wMAn8NxM2LLgarEzehi0c1z8DV4slO1xuSk7k18/9AY5h/cmMg34IufUuFz MIME-Version: 1.0 X-Received: by 10.112.85.11 with SMTP id d11mr102948010lbz.100.1420578233128; Tue, 06 Jan 2015 13:03:53 -0800 (PST) Received: by 10.112.77.231 with HTTP; Tue, 6 Jan 2015 13:03:53 -0800 (PST) In-Reply-To: <54AAF56F.3040606@isi.edu> References: <20150105171408.GA8394@elstar.local> <54AAF56F.3040606@isi.edu> Date: Tue, 6 Jan 2015 13:03:53 -0800 Message-ID: From: Andy Bierman To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eBCf_rlceL8TlwCRnhGVxHte818 Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf call home term 'tcp session' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 21:03:57 -0000 Hi, I agree with all the edits proposed by Joe. IMO this is a bugfix and should not take long to decide. Andy On Mon, Jan 5, 2015 at 12:34 PM, Joe Touch wrote: > > > On 1/5/2015 11:39 AM, Kent Watsen wrote: >> >> True, RFC 793 does not use the term "tcp session", but other RFCs do: >> >> https://www.google.com/search?&q=%22tcp+session%22+site:ietf.org > > EPP refers to a session, and then goes on to refer (IMO incorrectly) to > TCP sessions. That's the primary BCP/standard doc series that does so. > > NAT and STUN refer to sessions to include associations over > non-connection protocols. SIP's and RTP's brief of the term is likely > related to other parts of the protocol being called "session". > > Others are Historic. > > IMO, it ought to be referred to as a TCP connection. A session is an > association which may or may not involve a TCP connection. > >> The reason is because of comments received regarding which TCP >> connection/session was being used. The current text uses these different >> terms in trying to be more clear (perhaps not). As currently written, the >> term "connection" only appears once, in a desperate attempt to put an end >> to how many connections there are ;) >> >> You still think it should be changed? > > FWIW, I do. Overall, the TCP language needs cleaning. E.g.: > > >> o The NETCONF/RESTCONF server initiates a TCP connection to the > > a TCP connection request (SYN) > >> NETCONF/RESTCONF client on one of the IANA-assigned ports for call >> home (PORT-X for netconf-ch-ssh, PORT-Y for netconf-ch-tls, or >> PORT-Z for restconf-ch-tls). >> >> o The TCP connection is accepted and a TCP session is established. > > The TCP connection request is accepted and a TCP connection is established. > >> o Using this TCP session, the NETCONF/RESTCONF server immediately > > TCP connection > >> starts either the SSH-server or the TLS-server protocol, depending >> on which port is connected. The server MUST start the SSH-server > > depending on which port is used in the connection. > > [note - ports aren't "connected"; they're only 1/4 of a TCP connection > identifier] > >> protocol when port PORT-X is connected or the TLS-server protocol >> when either port PORT-Y or PORT-Z is connected. The SSH-server >> and TLS-server protocols are described by [RFC4253] and [RFC5246] >> respectively. > > I'm not sure why you're mandating when the server must be started. > That's an implementation issue, and when it starts depends on how > incoming connection requests are handled. > > However, the server must be started before *user data* is exchanged. > AFAICT there is no requirement that the service be started before a port > is used in a TCP connection in the ESTABLISHED state. > > I think what you mean to say here can be sufficiently indicated as: > > o Using this TCP connection, the NETCONF/RESTCONF server MUST > immediately start using either the SSH-server or the TLS-server > protocol, depending on which port receives the connection request. The > SSH-server and TLS-server protocols are described by [RFC4253] and > [RFC5246] respectively. > > Joe > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jan 6 13:34:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCAE1A1B61 for ; Tue, 6 Jan 2015 13:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.389 X-Spam-Level: X-Spam-Status: No, score=0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, 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 A_8_dz6k33WU for ; Tue, 6 Jan 2015 13:34:27 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id D9AB31A1AA7 for ; Tue, 6 Jan 2015 13:34:26 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 6041C1280052; Tue, 6 Jan 2015 22:34:25 +0100 (CET) Date: Tue, 06 Jan 2015 22:34:49 +0100 (CET) Message-Id: <20150106.223449.1160000230471393141.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <838CEF6F-0AB8-49CA-A466-EC9FB50B18F2@nic.cz> References: <838CEF6F-0AB8-49CA-A466-EC9FB50B18F2@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: http://mailarchive.ietf.org/arch/msg/netconf/lsFzRD_l_kI4lphqd12OOema3sQ Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 21:34:28 -0000 Ladislav Lhotka wrote: > > > On 06 Jan 2015, at 15:54, Andy Bierman wrote: [...] > > I completely agree that YANG is being used here in a manner different > > than NETCONF. > > YANG does not even completely work for RESTCONF, let alone resource > > abstractions or a new datastore for I2RS. > > > > We are using YANG as a low-level info model here. > > We do not want to tightly couple the protocol messages to a specific > > syntax. > > IMO this is a big weakness with NETCONF and YANG. > > The message encoding could be XML, JSON, CBOR, EXI, who cares. > > But YANG is tightly coupled to NETCONF and XML and that isn't > > changing in YANG 1.1. > > I have supported, actually proposed, to make YANG into a more general > schema language by removing the dependence on NETCONF (and XML) I agree, to some extent. I also think that a core statement "structure" would be the best solution. Meanwhile, in YANG 1.0, an extension like the one proposed is the best way to solve this. > but I > believe this has to be done by rewriting the spec, and not by bending > it via extension hacks. /martin From nobody Wed Jan 7 02:04:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6470F1A899D for ; Wed, 7 Jan 2015 02:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3] 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 wRrNmOYBU6nB for ; Wed, 7 Jan 2015 02:04:39 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0EE1A8990 for ; Wed, 7 Jan 2015 02:04:38 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3DBF01CC003E; Wed, 7 Jan 2015 11:04:43 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20150106.223449.1160000230471393141.mbj@tail-f.com> References: <838CEF6F-0AB8-49CA-A466-EC9FB50B18F2@nic.cz> <20150106.223449.1160000230471393141.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: Wed, 07 Jan 2015 11:04:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/O765rBt1CEGjyzUrNf9PbdAzrV4 Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF #15: usage of groupings X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 10:04:41 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >>=20 >> > On 06 Jan 2015, at 15:54, Andy Bierman wrote: > > [...] > >> > I completely agree that YANG is being used here in a manner different >> > than NETCONF. >> > YANG does not even completely work for RESTCONF, let alone resource >> > abstractions or a new datastore for I2RS. >> >=20 >> > We are using YANG as a low-level info model here. >> > We do not want to tightly couple the protocol messages to a specific >> > syntax. >> > IMO this is a big weakness with NETCONF and YANG. >> > The message encoding could be XML, JSON, CBOR, EXI, who cares. >> > But YANG is tightly coupled to NETCONF and XML and that isn't >> > changing in YANG 1.1. >>=20 >> I have supported, actually proposed, to make YANG into a more general >> schema language by removing the dependence on NETCONF (and XML) > > I agree, to some extent. I also think that a core statement > "structure" would be the best solution. Meanwhile, in YANG 1.0, an > extension like the one proposed is the best way to solve this. Well, it's not proposed for YANG 1.1 either, and everything else sounds like "when pigs fly" to me. Or could we perhaps consider it for inclusion in YANG 1.1? Actually, there is another possible solution, namely to use XSD or RELAX=C2=A0NG for XML and draft-newton-json-content-rules-04 for JSON. It is true that the latter is still in an early stage but its acceptance in the JSON WG was positive and that WG seems to act fast. Lada > >> but I >> believe this has to be done by rewriting the spec, and not by bending >> it via extension hacks. > > > /martin --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 8 03:19:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0A81ACD10 for ; Thu, 8 Jan 2015 03:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, 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 2OFmKhWlJiYT for ; Thu, 8 Jan 2015 03:19: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 BF3251A89B3 for ; Thu, 8 Jan 2015 03:19:14 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7ED42AC8; Thu, 8 Jan 2015 12:19: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 pLwlIh0b_vNn; Thu, 8 Jan 2015 12:19:12 +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, 8 Jan 2015 12:19:12 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC0182002C; Thu, 8 Jan 2015 12:19:12 +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 Kf5a4yqQAb1p; Thu, 8 Jan 2015 12:19: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 DE71120017; Thu, 8 Jan 2015 12:19:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C159B3051BC5; Thu, 8 Jan 2015 12:19:13 +0100 (CET) Date: Thu, 8 Jan 2015 12:19:13 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20150108111913.GC15995@elstar.local> Mail-Followup-To: netconf@ietf.org, netconf-chairs@tools.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: Cc: netconf-chairs@tools.ietf.org Subject: [Netconf] NACM update for YANG 1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 11:19:17 -0000 Hi, the YANG 1.1 work going on in NETMOD has two issues that interact with the NETCONF access control model (NACM) defined in RFC 6536. YANG 1.1 issue Y58 provides a mechanism to associate an action with a data node. (Similarily, Y36 provides a mechanism to associate a notification with a data node.) To fully support Y58 (and perhaps Y36), a minor modification of NACM would be needed so that access control rights can be associated with actions. The change is expected to be minor and the editors of RFC 6536 indicated to be willing to do the work. The question now is if NETCONF is willing to do this update if say Y58 makes it into YANG 1.1. (While there seems to be good support for Y58, some people raised a concern that we should not have an incomplete solution where standard access control cannot be configured for actions.) The YANG 1.1 issues list can be found 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 Thu Jan 8 07:20:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381E31A8A98 for ; Thu, 8 Jan 2015 07:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 tAQoZATAj9PY for ; Thu, 8 Jan 2015 07:20:34 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D0D1A6EE0 for ; Thu, 8 Jan 2015 07:20:34 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t08FKVh8025578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Jan 2015 15:20:31 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t08FKTJY019224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Jan 2015 16:20:29 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 16:20:28 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Juergen Schoenwaelder Thread-Topic: NACM update for YANG 1.1 Thread-Index: AQHQKzTzhq9fIUxwc0CzTJeRgNhTopy2VEcw Date: Thu, 8 Jan 2015 15:20:28 +0000 Message-ID: References: <20150108111913.GC15995@elstar.local> In-Reply-To: <20150108111913.GC15995@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1748 X-purgate-ID: 151667::1420730431-00001177-B9CB8A9A/0/0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] NACM update for YANG 1.1 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:20:37 -0000 Hi Juergen, thanks for sharing the issue description and the background. I personally believe we should extend RFC 6536 to support the usage of acti= ons. @All: Please comment by January 22, 2015, whether you have any objections t= o addressing the issue with a rfc6536bis document. Regards, Mehmet=20 -----Original Message----- From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Thursday, January 08, 2015 12:19 PM To: netconf@ietf.org Cc: netconf-chairs@tools.ietf.org Subject: NACM update for YANG 1.1 Hi, the YANG 1.1 work going on in NETMOD has two issues that interact with the NETCONF access control model (NACM) defined in RFC 6536. YANG 1.1 issue Y58 provides a mechanism to associate an action with a data node. (Similarily, Y36 provides a mechanism to associate a notification with a data node.) To fully support Y58 (and perhaps Y36), a minor modification of NACM would be needed so that access control rights can be associated with actions. The change is expected to be minor and the editors of RFC 6536 indicated to be willing to do the work. The question now is if NETCONF is willing to do this update if say Y58 makes it into YANG 1.1. (While there seems to be good support for Y58, some people raised a concern that we should not have an incomplete solution where standard access control cannot be configured for actions.) The YANG 1.1 issues list can be found here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jan 8 10:30:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691291A0039 for ; Thu, 8 Jan 2015 10:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 D04lnhnq7EFe for ; Thu, 8 Jan 2015 10:30:19 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B1D1A004B for ; Thu, 8 Jan 2015 10:30:18 -0800 (PST) Received: by mail-oi0-f50.google.com with SMTP id x69so8595631oia.9 for ; Thu, 08 Jan 2015 10:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=RfwiQ+d6+fFd4fFLqbuA10eYsmuw+gSDoeWla7JhADc=; b=ij2ZovVZ1NHtYdAIXPIUqnu2e6i6LqDI7Rs/4XEElq2WCYfcQFJ7GMBZN7QHJ3DXO3 ShPM06HJM4ZLLtw5q99h9VyfujiN7k0UbLHQR0Nzs1okAKq8lffkAgTNlqCrEdSdFMmz COuSmZcshGQnr4TYYzbIShnGKOmvUe+aA+16jZncrl+atHQBKRKpyKEaaUsDQ2VvF3ZN zP9JS4s7rJO4q/Mw3M/8XtM9LIDCgpy8Jsl3rQ4nuFJe5WmISzhh8CMUZ0rGANhQTpRz 81tF0Zzl7vClkEDqgyof+BOn/t+cNx10tuFtaJm7ZBwUrC2xQThSnr3hi8j87l0LdI2X c5RQ== X-Received: by 10.202.199.80 with SMTP id x77mr6240563oif.12.1420741818045; Thu, 08 Jan 2015 10:30:18 -0800 (PST) MIME-Version: 1.0 From: Mahesh Jethanandani Date: Thu, 08 Jan 2015 18:30:17 +0000 Message-ID: To: Netconf Content-Type: multipart/mixed; boundary=001a1134f5a861f34b050c283b80 Archived-At: Subject: [Netconf] Minutes from the NETCONF Interim Meeting on January 5th, 2015 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 18:30:21 -0000 --001a1134f5a861f34b050c283b80 Content-Type: multipart/alternative; boundary=001a1134f5a861f345050c283b7e --001a1134f5a861f345050c283b7e Content-Type: text/plain; charset=UTF-8 are attached. Please provide any comments/corrections by end of next week. --001a1134f5a861f345050c283b7e Content-Type: text/html; charset=UTF-8 are attached. Please provide any comments/corrections by end of next week. --001a1134f5a861f345050c283b7e-- --001a1134f5a861f34b050c283b80 Content-Type: text/plain; charset=US-ASCII; name="Netconf virtual meeting January 5 2014.txt" Content-Disposition: attachment; filename="Netconf virtual meeting January 5 2014.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: 14acacef4a0f058639d TWludXRlcyBvZiB0aGUgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgb24gRGVjZW1iZXIgMTUsMjAx NCAxNzAwLTE5MDAgVVRDDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkF0dGVuZGVl czoNCiAgICAgICAgTWVobWV0IEVyc3VlDQogICAgICAgIE1haGVzaCBKZXRoYW5hbmRhbmkNCiAg ICAgICAgQW5keSBCaWVybWFuDQogICAgICAgIEtlbnQgV2F0c2VuDQogICAgICAgIFN1c2FuIEhh cmVzDQogICAgICAgIEhhbm5lcyBUc2Nob2ZlbmlnDQogICAgICAgIEp1ZXJnZW4gU2Nob2VuZmVs ZGVyDQogICAgICAgIEFsYW4gTHVjaHVrDQogICAgICAgIFJlaW5hbGRvIFBlbm5vDQoNCkFnZW5k YSBpcyBhdmFpbGFibGUgYXQ6IA0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRl cmltLzIwMTUvMDEvMDUvbmV0Y29uZi9hZ2VuZGEvYWdlbmRhLWludGVyaW0tMjAxNS1uZXRjb25m LTENCiANCi0gNSBtaW4gY2hhaXIgaW50cm8sIHNjcmliZSwgYWdlbmRhIGJhc2hpbmcNCiAgVGhl IG5vdGVzIHdpbGwgYmV0YUtlbnQgb246IGh0dHA6Ly9iZXRhLmV0aGVycGFkLm9yZy9wL25ldGNv bmYtSmFuMDUgIA0KIA0KSXNzdWUgZGlzY3Vzc2lvbiBwZXIgV0cgaXRlbToNCiANCi0gQ2FsbCBI b21lIChLZW50KSAoMTBtaW4pDQogIEN1cnJlbnRseSAzIG9wZW5pc3N1ZXMuDQogIFNlZSBodHRw czovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9jYWxsLWhvbWUvaXNzdWVzICANCg0KICAgIE5vdGVz IGR1cmluZyB0aGUgZGlzY3Vzc2lvbjogDQogICAgbm8gY29uc2Vuc3VzIG9uIHNwbGl0dGluZyB0 aGUgZHJhZnQgaW50byB0d28gZHJhZnRzLiANCiAgICBCZXR0ZXIgcmVhZGFiaWxpdHkgY2FuIGJl IGFjaGlldmVkIGJ5OiANCiAgICAtIGJyZWFrIFJFU1RDT05GIG9yIE5FVENPTkYgaW50byBkaWZm ZXJlbnQgc2VjdGlvbnMuIA0KICAgIC0gYW5vdGhlciB3YXkgaXMgdGhhdCB0aGlzIHNlY3Rpb24g Y291bGQgYmUgIGJyb0tlbnQgb3V0IGJ5IHRyYW5zcG9ydCBzZWN0aW9ucy4gDQogICAgSG93ZXZl ciwgdGhlc2Ugc2VjdGlvbnMgYXJlIGhpZ2hseSBzaGFyZWQgLSBzbyB0aGlzIHdvdWxkIHNvbHZl IHRoZSBpc3N1ZS4gDQoNCiAgICBBbmR5OiBJIGRvIG5vdCBzZWUgd2h5IHRoZXNlIHNob3VsZCBi ZSBicm9LZW50IGludG8gdHdvIHNlbnRlbmNlcyBpbiB0aGlzIHNlY3Rpb24uIA0KICAgIEtlbnQ6 ICBEbyB5b3UgbWVhbiB0d28gc2VudGVuY2VzLiANCiAgICBNZWhtZXQ6IFRoZSBmb3VyIGJ1bGxl dHMgYXJlIHN0ZXBzLiAgWW91IGNhbiBub3QgYWRkIGJ1bGxldHMsIGJ1dCB5b3UgY291bGQgaGF2 ZSBzdWItYnVsbGV0cy4gDQogICAgS2VudDogSSBjYW4gdHJ5IGl0LiANCiAgICBNZWhtZXQ6IFlv dSBkbyBub3Qgc2VlbSBjb252aW5jZWQuICBTaG91bGQgd2UgaGF2ZSBpdCBvbiB0aGUgbWFpbCBs aXN0PyANCiAgICBLZW50OiBJIGFncmVlIHRoYXQgaXQgbmVlZHMgdG8gYmUgdGhlIGNvbXBsZXRl IGRvY3VtZW50LiANCiAgICBBbmR5OiBUaGlzIHNvbHV0aW9uIG1ha2VzIHNlbnNlIHRvIG1lLiBS ZWFkYWJpbGl0eSBpcyBzdWJqZWN0aXZlLg0KICAgIEhhbm5lczogcmVhZGFiaWxpdHkgaXMgaW1w b3J0YW50LiAgDQogICAgTWVobWV0OiBMZXQncyBnbyBmb3IgdGhpcyBzb2x1dGlvbi4gDQoNCiAN Ci0gU2VydmVyIE1vZGVsIChLZW50KSAoMjBtaW4pDQogIEN1cnJlbnRseSA0IG9wZW5pc3N1ZXMu DQogIFNlZSBodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9zZXJ2ZXItbW9kZWwvaXNzdWVz DQogIE5vdGVzOg0KDQogICAgS2VudDogIFdHIGNvbnNlbnN1cyAibm90IGdyYW50ZWQiIG9uIHRo ZSBpc3N1ZSAyMS4gUmVzb2x1dGlvbiBpcyB0byBub3QgaGF2ZSBhIGZlYXR1cmUgc3RhdGVtZW50 LiBhcm91bmQgdGhlIHNlc3Npb24gb3B0aW9ucyBub2RlLiAgKCANCiAgICBNZWhtZXQ6IGNhbiB5 b3UgZ2l2ZSB1cyBhbiB1cGRhdGUgb24gaXNzdWVzIDE4IGFuZCBpc3N1ZXMgMjQuIA0KICAgIEtl bnQ6ICBIYW5uZXMgVHNjaG9mZW5pZyBhZ3JlZWQgY2xpaWVudC10cnVzdC1jZXJ0IGFyZSBwYXNz d29yZCwgYW5kIGhlbmNlIHRoZXkgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgdGhlIHNhbWUuICBUaGUg cGxhbiBpcyB0byBhZGQgTkFDTSBhdHRyaWJ1dGUgdG8gdGhlIHlhbmcgbW9kZWwgZm9yIHRoZSBj bGllbnQtdHJ1c3QtY2VydCBub2RlIGluZGljYXRpbmcgdGhhdCBpdCBzaG91bGQgb25seSBiZSB3 cml0dGVuIGJ5IHBlcm1pdHRlZCB1c2Vycy4gIFNpbWlpbGFyIHVwZGF0ZXMgdG8gYmUgbWFkZSB0 byBpbmRpY2F0ZSB0aGlzIGluIHRoZSBzZWN1cml0eSBzZWN0aW9uLiANCiAgICBNZWhtZXQ6IFNo b3VsZCB3ZSBzZW5kIGEgc29sdXRpb24gdG8gdGhlIG1haWwgbGlzdD8gIFdlIGNhbiBoYXZlIGEg MSB3ZWVrIGRlYWRsaW5lICgxLzEyLzIwMTUpLiANCiAgICBLZW50IG5lZWRzIHRvIHVwZGF0ZSB0 aGUgU2VydmVyIE1vZGVsIGRyYWZ0IGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gdG8gbWFrZSBp dCBjb25zaXN0ZW50LiBLZW50IHdpbGwgb3BlbiBhIG5ldyBpc3N1ZSBmb3IgaXQgaW4gR0guDQoN Cg0KLSBaZXJvdG91Y2ggKEtlbnQpICgzMG1pbikNCiAgQ3VycmVudGx5IDIgb3Blbmlzc3Vlcy4N CiAgU2VlIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91Y2gvaXNzdWVzDQoN CiAgICBpc3N1ZSA1OiBWYWxpZGF0ZSBpZiB2ZW5kb3JzIGNhbiBzdXBwb3J0IG93bmVyLXZhbGlk YXRpb24gc2VydmljZSAoZnJvbSBhbmltYSBXRykNCiAgICBLZW50IHdpbGwgc2VuZCBhIHJlcXVl c3QgdG8gdGhlIG1haWwgbGlzdC4gIA0KICAgIE1laG1ldDogV2h5IGFyZSB3ZSBub3QgdXNpbmcg WWFuZyBpbnN0ZWFkIG9mICBYU0QgZGF0YW1vZGVsPyANCiAgICBLZW50OiBUaGUgaW50ZXJlc3Rp bmcgdGhpbmcgd2FzIHdlIHdlcmUgdXNpbmcgeWFuZywgYW5kIHdlIHVzZWQgWFNEIHRvIGFzc2Vy dCB0aGUgdXNlIG9mIFhNTCBidXQgYWxzbyBiZWNhdXNlIGEgZ3JvdXBpbmcgY29uZmlnbGV0IHdv dWxkIGNyZWF0ZSBhIHRvcC1sZXZlbCBtYW5kYXRvcnkgbm9kZS4NCg0KICAgIFlBTkcgaXMgYWJv dXQgY29uZmlndXJhdGlvbiBhbmQgbm9uLWNvbmZpZ3VyYXRpb24gZGVmaW5pdGlvbi4gQSBjb25m aWctbGV0IGlzIG5vdCBhIGNvbmZpZ3VyYXRpb24uIEl0IGlzIGEgSFRUUCBmaWxlIGRvd25sb2Fk ZWQgYnkgdGhlIGRldmljZS4gVGhlIGRhdGEgaXMgWE1MLg0KDQogICAgSGFubmVzOiBUaGVyZSBp cyBubyByZXF1aXJlbWVudCB0byB1c2UgYSBzY2hlbWEgbGFuZ2F1Z2UuICANCiAgICBLZW50OiBU aGlzIGNvdWxkIGJlIGRlZmluZWQgaW4gWWFuZyBhbmQgdGhlIGluc3RhbmNlIGRvY3VtZW50IHdv dWxkIGJlIFhNTC4NCiAgICBBbGFuIEx1Y2h1ayBhZ3JlZXMgd2l0aCB0aGUgcmVhc29uIGZvciBr ZWVwaW5nIHRoZSBjb25maWctbGV0IGluIFhTRCBmb3JtYXQuDQogICAgVGhlcmUgaXMgYWxzbyBh biBpc3N1ZSB3aXRoIFhNTCBzaWduaW5nIGFuZCBlbmNyeXB0aW9uIGZvciB0aGUgY29uZmlnLWxl dC4gWE1MIHNpZ25pbmcgYW5kIGVuY3J5cHRpb24gaXMgbm90IHdpZGVseSBhZG9wdGVkLiBMb29r aW5nIGZvciBhIHNpbXBsZXIgc29sdXRpb24uIA0KICAgIEhhbm5lcyBzdWdnZXN0ZWQgdXNpbmcg dHJhbnNwb3J0IGxheWVyIHNlY3VyaXR5LiAgDQoNCiANCi0gcmZjNTUzOWJpcyAoSnVlcmdlbikg KDVtaW4pDQogIE5vIG9wZW4gaXNzdWVzLg0KICBUaGVyZSB3YXMgYSBzaG9ydCBkaXNjdXNzaW9u IG9uIHN0YXJ0aW5nIFdHTEMgZm9yIGNhbGwtaG9tZSwgc2VydmVyLW1vZGVsIGFuZCA1NTM5Ymlz IHRvZ2V0aGVyLg0KICBKdWVyZ2VuIHNheXMgdGhhdCB0aGlzIGRvY3VtZW50IG1ha2VzIG5vIG5v cm1hdGl2ZSByZWZlcmVuY2UgdG8gc2VydmVyIG1vZGVsIGFueW1vcmUsIHNvIDU1MzliaXMgaXMg aW5kZXBlbmRlbnQgb2YgdGhlIG90aGVyIHR3by4NCiAgTWVobWV0IHN1Z2dlc3RlZCB0aGF0IHdl IHN0YXJ0IFdHTEMgb24gdGhlIGRvY3VtZW50IGFzYXAuIEFJIGZvciBNZWhtZXQuDQoNCiANCi0g UmVzdGNvbmYvWUFORyBQYXRjaCAoQW5keSkgKDQwbWluKQ0KICBDdXJyZW50bHkgOS8yb3BlbiBp c3N1ZXMuDQogIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3Jlc3Rjb25mL2lzc3VlcyAg IA0KICBodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLXBhdGNoL2lzc3Vlcw0KDQpS RVNUQ09ORiBJc3N1ZSMxNS4gQW5keSBoYXMgYWxyZWFkeSBwb3N0ZWQgdGhlIHByb3Bvc2FsIChT Mi1CKSBvbiB0aGUgTUwgTGFkYSBvYmplY3RlZCwgYnV0IGhhcyBub3QgcHJvdmlkZWQgY2xhcmlm aWNhdGlvbi4gS2VudCBwcmVmZXJzIG1hY2hpbmUgcmVhZGFibGUsIHNvIGhlIGRvZXMgbm90IGxp a2UgUzMuIEhlIHByZWZlcnMgUzItQSBvciBTMi1CLiBXaGF0ZXZlciBzb2x1dGlvbiBpcyBwcmVm ZXJyZWQgaGVyZSBjYW4gdGhlbiBiZSBhcHBsaWVkIHRvIGNvbmZsaWctbGV0IGlzc3VlIGluIFpl cm9Ub3VjaC4NCkhhbm5lcyBoYXMgYSBwcm9ibGVtIHdpdGggZGVmaW5pbmcgcHJvdG9jb2wgb3Bl cmF0aW9ucyB1c2luZyBhIFhNTCBzY2hlbWEuIA0KS2VudCBzdXJwaXNlZCBieSBIYW5uZXMgb2Jq ZWN0aW9uLiBJRVRGIGhhcyBhIGxvbmcgdHJhZGl0aW9uIG9mIHVzaW5nIEFCTiBmb3JtYXQuDQpB bmR5IGFncmVlcyB0aGF0IHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBpcyBub3QgaHVtYW4gcmVhZGFi bGUgZm9ybWF0IGFuZCBhdCBiZXN0IGlzIHRoZSB3b3JrIGFyb3VuZCB0byB0aGUgbGltaXRhdGlv bi4NCkFuZHkgbmVlZHMgdGltZSB0byB1cGRhdGUgdGhlIGRyYWZ0LiBIZSBjYW4gZG8gaXQgZm9y IG5leHQgTW9uZGF5Lg0KDQpZYW5nIHBhdGNoIGlzIGFscmVhZHkgdXBkYXRlZC4gDQpJc3N1ZSAj MiBpbiB5YW5nIHBhdGNoIGlzIGFuIGltcGxlbWVudGF0aW9uIGlzc3VlLg0KDQpLZW50IHdhbnRz IG1vcmUgZGlzY3Vzc2lvbiBhcm91bmQgaXNzdWUgIzkgb2YgUkVTVENPTkYuIFBlciB0aGUgbm90 ZXMgaW4gR0gsIEJhc2lzQXV0aCBuZWVkcyB0byBiZSBzdXBwb3J0ZWQuIFNlcnZlciBuZWVkcyB0 byBzdXBwb3J0IGEgc21hbGwgbnVtYmVyIG9mIGNsaWVudCAocGFzc3dvcmQgYW5kIGNsaWVudC1h dXRoKSBhdXRoZW50aWNhdGlvbi5TZXJ2ZXIgbmVlZHMgdG8gc3VwcG9ydCBhdCBsZWFzdCBvbmUg b2YgcGFzc3dvcmQsIGRpZ2VzdCBhbmQgY2xpZW50LWF1dGguIEFuZHkgaGFzIG5vIG9iamVjdGlv biB0byB0aGUgcHJvcG9zZWQgc29sdXRpb24uIEN1cnJlbnRseSwgYXMgd3JpdHRlbiwgdGhlIGRy YWZ0IHNheXMgQmFzaWNBdXRoIGhhcyB0byBiZSBzdXBwb3J0ZWQuIFRoYXQgYWNjb3JkaW5nIHRv IEtlbnQgaXMgbm90IHJlYWxpc3RpYy4gUGFzc3dvcmRzIGFyZSBpbmhlcmVudGx5IGxlc3Mgc2Vj dXJlLiBJdCBhbHNvIHJlcXVpcmVzIGFsbCBzZXJ2ZXIgdG8gc3VwcG9ydCBCYXNpY0F1dGguIEp1 ZXJnZW4gY29tbWVudHMgdGhhdCBmb3IgaW50ZXJvcGVyYWJpbGl0eSwgeW91IG5lZWQgYSBjb21t b24gYmFzZWxpbmUuIEVpdGhlciBvciBpcyBicm9rZW4gZm9yIGludGVyb3BlcmFiaWxpdHkuIEhl IHN1Z2dlc3RzIHRoYXQgY2hvaWNlIG9mIGF1dGggaXMgYSBkZXBsb3ltZW50IHBvbGljeSBhbmQg c2hvdWxkIG5vdCBiZSBoYXJkIGNvZGVkLiANCk1laG1ldCBzdWdnZXN0cyB0byBzdGFydCBMQyBv biBSRVNUQ09ORiBhbmQgeWFuZy1wYXRjaCBuZXh0IE1vbmRheSB3aXRoIHRoaXMgaXNzdWUgb3Bl biBmb3IgZGlzY3Vzc2lvbi4gS2VudCBjYW4gYnJpbmcgdGhlIGlzc3VlIHRvIHRoZSBtYWlsbGlz dC4gDQogDQoNCiANCi0gNSBtaW4gQU9CIG90aGVyIHRvcGljcw0KU3VzYW4gSGFyZXMgd2lsbCBw cm92aWRlIGFuIHVwZGF0ZS4gVGhlIGkycnMgaW50ZXJpbSBtZWV0aW5nIGhhZCBhIGRpc2N1c3Np b24gYXJvdW5kIHRoZSBSSUIgbW9kZWwgYW5kIHdoYXQgTkVUQ09ORiBuZWVkcyB0byBwcm92aWRl LiBTdXNhbiB3aWxsIGhhdmUgYSBkaXNjdXNzaW9uIHdpdGggSmVmZiBhbmQgcG9zdCB0aGUgcXVl c3Rpb25zIHRoZSBncm91cCBoYXMgdG8gdGhlIE1MLg0KDQpNRTogVGhlIG5leHQgbWVldGluZyBp cyBvbiAyMDE1LTAxLTE5IDE3MDAgVVRDLg0KV2Ugd2lsbCBwbGFuIGEgSTJSUyBzbG90IGZvciBk aXNjdXNzaW9uIHdpdGggSmVmZiBIYWFzIGFuZCBvdGhlcnMuDQoNCiAgIA== --001a1134f5a861f34b050c283b80-- From nobody Sun Jan 11 08:44:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184AE1A702B for ; Sun, 11 Jan 2015 08:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 H8SQxjtCiuXy for ; Sun, 11 Jan 2015 08:44:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D4B1A7029 for ; Sun, 11 Jan 2015 08:44:08 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t0BGi5mW032542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Jan 2015 16:44:06 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0BGi5vI028909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 11 Jan 2015 17:44:05 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0195.001; Sun, 11 Jan 2015 17:44:05 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: [Netconf] Minutes from the NETCONF Interim Meeting on January 5th, 2015 Thread-Index: AQHQK3EsPVSTRNxhCUehLNZt0iaaDZy6ugTA Date: Sun, 11 Jan 2015 16:44:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.158] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8195AD978DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 37986 X-purgate-ID: 151667::1420994646-00001177-12159B14/0/0 Archived-At: Subject: Re: [Netconf] Minutes from the NETCONF Interim Meeting on January 5th, 2015 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 16:44:12 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195AD978DEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQp0aGUgcmVzdWx0IG9mIHRoZSBpc3N1ZSBkaXNjdXNzaW9uIGluIHRoZSBWTSBoYXMg YmVlbiBlbnRlcmVkIGludG8gdGhlIEdpdGh1Yi4NClBsZWFzZSByZXZpZXcgdGhlIHN0YXR1cyBv ZiB0aGUgaXNzdWVzIGluIEdpdGh1Yi4gSWYgdGhlcmUgaXMgbm8gb2JqZWN0aW9uIHRvIHRoZSBj b25jbHVzaW9ucywgdGhlIGRyYWZ0IGF1dGhvcnMgYXJlIGdvaW5nIHRvIGFjdCBhcyBhZ3JlZWQu DQoNCk5FVENPTkYgR2l0aHViIGlzIGF2YWlsYWJsZSBhdDogaHR0cHM6Ly9naXRodWIuY29tL25l dGNvbmYtd2cvDQoNClRoZSBWTSBtaW51dGVzIGFyZSBhbHNvIGF2YWlsYWJsZSBhdDogaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9zZWNyL3Byb2NlZWRpbmdzL2ludGVyaW0tMjAxNS1uZXRj b25mLTEvbmV0Y29uZi8NCg0KUmVnYXJkcywNCk1laG1ldA0KDQpGcm9tOiBOZXRjb25mIFttYWls dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IE1haGVzaCBKZXRo YW5hbmRhbmkNClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDA4LCAyMDE1IDc6MzAgUE0NClRvOiBO ZXRjb25mDQpTdWJqZWN0OiBbTmV0Y29uZl0gTWludXRlcyBmcm9tIHRoZSBORVRDT05GIEludGVy aW0gTWVldGluZyBvbiBKYW51YXJ5IDV0aCwgMjAxNQ0KDQphcmUgYXR0YWNoZWQuIFBsZWFzZSBw cm92aWRlIGFueSBjb21tZW50cy9jb3JyZWN0aW9ucyBieSBlbmQgb2YgbmV4dCB3ZWVrLg0K --_000_E4DE949E6CE3E34993A2FF8AE79131F8195AD978DEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDAyREM2LjMwRjZDRTgwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8bzpUYXJnZXRTY3JlZW5TaXplPjEwMjR4NzY4PC9vOlRhcmdldFNjcmVlblNpemU+DQo8L286 T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpT cGVsbGluZ1N0YXRlPg0KPHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6 RW52ZWxvcGVWaXMvPg0KPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJ bnZhbGlkPmZhbHNlPC93OlNhdmVJZlhNTEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYv Pg0KPHc6TGlkVGhlbWVPdGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVB c2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5Y LU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRv Tm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNuYXBU b0dyaWRJbkNlbGwvPg0KPHc6V3JhcFRleHRXaXRoUHVuY3QvPg0KPHc6VXNlQXNpYW5CcmVha1J1 bGVzLz4NCjx3OkRvbnRHcm93QXV0b2ZpdC8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+ DQo8dzpEb250VmVydEFsaWduQ2VsbFdpdGhTcC8+DQo8dzpEb250QnJlYWtDb25zdHJhaW5lZEZv cmNlZFRhYmxlcy8+DQo8dzpEb250VmVydEFsaWduSW5UeGJ4Lz4NCjx3OldvcmQxMUtlcm5pbmdQ YWlycy8+DQo8dzpDYWNoZWRDb2xCYWxhbmNlLz4NCjwvdzpDb21wYXRpYmlsaXR5Pg0KPHc6QnJv d3NlckxldmVsPk1pY3Jvc29mdEludGVybmV0RXhwbG9yZXI0PC93OkJyb3dzZXJMZXZlbD4NCjxt Om1hdGhQcj4NCjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBt OnZhbD0iYmVmb3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxG cmFjIG06dmFsPSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0K PG06ck1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8 bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0K PG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0 eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBEZWZT ZW1pSGlkZGVuPSJ0cnVlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5IiBMYXRl bnRTdHlsZUNvdW50PSIyNjciPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJoZWFkaW5nIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcg NSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9 ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5 IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIE5hbWU9IkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTEiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1 YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjU5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNpbmciLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmciLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRh cmsgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwg U2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwg TGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3Jp ZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlz dCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg R3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIFNoYWRpbmcgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iUmV2aXNpb24iLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzQiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ikxpc3Qg UGFyYWdyYXBoIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjI5 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2Vu dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0 IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcz IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJM aWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFj Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFk aW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2Nl bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3Jp ZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg U2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBB Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFy ayBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAy IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRp bmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ikxp Z2h0IEdyaWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDYiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMg QWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlz dCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIxOSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIEVtcGhh c2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMxIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjMyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgTmFtZT0iQmlibGlvZ3JhcGh5Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBRRm9ybWF0PSJ0 cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KPC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7DQoJbXNvLWZvbnQtYWx0OiJDYWxpc3RvIE1UIjsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJ bXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7 DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTEwNzMwNTcyNyAwIDAgNDE1IDA7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0Ow0KCW1zby1mb250LWFsdDoiQXJpYWwgUm91bmRlZCBNVCBCb2xkIjsNCgltc28t Zm9udC1jaGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZv bnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MzY4NzAxNDUgMTA3Mzc4 NjExMSAxIDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtYWx0OlZlcmRhbmE7DQoJbXNv LWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1m b250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTIwMDgxNjY1IC0xMDcz NzE3MTU3IDQxIDAgNjYwNDcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtYWx0OlZlcmRhbmE7 DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0K CW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotMTU5MzgzMzcy OSAxMDczNzUwMTA3IDE2IDAgNDE1IDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxlLXVuaGlkZTpu bzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1v cnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93 LW9ycGhhbjsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hv dzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJz YW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6VmVyZGFuYTsNCgltc28taGFuc2kt Zm9udC1mYW1pbHk6VmVyZGFuYTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjsNCgljb2xvcjojMDAwMENDO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxv Y2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjguMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OlRhaG9tYTsNCglt c28taGFuc2ktZm9udC1mYW1pbHk6VGFob21hOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OlRhaG9t YTt9DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tc3BsLWU6eWVzO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZh dWx0LXByb3BzOnllczsNCglmb250LXNpemU6MTAuMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYXNjaWktZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5z aS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0Ow0KCW1zby1oZWFkZXItbWFyZ2luOjM2 LjBwdDsNCgltc28tZm9vdGVyLW1hcmdpbjozNi4wcHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNv Tm9ybWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHls ZS1yb3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHls ZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtcWZvcm1h dDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGNtIDUuNHB0 IDBjbSA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpO30NCjwv c3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIiBzdHlsZT0idGFiLWludGVydmFsOjM2LjBwdCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiMwMDAw Y2MiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMDAwMENDIj5B bGwsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjEiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDs7Y29sb3I6IzAwMDBDQyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjEiIGNvbG9yPSIjMDAwMGNjIiBm YWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzAwMDBDQyI+dGhlIHJl c3VsdCBvZiB0aGUgaXNzdWUgZGlzY3Vzc2lvbiBpbiB0aGUgVk0gaGFzIGJlZW4gZW50ZXJlZCBp bnRvIHRoZQ0KPHNwYW4gY2xhc3M9IlNwZWxsRSI+R2l0aHViPC9zcGFuPi48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMSIgY29s b3I9IiMwMDAwY2MiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjoj MDAwMENDIj5QbGVhc2UgcmV2aWV3IHRoZSBzdGF0dXMgb2YgdGhlIGlzc3VlcyBpbg0KPHNwYW4g Y2xhc3M9IlNwZWxsRSI+R2l0aHViPC9zcGFuPi4gSWYgdGhlcmUgaXMgbm8gb2JqZWN0aW9uIHRv IHRoZSBjb25jbHVzaW9ucywgdGhlIGRyYWZ0IGF1dGhvcnMgYXJlIGdvaW5nIHRvIGFjdCBhcyBh Z3JlZWQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjEiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjEiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDs7Y29sb3I6IzAwMDBDQyI+TkVUQ09ORg0KPHNwYW4gY2xhc3M9IlNwZWxsRSI+R2l0 aHViPC9zcGFuPiBpcyBhdmFpbGFibGUgYXQ6IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9u ZXRjb25mLXdnLyI+DQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy88L2E+IDwvc3Bhbj48 L2ZvbnQ+PGZvbnQgc2l6ZT0iMSIgZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwY2MiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O21zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28taGFuc2ktZm9udC1m YW1pbHk6Q2FsaWJyaTtjb2xvcjojMDAwMENDIj4mbmJzcDs8L3NwYW4+PC9mb250PjxzcGFuIHN0 eWxlPSJtc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGli cmkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjEiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMDAwMENDIj5UaGUgVk0gbWludXRl cyBhcmUgYWxzbyBhdmFpbGFibGUgYXQ6DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL3NlY3IvcHJvY2VlZGluZ3MvaW50ZXJpbS0yMDE1LW5ldGNvbmYtMS9uZXRjb25mLyI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3NlY3IvcHJvY2VlZGluZ3MvaW50ZXJpbS0y MDE1LW5ldGNvbmYtMS9uZXRjb25mLzwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwMDBjYyIgZmFj ZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWJpZGktZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwMDBDQyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBm YWNlPSJWZXJkYW5hIj48c3BhbiBsYW5nPSJERSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMDAw MENDO21zby1hbnNpLWxhbmd1YWdlOkRFO21zby1uby1wcm9vZjp5ZXMiPlJlZ2FyZHMsDQo8YnI+ DQpNZWhtZXQgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDAwMGNjIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDttc28tYmlkaS1mb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAw MENDIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1vdXRsaW5lLWxldmVs OjEiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iVGFob21hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPg0KIE5ldGNvbmYgWzxhIGhyZWY9 Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPk9uIEJlaGFs ZiBPZiA8L3NwYW4+PC9iPmV4dCBNYWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gVGh1cnNkYXksIEphbnVhcnkg MDgsIDIwMTUgNzozMCBQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5U bzo8L3NwYW4+PC9iPiBOZXRjb25mPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gW05ldGNvbmZdIE1pbnV0ZXMgZnJvbSB0aGUgTkVUQ09O RiBJbnRlcmltIE1lZXRpbmcgb24gSmFudWFyeSA1dGgsIDIwMTU8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYXNjaWktZm9u dC1mYW1pbHk6Q2FsaWJyaTttc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5hcmUgYXR0YWNoZWQuIFBsZWFzZSBwcm92aWRlIGFueSBjb21tZW50cy9jb3JyZWN0aW9u cyBieSBlbmQgb2YgbmV4dCB3ZWVrLg0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E4DE949E6CE3E34993A2FF8AE79131F8195AD978DEMUMBX005nsnin_-- From nobody Sun Jan 11 08:58:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAEA1A70FD for ; Sun, 11 Jan 2015 08:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 XmnTNqPWDRqG for ; Sun, 11 Jan 2015 08:58:14 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40A1D1A7029 for ; Sun, 11 Jan 2015 08:58:14 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t0BGwARu011840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 11 Jan 2015 16:58:10 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0BGwACG011610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 11 Jan 2015 17:58:10 +0100 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 11 Jan 2015 17:58:10 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Sun, 11 Jan 2015 17:58:10 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AdApKKHQsmh1voQ5Sgudn5IwYOG+2QEX2N2g Date: Sun, 11 Jan 2015 16:58:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.158] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8195AD99FDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 39393 X-purgate-ID: 151667::1420995490-00001177-886B7C5A/0/0 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2015 16:58:17 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195AD99FDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, this is a friendly reminder on the WGLC we started on January 5th for draft= -ietf-netconf-rfc5539bis-07. Please review and send your comments to the WG mailing. If you have read the document but don't have any comments, please state whe= ther you support the publication. Thanks, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Monday, January 05, 2015 9:46 PM To: netconf@ietf.org Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Dear NETCONF Members, we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. The document can be found at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 Please review and send your comments to the WG mailing list by January 19, = 2015 EOB PT. The document is planned to publish as a standard track document. As a minimum please state that you have read/reviewed and whether you suppo= rt the publication. Please indicate also if you plan to implement or have already implementatio= n experience with the rfc5539bis draft. Thank you. Mehmet and Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F8195AD99FDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= All,

=  

= this is a friendly reminder on the WGLC we start= ed on January 5th for draft-ietf-netconf-rfc5539bis-07.=

=  

= Please review= and send your comments to the WG mailing.

= If you have read the document but don’t ha= ve any comments, please state whether you support the publication.

=  

= Thanks,
Mehmet

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Ersue, Mehm= et (NSN - DE/Munich)
Sent: Monday, January 05, 20= 15 9:46 PM
To: netconf@ietf.org
Subject: [Netconf] WG Last C= all for draft-ietf-netconf-rfc5539bis-07

 

= Dear NETCONF Members,

=  

= we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07.

=  

= The document can be found at:<= /o:p>

=  

= Please review and send your comments to the WG mailing list by January 19, 2015 EOB PT.

=  

= The document is planned to publish as a standard track document.<= /font>

= As a minimum please state that you have read/reviewed and whether you support the publication.

=  

= Please indicate also if you plan to implement or have already implementa= tion experience with the rfc5539bis draft.=  

= Thank you.=

= Mehmet and Mahesh=

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F8195AD99FDEMUMBX005nsnin_-- From nobody Tue Jan 13 18:09:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCCD1A8974; Tue, 13 Jan 2015 18:09:18 -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 I3XWuHVGt8kh; Tue, 13 Jan 2015 18:09:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 186481A8820; Tue, 13 Jan 2015 18:09:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150114020909.16027.52300.idtracker@ietfa.amsl.com> Date: Tue, 13 Jan 2015 18:09:09 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 02:09:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-03.txt Pages : 12 Date : 2015-01-13 Abstract: This document presents NETCONF Call Home and RESTCONF Call Home, which respectively enable a NETCONF/RESTCONF server to initiate a secure connection to a NETCONF/RESTCONF client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-call-home-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-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 Jan 13 18:18:10 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22701A8832 for ; Tue, 13 Jan 2015 18:18:08 -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 9zpNOmHMeihu for ; Tue, 13 Jan 2015 18:18:07 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.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 B0F881A1AA6 for ; Tue, 13 Jan 2015 18:18:06 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.53.17; Wed, 14 Jan 2015 02:18:05 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) with mapi id 15.01.0053.000; Wed, 14 Jan 2015 02:18:05 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-03.txt Thread-Index: AQHQL58jYxt7JVQsckKao2UpgQm91Jy+jZkA Date: Wed, 14 Jan 2015 02:18:04 +0000 Message-ID: References: <20150114020909.16027.52300.idtracker@ietfa.amsl.com> In-Reply-To: <20150114020909.16027.52300.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.4.4.140807 x-originating-ip: [66.129.241.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(189002)(377424004)(51704005)(199003)(377454003)(2501002)(40100003)(106356001)(106116001)(86362001)(107886001)(2351001)(110136001)(2950100001)(450100001)(19580395003)(62966003)(77156002)(1720100001)(15975445007)(19580405001)(102836002)(36756003)(92566002)(64706001)(66066001)(2900100001)(2656002)(83506001)(101416001)(50986999)(54356999)(76176999)(230783001)(99286002)(105586002)(46102003)(87936001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 14 Jan 2015 02:18:04.6451 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 02:18:08 -0000 This update has the following change log entry: o Tried to improve readability (issue #6) o Removed "FIXME" in section 1.3 (issue #7) o Added RFC Editor notes (issue #8) o Removed "TCP session" term (issue #9) o Improved language for usage of IANA-assigned ports (issue #10) Issues #6 and #9 have been moved to the "review" state. Issues 7, 8, & 10 were editorial and hence resolved. Regarding issue #6, I reworked the paragraphs in situ by teasing apart the sentences some. Hopefully it's enough. At least I'm satisfied ;) Is this draft now ready for Last Call? Kent On 1/13/15, 9:09 PM, "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 Network Configuration Working Group of >the IETF. > > Title : NETCONF Call Home and RESTCONF Call Home > Author : Kent Watsen > Filename : draft-ietf-netconf-call-home-03.txt > Pages : 12 > Date : 2015-01-13 > >Abstract: > This document presents NETCONF Call Home and RESTCONF Call Home, > which respectively enable a NETCONF/RESTCONF server to initiate a > secure connection to a NETCONF/RESTCONF client. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-call-home-03 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-call-home-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/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jan 14 09:53:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B6B1A9135 for ; Wed, 14 Jan 2015 09:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rabgkMxAjDfH for ; Wed, 14 Jan 2015 09:53:25 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76F91A90E8 for ; Wed, 14 Jan 2015 09:53:25 -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.53.17; Wed, 14 Jan 2015 17:53:24 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) with mapi id 15.01.0053.000; Wed, 14 Jan 2015 17:53:24 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: server-model #27 Thread-Index: AQHQMCL9rwy6x0lTZEOznh3dwAUkxg== Date: Wed, 14 Jan 2015 17:53:23 +0000 Message-ID: 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.241.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(164054003)(54356999)(50986999)(64706001)(16236675004)(106356001)(110136001)(101416001)(83506001)(66066001)(450100001)(19580395003)(77156002)(62966003)(2900100001)(102836002)(15975445007)(2656002)(92566002)(107886001)(36756003)(87936001)(68736005)(561944003)(551544002)(99286002)(46102003)(86362001)(105586002)(106116001)(97736003)(122556002)(19617315012)(2351001)(229853001)(2501002)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0DC174290E05kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2015 17:53:23.7120 (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: Subject: [Netconf] server-model #27 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 17:53:27 -0000 --_000_D0DC174290E05kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In last week's meeting we discussed adding to the YANG module for RESTCONF = servers (ietf-restconf-server) an ability to authenticate RESTCONF clients = using client certificates. To be clear, while the RESTCONF server MUST use TLS (HTTPS), the client MAY= authenticate using any of the mechanisms supported by the server (Basic, D= igest, ClientCertificate, etc.). Just like with NETCONF/SSH, for the Basi= c/Digest auth mechanisms, it is assumed that the server has some external d= atabase of users and passwords. Similarly, as with NETCONF/TLS, it is ass= umed that the model must provide specific configuration for authenticating = client certs and mapping a client cert to a username. This is what issue #= 27 is about. The current plan is to use the proposal described in https://github.com/net= conf-wg/server-model/issues/27. This proposal will be implemented if no o= bjections are raised this week. Thanks, Kent --_000_D0DC174290E05kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

In last week's meeting we discussed adding to the YANG module for REST= CONF servers (ietf-restconf-server) an ability to authenticate RESTCONF cli= ents using client certificates.  

To be clear, while the RESTCONF server MUST use TLS (HTTPS), the clien= t MAY authenticate using any of the mechanisms supported by the server (Bas= ic, Digest, ClientCertificate, etc.).   Just like with NETCONF/SSH, fo= r the Basic/Digest auth mechanisms, it is assumed that the server has some external database of users and passwor= ds.   Similarly, as with NETCONF/TLS, it is assumed that the model mus= t provide specific configuration for authenticating client certs and mappin= g a client cert to a username.  This is what issue #27 is about.

The current plan is to use the proposal described in https://github.com/net= conf-wg/server-model/issues/27.   This proposal will be implemente= d if no objections are raised this week.

Thanks,
Kent


--_000_D0DC174290E05kwatsenjunipernet_-- From nobody Thu Jan 15 03:14:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF1F1B2BDA for ; Thu, 15 Jan 2015 03:14:11 -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 zHe88ZVzU-Jx for ; Thu, 15 Jan 2015 03:14:09 -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 E62811B2BD4 for ; Thu, 15 Jan 2015 03:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34786; q=dns/txt; s=iport; t=1421320449; x=1422530049; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=drdctt5s8n8q0MKBGqsGWrAAUGKPwchDlVOjAu+pfRU=; b=enge+Jl5Zm4iPRVtZXJp9ET3S+G7lPUCd2kXHFNilDDW3CBG9nuonzIz iK5MqYC8FN8m3XeiSBhgBAbt4+wHeActMQIOlfLaK6xk70IGwSK7w0Q9I YOFe2w6JZ7W81q0TKNtXIquNryGpnCYfx/FIDYNmOpjNqVVBOWs/5ifjF w=; X-IronPort-AV: E=Sophos;i="5.09,403,1418083200"; d="scan'208,217";a="313296779" 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; 15 Jan 2015 11:14:07 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t0FBE3f7025091; Thu, 15 Jan 2015 11:14:06 GMT Message-ID: <54B7A0FB.9030806@cisco.com> Date: Thu, 15 Jan 2015 12:14:03 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" , NETCONF References: <543AB40B.3030708@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090307020104090802070208" Archived-At: Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 11:14:12 -0000 This is a multi-part message in MIME format. --------------090307020104090802070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Discussing this issue with Martin, there is one small addition to the previous proposed text: s/MAY be/MAY also be/ I'm inclined to Verify this errata in a week from now, if no further comment. In section 6.3: OLD: The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. NEW: The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. If any sibling nodes of a node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output. Implicitly in section 6.2.5 to delete the moved text: OLD: If any sibling nodes of the selection node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output. NEW: Regards, Benoit > > Benoit, All, > > we should add that there was no consensus on the use of more strong > formulation with SHOULD or MUST. > > Regards, > Mehmet > > *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *ext > Benoit Claise > *Sent:* Sunday, October 12, 2014 7:02 PM > *To:* Klement Sekera -X (ksekera - Pantheon Technologies SRO at > Cisco); NETCONF > *Subject:* [Netconf] [Technical Errata Reported] RFC6241 (3980) > > Dear all, > > I would like to close the errata 3980, > http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3980 > Mehmet summarized the situation below. (Thanks Mehmet) > If you have a problem with the proposal, quickly let us know (a few days) > > > Martin proposed in June to put the text into section 6.3. > Klement proposed in the mail from 19.06.2014 following change: > > In section 6.3: > > OLD: > > The algorithm continues until all sibling sets in all subtrees specified > in the filter have been processed. > > NEW: > > The algorithm continues until all sibling sets in all subtrees specified > in the filter have been processed. If any sibling nodes of a node > are instance identifier components for a conceptual data structure > (e.g., list key leaf), then they MAY be included in the filter output. > > Implicitly in section 6.2.5 to delete the moved text: > > OLD: > > If any sibling nodes of the selection node are instance identifier > components for a conceptual data structure (e.g., list key leaf), > then they MAY also be included in the filter output. > > NEW: > > > > Regards, Mehmet and Benoit > --------------090307020104090802070208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Discussing this issue with Martin, there is one small addition to the previous proposed text:
    s/MAY be/MAY also be/
I'm inclined to Verify this errata in a week from now, if no further comment.

In section 6.3:

OLD:

  The algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed.
NEW:

   The algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed. If any sibling nodes of a node
   are instance identifier components for a conceptual data structure
   (e.g., list key leaf), then they MAY also be included in the filter output.

Implicitly in section 6.2.5 to delete the moved text:

OLD:

   If any sibling nodes of the selection node are instance identifier
   components for a conceptual data structure (e.g., list key leaf),
   then they MAY also be included in the filter output.

NEW:
   <void>

Regards, Benoit

Benoit, All,

 

we should add that there was no consensus on the use of more strong formulation with SHOULD or MUST.

 

Regards,
Mehmet

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Benoit Claise
Sent: Sunday, October 12, 2014 7:02 PM
To: Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco); NETCONF
Subject: [Netconf] [Technical Errata Reported] RFC6241 (3980)

 

Dear all,

I would like to close the errata 3980, http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3980
Mehmet summarized the situation below. (Thanks Mehmet)
If you have a problem with the proposal, quickly let us know (a few days)


Martin proposed in June to put the text into section 6.3.
Klement proposed in the mail from 19.06.2014 following change:

In section 6.3:

OLD:

  The algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed.

NEW:

   The algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed. If any sibling nodes of a node
   are instance identifier components for a conceptual data structure
   (e.g., list key leaf), then they MAY be included in the filter output.

Implicitly in section 6.2.5 to delete the moved text:

OLD:

   If any sibling nodes of the selection node are instance identifier
   components for a conceptual data structure (e.g., list key leaf),
   then they MAY also be included in the filter output.

NEW:

   <void>

Regards, Mehmet and Benoit


--------------090307020104090802070208-- From nobody Thu Jan 15 09:02:20 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33E71B2E29 for ; Thu, 15 Jan 2015 09:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, 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 MHKLHM7AE_FN for ; Thu, 15 Jan 2015 09:02:16 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 186671B2E24 for ; Thu, 15 Jan 2015 09:02:14 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA12415; Thu, 15 Jan 2015 12:02:05 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t0FH25gA033350; Thu, 15 Jan 2015 12:02:05 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t0FH24P6033349; Thu, 15 Jan 2015 12:02:04 -0500 (EST) (envelope-from luchuk) Date: Thu, 15 Jan 2015 12:02:04 -0500 (EST) From: Alan Luchuk Message-Id: <201501151702.t0FH24P6033349@mainfs.snmp.com> To: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: [Netconf] draft-ietf-netconf-call-home-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 17:02:18 -0000 Hello, Kent, thanks for your hard work on the call home and other drafts. After carefully reading draft-ietf-netconf-call-home-03.txt here are a few comments. Sections 2.1/3.1 ---------------- After the establishment of the TCP connection: - The NETCONF/RESTCONF server _immediately_ starts the SSH-server or the TLS-server protocol; - The NETCONF/RESTCONF client _immediately_ starts the SSH-client or the TLS-client protocol; Is it possible for a race condition to occur that might cause SSH or TLS connection problems? Section 3.2 ----------- I think this section does a pretty good job of describing the issues, listing the alternatives, and the pros/cons of each alternative. That said, I had to read this section several times very carefully. I _think_ I understand what it is saying. Does the following briefly summarize the ideas? After the TCP connection is established, the NETCONF/RESTCONF client has two problems: - How can the NETCONF/RESTCONF client identify the NETCONF/RESTCONF server? (Which server is the client talking to?) - How can the NETCONF/RESTCONF client _be certain_ of the identity of the NETCONF/RESTCONF server it is talking to? Possibilities: - The client can use IP address (from TCP source address of the TCP connection) to identify the server. - In advance of the first connect, the client must know what server is at what IP address. This has limited use cases, so is not recommended. - To identify the server, the client can use the host key or certificate presented by the server. - In advance of the first connect, the client must know which host key or certificate will be sent by which server. From the host key or certificate, the client can be assured of the identity of the server. This does not scale well, so is not recommended. - To identify the server, the client can use the server identity embedded in the host key or presented by the server. - In advance of the first connect, the client must know the trust anchor that signs the server's host key or certificate. From the host key or certificate, the client can be assured of the identity of the server. The client only needs a single trust anchor to identify many servers. Each server host key is populated by the manufacturer as part of the manufacturing process. This solves the client's scaling problem, and is the recommended mechanism. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From nobody Thu Jan 15 14:56:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1C21A909C for ; Thu, 15 Jan 2015 14:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-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 qiJDpF_CYLDk for ; Thu, 15 Jan 2015 14:56:42 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 595861A8FD6 for ; Thu, 15 Jan 2015 14:56:42 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA08592; Thu, 15 Jan 2015 17:56:40 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t0FMufRk036262; Thu, 15 Jan 2015 17:56:41 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t0FMueBA036261; Thu, 15 Jan 2015 17:56:40 -0500 (EST) (envelope-from luchuk) Date: Thu, 15 Jan 2015 17:56:40 -0500 (EST) From: Alan Luchuk Message-Id: <201501152256.t0FMueBA036261@mainfs.snmp.com> To: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Cc: jshoenwaelder@jacobs-university.de Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 22:56:45 -0000 Hello, I have fairly carefully read draft-ietf-netconf-server-model-05.txt, and have the comments included below. I hope the comments are helpful/useful to the NETCONF WG. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ Page 6, Section 2.4, typo ------------------------- s/mapping to be configured."/mapping to be configured./ (Delete the quotation mark.) Page 7, Section 2.6.6, possible improper hyphenation ---------------------------------------------------- The text reads: If a persistent connection is desired, it is the responsibility of the connection-initiator to actively test Not sure, but I think "connection-initiator" should not be hyphenated. Page 8, Section 3.1.1, clarification ------------------------------------ module: ietf-netconf-server +--rw netconf-server +--rw session-options {session-options}? +--rw hello-timeout? uint32 +--rw idle-timeout? uint32 The meaning of the braces { } around session-options initially was not clear. It appeared to be a typo instead of brackets [ ]. After a lot of looking at the usage of the braces, it appears to indicate when the "session-options" feature is present? Perhaps adding something like the following explanation to section 1.2 (on Pages 4 and 5): o Braces "{" and "}" enclose feature names, and indicate that the named feature must be present for the following part of the data model to be present. Page 14, Section 3.2, ietf-netconf-server.yang, nit --------------------------------------------------- grouping session-options-container { description ""; container session-options { I suggest removing the empty description. I think the reason/purpose of the grouping is obvious enough that a description clause does not assist the reader's understanding. Many of the grouping statements in the ietf-netconf-server.yang module and the ietf-restconf-server.yang module have empty descriptions. This same comment applies to them also. Page 18, Section 3.2, ietf-netconf-server.yang, nit --------------------------------------------------- container connection-type { description "Indicates the kind of connection to be maintained."; choice connection-type { default persistent-connection; Possibly change "maintained" to "used"? Persistent connections might be "maintained"; but "maintaining" a periodic connection seems confusing. Page 19, Section 3.2, ietf-netconf-server.yang, clarification ------------------------------------------------------------- leaf linger-secs { type uint8; units seconds; default 30; description "The amount of time the NETCONF server should wait after last receiving data from or sending data to the NETCONF client's endpoint before closing its connection to it. This is an optimization to prevent unnecessary connections."; } In the behavior of the periodic connection (with the 30 second linger-secs), what happens if the NETCONF server holds the idle periodic connection open for 29 seconds, then another message is exchanged on that connection? Based upon the description clause, I would expect the message would reset a linger timer, so the server would wait another 30 seconds before closing the connection. This behavior is not completely spelled out, though. In this scenario, if one of the NETCONF peers repeatedly sends a message just before the linger timeout expires, the periodic connection will never be closed. Is this the desired behavior for the periodic connection, or would it make sense to have timer that forces a close after a certain maximum time period? This same comment applies to other linger-secs values in the ietf-netconf-server.yang module and the ietf-restconf-server.yang module. Page 21, Section 3.2, ietf-netconf-server.yang, nit --------------------------------------------------- grouping tls-container { description ""; container tls { description "Configures TLS properties not specific to the listen or call-home use-cases"; Perhaps change the description text to: description "Configures TLS properties for authenticating clients."; Are there other possibilities are there other than the listen or call-home use cases? Page 23, Section 3.2, ietf-netconf-server.yang, question -------------------------------------------------------- grouping certificates-container { description ""; container certificates { description "Parent container for the list of certificates."; leaf-list certificate { type string; min-elements 1; description "An unordered list of certificates the TLS server can pick from when sending its Server Certificate message. The value of the string is the unique identifier for a certificate configured on the system. How valid values are discovered is outside the scope of this module, but they are envisioned to be the keys for a list of certificates provided by another YANG module"; reference "RFC 5246: The TLS Protocol, Section 7.4.2"; } } } What happens if the min-elements is not satisfied? Also, what is the use case for the server having more than one certificate it can send in it Server Certificate message? How would the server choose which certificate to send in its Server Certificate message? Does this description need a comment about "How a certificate is chosen for sending in a Server Certificate message is outside the scope of this module"? These questions also apply to the certificates-container grouping in the ietf-restconf-server.yang module. Page 25, Section 3.2, ietf-netconf-server.yang, clarification ------------------------------------------------------------- strategy). The interval timer is reset after each transmission, thus an unresponsive NETCONF client will be dropped after ~count-max * interval-secs seconds."; I suggest changing the text to: strategy). The interval timer is reset after each transmission, thus an unresponsive NETCONF client will be dropped after approximately (count-max * interval-secs) seconds."; Upon a first read of this description, the tilde ~ looked like the C-language operator. I had to think about the text a bit more. This same comment applies in the ietf-restconf-server.yang module, on page 36. Page 26, Section 4.1.1, typo ---------------------------- The text reads: module enables configuration for listening for remote connections, as described in [draft-ietf-netconf-restconf] and [draft-ietf-netconf-call-home]. Feature statements are used to limit ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Should the text be changed to delete the flagged text above and read as follows? module enables configuration for listening for remote connections, as described in [draft-ietf-netconf-restconf]. Also, the text reads: to use (i.e. SSH, TLS), and the IP address and port to listen on. ^^^ Should the text be changed to delete the flagged text above and read as follows? to use (i.e. TLS), and the IP address and port to listen on. Page 27, Section 4.1.2, typo ---------------------------- The text reads: the transport to be used (i.e. SSH, TLS), and a list of remote ^^^ Should the text be changed to delete the flagged text above and read as follows? the transport to be used (i.e. TLS), and a list of remote Page 30, Section 4.2, ietf-restconf-server.yang, nit ---------------------------------------------------- list endpoint { key name; description "List of endpoints to listen for connections on."; leaf name { type string; description "An arbitrary name for the listen endpoint."; } Should RESTCONF be added to these descriptions like so? list endpoint { key name; description "List of endpoints to listen for RESTCONF connections on."; leaf name { type string; description "An arbitrary name for the RESTCONF listen endpoint."; } Page 30, Section 4.2, ietf-restconf-server.yang, question --------------------------------------------------------- The following snippet of the data model uses "mandatory true;". choice transport { mandatory true; description "Selects between available transports."; case tls { container tls { I have no idea, but should more schema nodes in both the ietf-restconf- server.yang module and the ietf-netconf-server.yang module be marked by "mandatory true;"? The correct use of the "mandatory true" is unclear to me, based upon the description of the "mandatory" statement in sections 3.1, 7.6.5, 7.9.4, of RFC 6020. But that is a side issue. Correctly identifying schema nodes with "mandatory true" seems high-effort and relatively low value. The best way to address this particular comment might be to ignore it. Page 30, Section 4.2, ietf-restconf-server.yang, question ---------------------------------------------------------- case tls { container tls { description "TLS-specific listening configuration for inbound connections."; uses address-and-port-grouping { refine port { default 6513; } } uses certificates-container; } } Is refining the default value for the port to 6513 intentional, or a cut-and-paste error? This is the same port number IANA assigned for NETCONF over TLS. Page 31, Section 4.2, ietf-restconf-server.yang, typo ----------------------------------------------------- choice transport { mandatory true; description "Selects between SSH and TLS transports."; ^^^^^^^^^^^ Should the "SSH and TLS" be removed? Is it envisioned that RESTCONF may operate over transports other than TLS, or should this not even be a choice because only TLS is supported? Page 36, Section 4.2, ietf-restconf-server.yang, wording -------------------------------------------------------- grouping keep-alives-container { description ""; container keep-alives { description "Configures the keep-alive policy, to proactively test the aliveness of the RESTCONF client, in order to know when a new call home connection should be established."; ^^^^^^^^^ The listen-container grouping on Page 30 also uses the keep-alives-container, so perhaps this description text should not be specific to call home. Page 38, Section 6, "Security Considerations", technical -------------------------------------------------------- The text reads: There are a number of data nodes defined in the "ietf-netconf-server" YANG module which are readable and/or writable that may be considered sensitive or vulnerable in some network environments. Write and read operations to these data nodes can have a negative effect on network operations. It is thus important to control write and read access to these data nodes. Below are the data nodes and their sensitivity/ vulnerability. Then lists a few containers considered security sensitive. Am I missing something, but shouldn't way more schema nodes than just the few listed in section 6 be recognized as security sensitive? As an example, in the ietf-netconf-server.yang module, aren't the following nodes security sensitive? module: ietf-netconf-server +--rw netconf-server +--rw listen {listen}? +--rw max-sessions? uint16 +--rw endpoint* [name] +--rw name string +--rw (transport) | +--:(ssh) {ssh}? | | +--rw ssh | | +--rw address? inet:ip-address | | +--rw port? inet:port-number | | +--rw host-keys | | +--rw host-key* string | +--:(tls) {tls}? | +--rw tls | +--rw address? inet:ip-address | +--rw port? inet:port-number | +--rw certificates | +--rw certificate* string +--rw keep-alives +--rw interval-secs? uint8 +--rw count-max? uint8 If these nodes aren't properly secured, then couldn't an attacker just delete all of the listen endpoints, and disable access to the server? Losing control of the NETCONF server (and presumably the network device it runs on) seems like it fits the description of adversely affect network operations, and so should be listed under security considerations. The same could be said of the call-home nodes, and probably other nodes. From nobody Thu Jan 15 22:27:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1F61AC399 for ; Thu, 15 Jan 2015 22:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 tXd2MLCf--Gb for ; Thu, 15 Jan 2015 22:27:46 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4BD1ABC10 for ; Thu, 15 Jan 2015 22:27:45 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id z107so15032436qgd.4 for ; Thu, 15 Jan 2015 22:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc:message-id :references:to; bh=6ep1sBQlGzR7Q+qDsiOW1ysGJ9p8yxTtUrRwOOIZrRs=; b=Di11AQTuSpszK3AZdzPrdj047Wnjzt1goKgsbJg/72+lGS1ql8wBK50xSISAIv1sEk w2dzmhmkN04cdcWWP5AVkWxzDK2p9Hkwro4Lh3zjTJHmVgKbmHUprXKfsE3fD6BaVwp0 mlhKZ/MKwTk6uahHrmN2I+jK1GS4JfCMOWw+OZA+38gPxqNYIc+H/gTTKnBrGLuhe8jp bnzoq+bhFdgl0q6bPA1fvNBZXVPJuqoddVDGLM70+phxgcHj/zK1Dzbhez5k6Er1hCyI xQpmzWDcs6vdirLMhpR0ewzB7hwTMdSGMRrTaJAfad/Vt8RzAcX/m9fgyo3Wfc+K0dm7 opOg== X-Received: by 10.229.248.69 with SMTP id mf5mr22627152qcb.29.1421389664978; Thu, 15 Jan 2015 22:27:44 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id j9sm3393010qao.16.2015.01.15.22.27.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Jan 2015 22:27:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2689CC29-A72D-4902-8C27-C044A1803181" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mahesh Jethanandani X-Mail-Calendar-Part: Yes Date: Thu, 15 Jan 2015 22:27:41 -0800 Message-Id: <940EF450-D36E-4B04-AD31-50BABF1B8834@gmail.com> References: To: Netconf X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [Netconf] Agenda of the NETCONF Virtual Interim Meeting on January 19, 2015 1700-1900 UTC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 06:27:48 -0000 --Apple-Mail=_2689CC29-A72D-4902-8C27-C044A1803181 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 NETCONF WG, Please find below the agenda of the NETCONF virtual interim meeting on = January 19, 2015 1700-1900 UTC and the access information for the = meeting. I would like to invite all WG members to participate in the meeting and = discuss the open issues. Based on the results of that discussion and = agreement reached, we will start the WGLC for some of the WG items. Agenda of the virtual interim meeting on January 19, 2015 1700-1900 UTC = --------------------------------------------------------------------------= ----------- Agenda is also available at:=20 = http://www.ietf.org/proceedings/interim/2015/01/19/netconf/agenda/agenda-i= nterim-2015-netconf-2 - 5 min chair intro, scribe, agenda bashing The notes will be taken on: http://beta.etherpad.org/p/netconf-Jan19 = =20 - 15 minutes. Discussion around use of GitHub as an issue tracker and = the different states. One of the suggestions from Kent is represented in = the following diagram: GitHub Status +----------------+----------------+ | Open | Closed | | | | | | | | | | | New -----------> Dead | | | | | | V | | | Open | | | | | | | V | | | Verify | | | | | | | V | | | Edit | | | | | | | V | | | Review --------> Done | | | | | | | | | | | Editorial -------> Editorial | | | | | | | +----------------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94+ where the states are (borrowed from NETMOD GitHub) and are defined as = follows: - NEW :: A submitted issue starts in the NEW state. Note that issues were collected in Spring 2014. Since then, we are adding new issues only in special cases (e.g., new YANG bugs identified or splitting issues into several smaller issues). - OPEN :: A first discussion of the issue took place and it was accepted to be in scope of the YANG 1.1 effort. - DEAD :: The issue was declared dead, e.g., because it is considered outside of the scope of YANG 1.1 or the issue does not seem to require a solution. - VRFY :: The issue was discussed and a resolution emerged that needs to be verified on the mailing list. - EDIT :: The issue is waiting for the document editor to make the corresponding changes. - REVIEW :: The edits have been done and the changes in the I-D need to be reviewed. - DONE :: The edits have been reviewed an the issue has been resolved. - Call Home (Kent) (10min) Updated draft posted.=20 Currently 2 open issues in review state See https://github.com/netconf-wg/call-home/issues = =20 - Server Model (Kent) (20min) Currently 4 open issues. Two in verify, 1 dead and 1 edit. See https://github.com/netconf-wg/server-model/issues = - Restconf (Andy) (20min) (Is Andy attending?) Currently 9 open issues, 4 of them are enhancement https://github.com/netconf-wg/restconf/issues = =20 - Zerotouch (Kent) (10min) Currently 2 open issues. See https://github.com/netconf-wg/zero-touch/issues = - Update from i2rs WG (Jeffrey Haas/Susan Hares) i2rs requirements on NETCONF. - 5 min AOB other topics Cheers Mahesh and Mehmet = --------------------------------------------------------------------------= --------------------------------------------------------------------------= ---------------------- NETCONF Virtual Meetings Every 2 weeks on Monday, from Monday, January 19, 2015, to Monday, March = 2, 2015 6:00 pm | Europe Time (Berlin, GMT+01:00) | 2 hr 45 min =20 Join WebEx meeting = Meeting number: 640 672 878 Meeting password: nc2015 =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: 640 672 878 Toll-free calling restrictions = =20 Add this meeting = to your calendar. =20 Can't join the meeting? Contact support. = =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. --Apple-Mail=_2689CC29-A72D-4902-8C27-C044A1803181 Content-Type: multipart/mixed; boundary="Apple-Mail=_16A2222B-3CF4-4BC3-80B3-7BA144B82BDD" --Apple-Mail=_16A2222B-3CF4-4BC3-80B3-7BA144B82BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
NETCONF WG,

Please find below the agenda of = the NETCONF virtual interim meeting on January 19, 2015 1700-1900 UTC = and the access information for the meeting.

I= would like to invite all WG members to participate in the meeting and = discuss the open issues. Based on the results of that discussion = and agreement reached, we will start the WGLC for some of the WG = items.


Agenda of the virtual = interim meeting on January 19, 2015 1700-1900 UTC
---------------------------------------------------------------= ----------------------
Agenda is also available at: 
http://www.ietf.org/proceedings/interim/2015/01/19/netconf/agen= da/agenda-interim-2015-netconf-2

- = 5 min chair intro, scribe, agenda bashing
 The notes = will be taken on: http://beta.etherpad.org/p/netconf-Jan19  

- 15 minutes. Discussion around use of GitHub as an issue = tracker and the different states. One of the suggestions from Kent is = represented in the following diagram:

            =    GitHub Status
   +----------------+----------------+
   |      Open =      |     Closed =     |
   | =             &n= bsp;  | =             &n= bsp;  |
   | =             &n= bsp;  | =             &n= bsp;  |
   | =             &n= bsp;  | =             &n= bsp;  |
   | =      New -----------> Dead =      |
   | =       | =        | =             &n= bsp;  |
   | =       V =        | =             &n= bsp;  |
   | =      Open      | =             &n= bsp;  |
   | =       | =        | =             &n= bsp;  |
   | =       V =        | =             &n= bsp;  |
   | =     Verify     | =             &n= bsp;  |
   | =       | =        | =             &n= bsp;  |
   | =       V =        | =             &n= bsp;  |
   | =      Edit      | =             &n= bsp;  |
   | =       | =        | =             &n= bsp;  |
   | =       V =        | =             &n= bsp;  |
   | =     Review --------> Done =       |
   | =             &n= bsp;  | =             &n= bsp;  |
   | =             &n= bsp;  | =             &n= bsp;  |
   | =             &n= bsp;  | =             &n= bsp;  |
   | =   Editorial -------> Editorial  |
   | =             &n= bsp;  | =             &n= bsp;  |
   | =             &n= bsp;  | =             &n= bsp;  |
   +----------------+=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94+

where the states are (borrowed from NETMOD = GitHub) and are defined as follows:

- = NEW :: A submitted issue starts in the NEW state. Note that issues
         were = collected in Spring 2014. Since then, we are adding new
         issues = only in special cases (e.g., new YANG bugs identified
         or = splitting issues into several smaller issues).
- OPEN :: A = first discussion of the issue took place and it was
          acc= epted to be in scope of the YANG 1.1 effort.
- DEAD :: The = issue was declared dead, e.g., because it is considered
          out= side of the scope of YANG 1.1 or the issue does not seem
          to = require a solution.
- VRFY :: The issue was discussed and = a resolution emerged that needs
          to = be verified on the mailing list.
- EDIT :: The issue is = waiting for the document editor to make the
          cor= responding changes.
- REVIEW :: The edits have been done = and the changes in the I-D need
          &nb= sp; to be reviewed.
- DONE :: The edits have been = reviewed an the issue has been resolved.

- Call Home (Kent) (10min)
    =         Updated draft posted. 
          =   Currently 2 open issues in review state

 See https://github.com/netconf-wg/call-home/issues  

- Server Model (Kent) (20min)
 Currently 4 = open issues. Two in verify, 1 dead and 1 edit.
 See https://github.com/netconf-wg/server-model/issues

         - Restconf (Andy) (20min) (Is = Andy attending?)
          =  Currently 9 open issues, 4 of them are enhancement
           https://github.com/netconf-wg/restconf/issues  &n= bsp;

        - Zerotouch (Kent) (10min)
          Currently 2 open = issues.
          See https://github.com/netconf-wg/zero-touch/issues

       - Update from i2rs WG (Jeffrey = Haas/Susan Hares)
          i2rs = requirements on NETCONF.


    =    - 5 min AOB other topics

Cheers
Mahesh and Mehmet

---------------------------------------------------------------= --------------------------------------------------------------------------= ---------------------------------
NETCONF Virtual = Meetings
Every 2 weeks on Monday, from Monday, January 19, 2015, to = Monday, March 2, 2015
6:00= pm  |  Europe Time (Berlin, = GMT+01:00)  |  2 hr 45 = min
 
Join WebEx = meeting
Meeting = number:640 = 672 878
Meeting = password:nc2015
 
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 672 878
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.
= --Apple-Mail=_16A2222B-3CF4-4BC3-80B3-7BA144B82BDD Content-Disposition: attachment; filename=WebEx_Meeting.ics Content-Type: text/calendar; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0ABEGIN:VTIMEZONE=0A= TZID:Europe=20Time=0ABEGIN:STANDARD=0ADTSTART:20131001T030000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10=0A= TZOFFSETFROM:+0200=0ATZOFFSETTO:+0100=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20130301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3=0A= TZOFFSETFROM:+0100=0ATZOFFSETTO:+0200=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0ABEGIN:VEVENT=0AATTENDEE;CN=3D"NETCONF=20= Working=20= Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:netconf-chairs@tools.ietf= .org=0AORGANIZER;CN=3D"NETCONF=20Working=20= Group":MAILTO:netconf-chairs@tools.ietf.org=0ADTSTART;TZID=3D"Europe=20= Time":20150119T180000=0ADTEND;TZID=3D"Europe=20Time":20150119T204500=0A= RRULE:FREQ=3DWEEKLY;INTERVAL=3D2;BYDAY=3DMO;UNTIL=3D20150302T204500Z=0A= LOCATION:https://ietf.webex.com/ietf=0ATRANSP:OPAQUE=0ASEQUENCE:2=0A= UID:WEBEX-MEETING=20CENTER-6.0456680-311998162-SU=3Dietf=0A= DTSTAMP:20150119T170000Z=0ADESCRIPTION:\n\n\nJOIN=20WEBEX=20= MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dmb7c42dd2a2944005f5fd0a8= 624dac056\nMeeting=20number:=20640=20672=20878\nMeeting=20password:=20= nc2015\n\n\nJOIN=20BY=20PHONE\n1-877-668-4493=20Call-in=20toll=20free=20= number=20(US/Canada)=20\n1-650-479-3208=20Call-in=20toll=20number=20= (US/Canada)\nAccess=20code:=20640=20672=20878\n\nToll-free=20dialing=20= restrictions:=20= \nhttp://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't=20join=20= the=20meeting?=20Contact=20support=20= here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT=20NOTICE:=20Please=20= note=20that=20this=20WebEx=20service=20allows=20audio=20and=20other=20= information=20sent=20during=20the=20session=20to=20be=20recorded,=20= which=20may=20be=20discoverable=20in=20a=20legal=20matter.=20By=20= joining=20this=20session,=20you=20automatically=20consent=20to=20such=20= recordings.=20If=20you=20do=20not=20consent=20to=20being=20recorded,=20= discuss=20your=20concerns=20with=20the=20host=20or=20do=20not=20join=20= the=20session.\n=0AX-ALT-DESC;FMTTYPE=3Dtext/html:=09 
=20=09=09Join=20= WebEx=20meeting=09=09=09=09=09=09=09=09=09=09=09=09= =09=09=09=09=09= =09=09=09=09= =09=09=09
=09=09=09=09=09=09Meeting=20number:=09=09=09=09=09=09=09=09=09=09=09640=20672=20878=09=09=09=09=09
=09=09=09
Meeting=20= password:nc2015
=09=09 
 
Join=20by=20phone =20
1-877-668-4493 Call-in=20toll=20= free=20number=20(US/Canada) =20
1-650-479-3208 Call-in=20toll=20= number=20(US/Canada) =20
Access=20code:=20640=20672=20= 878 =20
Toll-free=20calling=20= restrictions=20 =20


=09 
=09= =09=09=09=09= Can't=20join=20the=20meeting?=09=09Contact=20support.=09=  
 
IMPORTANT=20NOTICE:=20Please=20note=20that=20this=20WebEx=20= service=20allows=20audio=20and=20other=20information=20sent=20during=20= the=20session=20to=20be=20recorded,=20which=20may=20be=20discoverable=20= in=20a=20legal=20matter.=20By=20joining=20this=20session,=20you=20= automatically=20consent=20to=20such=20recordings.=20If=20you=20do=20not=20= consent=20to=20being=20recorded,=20discuss=20your=20concerns=20with=20= the=20host=20or=20do=20not=20join=20the=20session.=0A= SUMMARY:NETCONF=20Virtual=20Meetings=0APRIORITY:5=0ACLASS:PUBLIC=0A= BEGIN:VALARM=0ATRIGGER:-PT15M=0AACTION:DISPLAY=0ADESCRIPTION:Reminder=0A= END:VALARM=0AEND:VEVENT=0AEND:VCALENDAR=0A= --Apple-Mail=_16A2222B-3CF4-4BC3-80B3-7BA144B82BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii




= --Apple-Mail=_16A2222B-3CF4-4BC3-80B3-7BA144B82BDD-- --Apple-Mail=_2689CC29-A72D-4902-8C27-C044A1803181-- From nobody Fri Jan 16 07:38:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86F61ACDD7 for ; Fri, 16 Jan 2015 07:38:05 -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 v2P7cnmPsdhP for ; Fri, 16 Jan 2015 07:38:02 -0800 (PST) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659EA1ACE01 for ; Fri, 16 Jan 2015 07:37:55 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id 10so19059967lbg.5 for ; Fri, 16 Jan 2015 07:37: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=If0gVJS6zXnpHDVd9HXGRlLlQq3/XuVK6bRsoJNgXUM=; b=Ke6CGuxmop6JGqnP48xMku+O7dw/VS6bRsUye2bbHUYn+CwIkhIEWz+QCvR6q6n24Q Gmtpr7WdnU9vN5rrxWP0e20OeC5hT2KdByC+K11BwYvjbpWvJwGPKezq1exQVT+8CDk4 OIji774/z+f0f8p0ZlfZCtjfv8drYk26awnXdnkBiTJuJ5ZU5hpCc5UjOv2vfv7p+92H /U1k7KR7nhOS1mu7BzoJvRM8VBa7xK1WqRZNB2maAUsYR0amXoZmPhS0i7FwTO4T9J20 r+7PUpmTeuHmVEHSkVLVTp+Cq4xIObxP2bkQ+xtXL9obOLyxBSV6be2ATVuPCXgke1TK tvUw== X-Gm-Message-State: ALoCoQlI3yv+GG+TwDDJNE9pgaEKwqnclVZX6Fzsk0DLqUyp3Lda+3aMN38JKGBCZmFYmjeend87 MIME-Version: 1.0 X-Received: by 10.152.7.206 with SMTP id l14mr16345774laa.1.1421422673848; Fri, 16 Jan 2015 07:37:53 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 16 Jan 2015 07:37:53 -0800 (PST) In-Reply-To: <940EF450-D36E-4B04-AD31-50BABF1B8834@gmail.com> References: <940EF450-D36E-4B04-AD31-50BABF1B8834@gmail.com> Date: Fri, 16 Jan 2015 07:37:53 -0800 Message-ID: From: Andy Bierman To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=001a11c34b648d05f0050cc6c141 Archived-At: Cc: Netconf Subject: Re: [Netconf] Agenda of the NETCONF Virtual Interim Meeting on January 19, 2015 1700-1900 UTC X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 15:38:06 -0000 --001a11c34b648d05f0050cc6c141 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Monday, Jan. 19th is a national holiday in the US (MLK day) so I will not be attending the interim. Perhaps somebody else can present the RESTCONF status. Andy On Thu, Jan 15, 2015 at 10:27 PM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > NETCONF WG, > > Please find below the agenda of the NETCONF virtual interim meeting on > January 19, 2015 1700-1900 UTC and the access information for the meeting= . > > I would like to invite all WG members to participate in the meeting and > discuss the open issues. Based on the results of that discussion and > agreement reached, we will start the WGLC for some of the WG items. > > > Agenda of the virtual interim meeting on January 19, 2015 1700-1900 UTC > > -------------------------------------------------------------------------= ------------ > Agenda is also available at: > > http://www.ietf.org/proceedings/interim/2015/01/19/netconf/agenda/agenda-= interim-2015-netconf-2 > > - 5 min chair intro, scribe, agenda bashing > The notes will be taken on: http://beta.etherpad.org/p/netconf-Jan19 > > - 15 minutes. Discussion around use of GitHub as an issue tracker and the > different states. One of the suggestions from Kent is represented in the > following diagram: > > GitHub Status > +----------------+----------------+ > | Open | Closed | > | | | > | | | > | | | > | New -----------> Dead | > | | | | > | V | | > | Open | | > | | | | > | V | | > | Verify | | > | | | | > | V | | > | Edit | | > | | | | > | V | | > | Review --------> Done | > | | | > | | | > | | | > | Editorial -------> Editorial | > | | | > | | | > +----------------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94+ > > where the states are (borrowed from NETMOD GitHub) and are defined as > follows: > > - NEW :: A submitted issue starts in the NEW state. Note that issues > were collected in Spring 2014. Since then, we are adding new > issues only in special cases (e.g., new YANG bugs identified > or splitting issues into several smaller issues). > - OPEN :: A first discussion of the issue took place and it was > accepted to be in scope of the YANG 1.1 effort. > - DEAD :: The issue was declared dead, e.g., because it is considered > outside of the scope of YANG 1.1 or the issue does not seem > to require a solution. > - VRFY :: The issue was discussed and a resolution emerged that needs > to be verified on the mailing list. > - EDIT :: The issue is waiting for the document editor to make the > corresponding changes. > - REVIEW :: The edits have been done and the changes in the I-D need > to be reviewed. > - DONE :: The edits have been reviewed an the issue has been resolved. > > - Call Home (Kent) (10min) > > Updated draft posted. > Currently 2 open issues in review state > > See https://github.com/netconf-wg/call-home/issues > > - Server Model (Kent) (20min) > Currently 4 open issues. Two in verify, 1 dead and 1 edit. > See https://github.com/netconf-wg/server-model/issues > > - Restconf (Andy) (20min) (Is Andy attending?) > Currently 9 open issues, 4 of them are enhancement > https://github.com/netconf-wg/restconf/issues > > - Zerotouch (Kent) (10min) > Currently 2 open issues. > See https://github.com/netconf-wg/zero-touch/issues > > > - Update from i2rs WG (Jeffrey Haas/Susan Hares) > i2rs requirements on NETCONF. > > > - 5 min AOB other topics > > Cheers > Mahesh and Mehmet > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------- > *NETCONF Virtual Meetings*Every 2 weeks on Monday, from Monday, January > 19, 2015, to Monday, March 2, 20156:00 pm | Europe Time (Berlin, > GMT+01:00) | 2 hr 45 min *Join WebEx meeting* > Meeting > number:640 672 878Meeting password:nc2015 *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 672 878Toll-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. > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c34b648d05f0050cc6c141 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


Monday, Jan. 19th is= a national holiday in the US (MLK day) so I will
not be attendin= g the interim.=C2=A0 Perhaps somebody else can present
the RESTCO= NF status.


Andy


On Thu, Ja= n 15, 2015 at 10:27 PM, Mahesh Jethanandani <mjethanandani@gmail.c= om> wrote:
NETCONF= WG,

Please find below = the agenda of the NETCONF virtual interim meeting on January 19, 2015 1700-= 1900 UTC and the access information for the meeting.

I would like to= invite all WG members to participate in the meeting and discuss the open i= ssues.=C2=A0Based on the results of that discussion and agreement reached, = we will start the WGLC for some of the WG items.


Agenda of the v= irtual interim meeting on January 19, 2015 1700-1900 UTC
---------------= ----------------------------------------------------------------------
A= genda is also available at:=C2=A0
http://www.ietf= .org/proceedings/interim/2015/01/19/netconf/agenda/agenda-interim-2015-netc= onf-2

- = 5 min chair intro, scribe, agenda bashing
=C2=A0The notes will be taken on:=C2= =A0http://beta.etherpad.org/p/netconf-Jan19=C2=A0=C2=A0

- 15= minutes. Discussion around use of GitHub as an issue tracker and the diffe= rent states. One of the suggestions from Kent is represented in the followi= ng diagram:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GitHub Status<= br>=C2=A0=C2=A0=C2=A0+----------------+----------------+
=C2=A0=C2=A0=C2= =A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Open =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2= =A0=C2=A0=C2=A0=C2=A0Closed =C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0= | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=A0New ----------= -> Dead =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0V =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2= =A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Open =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0V =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0|= =C2=A0=C2=A0=C2=A0=C2=A0Verify =C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0V =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Edit =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2= =A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0V =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0Review -------= -> Done =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=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=A0Editorial -------> Editorial =C2=A0= |
=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2= =A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0| =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|
=C2=A0=C2=A0=C2=A0+------= ----------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94+

where the states are (borrowed from NETMOD Git= Hub) and are defined as follows:

- NEW :: A submitted issue s= tarts in the NEW state. Note that issues
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0were collected in Spring 2014. Since then, we are a= dding new
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0issues o= nly in special cases (e.g., new YANG bugs identified
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0or splitting issues into several smalle= r issues).
- OPEN :: A first discussion of the issue took place and it w= as
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0accepted = to be in scope of the YANG 1.1 effort.
- DEAD :: The issue was declared = dead, e.g., because it is considered
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0outside of the scope of YANG 1.1 or the issue do= es not seem
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= to require a solution.
- VRFY :: The issue was discussed and a resolutio= n emerged that needs
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0to be verified on the mailing list.
- EDIT :: The issue is wait= ing for the document editor to make the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0corresponding changes.
- REVIEW :: The edi= ts have been done and the changes in the I-D need
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0to be reviewed.
- DON= E :: The edits have been reviewed an the issue has been resolved.

- Cal= l Home (Kent) (10min)
<= div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va= riant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;te= xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-= spacing:0px">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Updated draft posted.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Curre= ntly 2 open issues in review state
<= blockquote style=3D"font-family:Helvetica;font-size:12px;font-style:normal;= font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:no= rmal;text-align:start;text-indent:0px;text-transform:none;white-space:norma= l;word-spacing:0px;margin-top:5pt;margin-bottom:5pt">

=C2=A0See=C2=A0https://github.com/netconf-wg/call-home/issues=C2=A0<= /span>=C2=A0

- Server Model (Kent) (20min)
=C2=A0Currently 4 open= issues. Two in verify, 1 dead and 1 edit.
=C2=A0See=C2=A0<= a href=3D"https://github.com/netconf-wg/server-model/issues" style=3D"text-= decoration:underline" target=3D"_blank">https://github.com/netconf-wg/serve= r-model/issues

<= p class=3D"MsoNormal" style=3D"margin:0cm 0cm 12pt;font-size:12pt;font-fami= ly:'Times New Roman',serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Res= tconf (Andy) (20min) (Is Andy attending?)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Currently 9 open issues, 4 of them are enhancement
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://github.com/netconf-wg/restconf/i= ssues=C2=A0=C2=A0=C2=A0

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 - Zerotouch (Kent) (10min)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Currently 2 open issues.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S= ee=C2=A0https://github.com/netconf-wg/zero-touch/issues

=C2=A0 =C2=A0 =C2=A0 =C2=A0- Updat= e from i2rs WG (Jeffrey Haas/Susan Hares)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 i2rs requirements on NETCONF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0- 5 min AOB other topics
Cheers
Mahesh and Mehmet

-----------------------= ---------------------------------------------------------------------------= ------------------------------------------------------------------------
=
NETCONF Virtual Meetings<= /b>
Every 2 weeks on Monday, from Monday, January 19, 2015, to Monday, = March 2, 2015
6:00 pm=C2=A0=C2=A0|=C2=A0=C2=A0Europe Time (Berlin, GMT= +01:00)=C2=A0=C2=A0|=C2=A0=C2=A02 hr 45 min
=C2=A0
Join Web= Ex meeting
Meeting number:640 672 878
Meeting password:n= c2015
=C2=A0
<= td style=3D"word-wrap:break-word;word-break:normal;font-size:15px;color:rgb= (102,102,102);padding:0px">1-650-479-3208=C2=A0Call-in toll number (= US/Canada)
Join by phone
1-877-668-4493=C2=A0Call-in toll f= ree number (US/Canada)
Access code:=C2=A0640 672 878
Toll-free callin= g restrictions
=C2=A0
Add this meeting=C2=A0to your = calendar.
=C2=A0
Can't join the meeting?=C2=A0Contact support.
=C2=A0
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 joi= ning this session, you automatically consent to such recordings. If you do = not consent to being recorded, discuss your concerns with the host or do no= t join the session.



=



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


--001a11c34b648d05f0050cc6c141-- From jumilan@cisco.com Fri Jan 16 09:52:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5B91AD371 for ; Fri, 16 Jan 2015 09:52:37 -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 ZhglOkxq3UtW for ; Fri, 16 Jan 2015 09:52:36 -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 B7DE51AD2A4 for ; Fri, 16 Jan 2015 09:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4734; q=dns/txt; s=iport; t=1421430755; x=1422640355; h=from:to:cc:subject:date:message-id:mime-version; bh=mNt+4Fz56PhFoOryZRrV1u4G4v6vbEbh+qll9eWLnKk=; b=m+Y3cb826NdxR+pC+SaSdGRfAUjMpfMCrUlmiJqUqCNen90Il8Vmkv3t gs3artTKS2hoS2dOKoKoGD0b9X01Cp0liNb4wE2EejSHbuMKI9eFKDyxK /RpOoYr/eJJUuXktcu3bBL41/IR4CUWL42SZj9krNBcer51tt0uc72094 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAPxOuVStJV2R/2dsb2JhbABagkNDUlgExAKCJYVxAoETQwEBAQEBfYQOAQQtOhISASpWJgEEDg2IJA3STwEBAQEBAQEBAQEBAQEBAQEBAQEBGAuNYYFcMYMdgRMFjkybGSKDbm8BgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,412,1418083200"; d="scan'208,217";a="113924771" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 16 Jan 2015 17:52:35 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0GHqYxr031518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 Jan 2015 17:52:34 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 16 Jan 2015 11:52:34 -0600 From: "Julius Milan -X (jumilan - Pantheon Technologies SRO at Cisco)" To: "netconf@ietf.org" Thread-Topic: message-id attribute value normalization Thread-Index: AdAxtS/196KFVEGPQJGaq2NUav0z1Q== Date: Fri, 16 Jan 2015 17:52:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-Auto-Response-Suppress: DR, OOF, AutoReply X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.51] Content-Type: multipart/alternative; boundary="_000_C77BBBE062316D4C8138F26BC5DA2B6E04A0B32Axmbrcdx06ciscoc_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 16 Jan 2015 10:52:17 -0800 Cc: "ulfberht-dev\(mailer list\)" , "Anna Medvedova -X \(amedvedo - Pantheon Technologies SRO at Cisco\)" Subject: [Netconf] message-id attribute value normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 18:07:10 -0000 --_000_C77BBBE062316D4C8138F26BC5DA2B6E04A0B32Axmbrcdx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have one detail regarding RFC 6241. In netconf.xsd is attribute message-id defined as string. Type string is defined (http://www.schemacentral.com/sc/xsd/t-xsd_string.ht= ml) to be non-normalized. So all whitespace characters (spaces, tabs, carriage returns, and line feed= s) must be preserved by the processor. However in rfc is also written: "The sender MUST ensure that the "message-id" value is normalized according to ... if the sender wants the string to be returned unmodified." Is it intended to have a message-id non-normalized? Wouldn't be more appropriate to define it as normalizedString (http://www.d= atypic.com/sc/xsd/t-xsd_normalizedString.html)? Which is basically the same, just provides normalization of allowed whitesp= ace characters and as written in specification above: "This processing is equivalent to the processing of CDATA attribute values = in XML 1.0." Thanks, Julius --_000_C77BBBE062316D4C8138F26BC5DA2B6E04A0B32Axmbrcdx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have one detail regarding RFC 6241.

In netconf.xsd is attribute message-id defined as st= ring.

Type string is defined (http://www.schemacentral.com/sc/xsd/t= -xsd_string.html) to be non-normalized.

So all whitespace characters (spaces, tabs, carriage= returns, and line feeds) must be preserved by the processor.

 

However in rfc is also written:

“The sender MUST ensure that the "message= -id" value is normalized

according to … if the sender wants the string = to be returned unmodified.”

 

Is it intended to have a message-id non-normalized?<= o:p>

Wouldn’t be more appropriate to define it as n= ormalizedString (http://www.datypic.com/sc/xsd/t-xsd_normalizedString.html)= ?

Which is basically the same, just provides normaliza= tion of allowed whitespace characters

and as written in specification above:

“This processing is equivalent to the processi= ng of CDATA attribute values in XML 1.0.”

 

Thanks,

Julius

--_000_C77BBBE062316D4C8138F26BC5DA2B6E04A0B32Axmbrcdx06ciscoc_-- From nobody Fri Jan 16 11:54:25 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A531B2AFB for ; Fri, 16 Jan 2015 11:54:23 -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 SL9FLZ3fSPPb for ; Fri, 16 Jan 2015 11:54:21 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6311B2AF8 for ; Fri, 16 Jan 2015 11:54:21 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id l4so7463263lbv.3 for ; Fri, 16 Jan 2015 11:54: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=is9wNG4t8HuRoMlaHQPAoWu6JJ1PgQPQVO4wKksTm7w=; b=jfZIlv9mndN8oztGyLtODU/EZ49xfndBNydZf18SnoVbecau9bZIkNmTaoTFxb5iJ1 hioDV45dgTYstwTH1oiXRlrEqYsLVwCRO7Vpm1SB4va+Fmkn3NkhnemdfExtm69vI3u2 UUgioY6ewDd+yKecuL5s4ruizrVgIlKM/xatumdyCW65G5S0HvCboIZ+4+ioYFMZCeiu lQXzbXUrgWEbipva8nXNauLfYAOe+q3aWK3qAl59xRF7K2QiPt0R/rJDNIEDikhr0Q6o GCasNJrQrdwVcJmvAydrpT3IsDWHwGt0hV4CSbNIABLcGWvu6cYpOiXURRJMlhkGa8Mu vxIw== X-Gm-Message-State: ALoCoQmHkN0zls7042Dt61Lem4rW7NUEG3K4FSljMAglVOCfDeRqLanlF52j5YFHViL2PyDw5YxU MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr17233851lam.15.1421438059609; Fri, 16 Jan 2015 11:54:19 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 16 Jan 2015 11:54:19 -0800 (PST) In-Reply-To: References: Date: Fri, 16 Jan 2015 11:54:19 -0800 Message-ID: From: Andy Bierman To: "Julius Milan -X (jumilan - Pantheon Technologies SRO at Cisco)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netconf@ietf.org" , "ulfberht-dev\(mailer list\)" , "Anna Medvedova -X \(amedvedo - Pantheon Technologies SRO at Cisco\)" Subject: Re: [Netconf] message-id attribute value normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 19:54:23 -0000 On Fri, Jan 16, 2015 at 9:52 AM, Julius Milan -X (jumilan - Pantheon Technologies SRO at Cisco) wrote: > Hi all, > > > > I have one detail regarding RFC 6241. > > In netconf.xsd is attribute message-id defined as string. > > Type string is defined > (http://www.schemacentral.com/sc/xsd/t-xsd_string.html) to be > non-normalized. > > So all whitespace characters (spaces, tabs, carriage returns, and line > feeds) must be preserved by the processor. > > > > However in rfc is also written: > > =E2=80=9CThe sender MUST ensure that the "message-id" value is normalized > > according to =E2=80=A6 if the sender wants the string to be returned unmo= dified.=E2=80=9D > > > > Is it intended to have a message-id non-normalized? > > Wouldn=E2=80=99t be more appropriate to define it as normalizedString > (http://www.datypic.com/sc/xsd/t-xsd_normalizedString.html)? > > Which is basically the same, just provides normalization of allowed > whitespace characters > > and as written in specification above: > > =E2=80=9CThis processing is equivalent to the processing of CDATA attribu= te values > in XML 1.0.=E2=80=9D > The intent is that has all the attributes that are in start-tag, unchanged by the server. The server parses the input parameters and then returns the attribute encoding of the parsed value in . The server is not supposed to alter these attributes. It is not clear whether "xmlns" attributes have to be returned unchanged. A valid XML parser should not rely on specific prefix mappings. > > > Thanks, > > Julius > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Fri Jan 16 12:35:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86851B2B85 for ; Fri, 16 Jan 2015 12:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5-S-lflYITpq for ; Fri, 16 Jan 2015 12:35:50 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F191B2B84 for ; Fri, 16 Jan 2015 12:35:50 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.53.17; Fri, 16 Jan 2015 20:35:47 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) with mapi id 15.01.0053.000; Fri, 16 Jan 2015 20:35:47 +0000 From: Kent Watsen To: Alan Luchuk , "netconf@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-call-home-03.txt Thread-Index: AQHQMOUJjeGCbrIRk0K/2wI+9zdOR5zC4mcA Date: Fri, 16 Jan 2015 20:35:47 +0000 Message-ID: References: <201501151702.t0FH24P6033349@mainfs.snmp.com> In-Reply-To: <201501151702.t0FH24P6033349@mainfs.snmp.com> 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.241.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 04583CED1A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(189002)(43784003)(2900100001)(107886001)(102836002)(99286002)(2950100001)(106116001)(105586002)(40100003)(36756003)(46102003)(106356001)(68736005)(86362001)(50986999)(83506001)(76176999)(54356999)(2656002)(66066001)(230783001)(87936001)(92566002)(77156002)(97736003)(2501002)(62966003)(122556002)(64706001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 16 Jan 2015 20:35:47.1697 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 20:35:52 -0000 Hi Alan, Thank you for your review! Below are responses to your questions. Thanks Kent >Sections 2.1/3.1 >---------------- > >After the establishment of the TCP connection: > >- The NETCONF/RESTCONF server _immediately_ starts the SSH-server or > the TLS-server protocol; > >- The NETCONF/RESTCONF client _immediately_ starts the SSH-client or > the TLS-client protocol; > >Is it possible for a race condition to occur that might cause SSH or TLS >connection problems? The "immediately" is meant to be interpreted more as "no more TPC data is exchanged" than "without temporal delay". There isn't a race condition here. Just like with a standard (not reversed) connection, the TCP stacks will buffer the data until the SSH/TLS layers get initialized. Do you agree? >Section 3.2 >----------- > >I think this section does a pretty good job of describing the issues, >listing the alternatives, and the pros/cons of each alternative. That >said, I had to read this section several times very carefully. I _think_ >I understand what it is saying. Does the following briefly summarize the >ideas? > > >After the TCP connection is established, the NETCONF/RESTCONF client has >two problems: > >- How can the NETCONF/RESTCONF client identify the NETCONF/RESTCONF >server? > (Which server is the client talking to?) > >- How can the NETCONF/RESTCONF client _be certain_ of the identity of the > NETCONF/RESTCONF server it is talking to? > Yes >Possibilities: > >- The client can use IP address (from TCP source address of the TCP > connection) to identify the server. > > - In advance of the first connect, the client must know what server > is at what IP address. This has limited use cases, so is not > recommended. > > >- To identify the server, the client can use the host key or certificate > presented by the server. > > - In advance of the first connect, the client must know which host > key or certificate will be sent by which server. From the host > key or certificate, the client can be assured of the identity of > the server. This does not scale well, so is not recommended. > > >- To identify the server, the client can use the server identity >embedded=20 > in the host key or presented by the server. > > - In advance of the first connect, the client must know the trust > anchor that signs the server's host key or certificate. From > the host key or certificate, the client can be assured of the > identity of the server. > > The client only needs a single trust anchor to identify many > servers. Each server host key is populated by the manufacturer > as part of the manufacturing process. This solves the client's > scaling problem, and is the recommended mechanism. One small correction on the last case. In advance of the first connect, the client should (not must) also know the unique-identifer expected in the server's certificate. By example, an NMS should know the serial-numbers for devices it expects to connect to it, in order to be certain the devices are legitimate. Otherwise, is this section still OK? Thanks again, Kent From nobody Fri Jan 16 13:28:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2EB1B2A07 for ; Fri, 16 Jan 2015 13:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 JWYdpOcqzX1J for ; Fri, 16 Jan 2015 13:28:53 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5E1ACD92 for ; Fri, 16 Jan 2015 13:28:52 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA14330; Fri, 16 Jan 2015 16:28:48 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t0GLSnBA060605; Fri, 16 Jan 2015 16:28:49 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t0GLSn2W060604; Fri, 16 Jan 2015 16:28:49 -0500 (EST) (envelope-from luchuk) Date: Fri, 16 Jan 2015 16:28:49 -0500 (EST) From: Alan Luchuk Message-Id: <201501162128.t0GLSn2W060604@mainfs.snmp.com> To: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 21:28:55 -0000 Hi Kent, >Thank you for your review! You're welcome, and thanks for your clarifications. >>Sections 2.1/3.1 >>---------------- >> >>After the establishment of the TCP connection: >> >>- The NETCONF/RESTCONF server _immediately_ starts the SSH-server or >> the TLS-server protocol; >> >>- The NETCONF/RESTCONF client _immediately_ starts the SSH-client or >> the TLS-client protocol; >> >>Is it possible for a race condition to occur that might cause SSH or TLS >>connection problems? > > >The "immediately" is meant to be interpreted more as "no more TPC data is >exchanged" than "without temporal delay". There isn't a race condition >here. Just like with a standard (not reversed) connection, the TCP stacks >will buffer the data until the SSH/TLS layers get initialized. Do you >agree? Yes. >>Section 3.2 >>----------- >> >>I think this section does a pretty good job of describing the issues, >>listing the alternatives, and the pros/cons of each alternative. That >>said, I had to read this section several times very carefully. I _think_ >>I understand what it is saying. Does the following briefly summarize the >>ideas? > >One small correction on the last case. In advance of the first connect, >the client should (not must) also know the unique-identifer expected in >the server's certificate. By example, an NMS should know the >serial-numbers for devices it expects to connect to it, in order to be >certain the devices are legitimate. > >Otherwise, is this section still OK? I think the bulk of the text can be kept intact, but might be clarified with a few relatively small changes. The comments below highlight what I found confusing. On the other hand, if nobody else was confused, then maybe the text should not be changed. Use your judgement. Section 3.2, third paragraph: ----------------------------- Would it be appropriate to change "credentials" to "identity"? This is the only paragraph where the term "credentials" is used. When I saw "credentials", I thought of something like a password, host key, or X.509 cert, rather than simply the server's identity. If changing "credentials" to "identity" is not appropriate, then perhaps adding one sentence that defines the term credentials. Section 3.2, fifth paragraph: ----------------------------- The following is hard to parse. Without examining the contents of the host-key or certificate, it is possible to form an identity for the NETCONF/RESTCONF server using it directly (e.g., a fingerprint), since each NETCONF/RESTCONF server is assumed to have a statistically unique public key, even in virtualized environments. Perhaps splitting like so? Without examining the contents of the host-key or certificate, it is possible to form an identity for the NETCONF/RESTCONF server using it directly (e.g., a fingerprint). This works because each NETCONF/RESTCONF ^^^^^^^^^^^^^^^^^^^^^ server is assumed to have a statistically unique public key, even in virtualized environments. The following sentence reads: This strategy also provides a mechanism to verify the NETCONF/RESTCONF server... Would the following clarify what is being verified? This strategy also provides a mechanism to verify the identity of the NETCONF/RESTCONF server... ^^^^^^^^^^^^^^^ Section 3.2, sixth paragraph: ----------------------------- One of the sentences reads: This strategy's use of PKI enables a NETCONF/RESTCONF client to transparently authenticate NETCONF/RESTCONF servers Would it be appropriate to change the text to read: This strategy's use of PKI enables a NETCONF/RESTCONF client to transparently authenticate the identity of NETCONF/RESTCONF servers This is the only paragraph where the term "authenticate" is used. I hope these suggestions are useful. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From nobody Fri Jan 16 16:18:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CA31A907B for ; Fri, 16 Jan 2015 16:18: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, 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 v1AmwI934pHK for ; Fri, 16 Jan 2015 16:18:55 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015391A9068 for ; Fri, 16 Jan 2015 16:18:54 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sat, 17 Jan 2015 00:18:31 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) with mapi id 15.01.0053.000; Sat, 17 Jan 2015 00:18:31 +0000 From: Kent Watsen To: Alan Luchuk , "netconf@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-call-home-03.txt Thread-Index: AQHQMdNqjeGCbrIRk0K/2wI+9zdOR5zDHsaA Date: Sat, 17 Jan 2015 00:18:30 +0000 Message-ID: References: <201501162128.t0GLSn2W060604@mainfs.snmp.com> In-Reply-To: <201501162128.t0GLSn2W060604@mainfs.snmp.com> 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.241.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB457; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 04599F3534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(43784003)(189002)(51444003)(51704005)(50986999)(101416001)(105586002)(97736003)(551544002)(106356001)(2501002)(76176999)(54356999)(106116001)(64706001)(99286002)(36756003)(107886001)(2656002)(230783001)(2950100001)(92566002)(2900100001)(87936001)(102836002)(122556002)(68736005)(77156002)(83506001)(40100003)(62966003)(46102003)(86362001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <037E16AE3B78784B8F03A4B4F948DF55@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2015 00:18:30.5439 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 00:18:57 -0000 >>>- The NETCONF/RESTCONF server _immediately_ starts the SSH-server or >>> the TLS-server protocol; >>> >>>- The NETCONF/RESTCONF client _immediately_ starts the SSH-client or >>> the TLS-client protocol; >>> >>>Is it possible for a race condition to occur that might cause SSH or TLS >>>connection problems? >> >> >>The "immediately" is meant to be interpreted more as "no more TPC data is >>exchanged" than "without temporal delay". There isn't a race condition >>here. Just like with a standard (not reversed) connection, the TCP >>stacks >>will buffer the data until the SSH/TLS layers get initialized. Do you >>agree? > >Yes. =20 Do you think the current text can be improved to make this interpretation clearer? >I think the bulk of the text can be kept intact, but might be clarified >with a few relatively small changes. The comments below highlight what >I found confusing. On the other hand, if nobody else was confused, then >maybe the text should not be changed. Use your judgement. Great, see my comments below: >Section 3.2, third paragraph: >----------------------------- > >Would it be appropriate to change "credentials" to "identity"? This is >the=20 >only paragraph where the term "credentials" is used. > >When I saw "credentials", I thought of something like a password, host >key,=20 >or X.509 cert, rather than simply the server's identity. If changing >"credentials" to "identity" is not appropriate, then perhaps adding one >sentence that defines the term credentials. We could say "verify identity" as well. Think of the questions the client is asking: - who is trying to connect to me? (identity) - how do I know that it is really you? (verify identity) What gets tricky is that verifying identity is done by verifying credentials (public key, proof that the server possesses the private key, and optionally certificates for PKI (host cert, cert chain, and trust anchor cert). So I think that it's OK as written, but I can see "verify identity" as being easier on the reader, so: Agreed - done (switched out use of "credential" term) >Section 3.2, fifth paragraph: >----------------------------- > >The following is hard to parse. > > Without examining the contents of the host-key or certificate, it is > possible to form an identity for the NETCONF/RESTCONF server using it > directly (e.g., a fingerprint), since each NETCONF/RESTCONF server is > assumed to have a statistically unique public key, even in virtualized > environments. =20 > >Perhaps splitting like so? > > Without examining the contents of the host-key or certificate, it is > possible to form an identity for the NETCONF/RESTCONF server using it > directly (e.g., a fingerprint). This works because each >NETCONF/RESTCONF=20 > ^^^^^^^^^^^^^^^^^^^^^ > server is assumed to have a statistically unique public key, even in > virtualized environments. Agreed - done! >The following sentence reads: > > This strategy also provides a mechanism to verify the NETCONF/RESTCONF > server... > >Would the following clarify what is being verified? > > This strategy also provides a mechanism to verify the identity of the > NETCONF/RESTCONF server... ^^^^^^^^^^^^^^^ Agreed - done! >=20 >=20 >Section 3.2, sixth paragraph: >----------------------------- > >One of the sentences reads: > > This strategy's use of PKI enables a NETCONF/RESTCONF client to > transparently authenticate NETCONF/RESTCONF servers > >Would it be appropriate to change the text to read: > > This strategy's use of PKI enables a NETCONF/RESTCONF client to > transparently authenticate the identity of NETCONF/RESTCONF servers We're really talking about authenticated the certificate here, so I change this as follows instead: - transparently authenticate NETCONF/RESTCONF servers + transparently authenticate the NETCONF/RESTCONF server's certificate >This is the only paragraph where the term "authenticate" is used. Verify and authenticate are synonyms - these aren't technical words. I'm using them interchangeably throughout the draft (more than just this paragraph). I don't think this is an issue, does anyone else? Thanks again, Kent From nobody Fri Jan 16 17:54:56 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC981A9125 for ; Fri, 16 Jan 2015 17:54:52 -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 RAX_v6_Y7mYp for ; Fri, 16 Jan 2015 17:54:48 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0746.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::746]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EF11A90F1 for ; Fri, 16 Jan 2015 17:54:47 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.53.17; Sat, 17 Jan 2015 01:54:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.151]) with mapi id 15.01.0053.000; Sat, 17 Jan 2015 01:54:23 +0000 From: Kent Watsen To: Alan Luchuk , "netconf@ietf.org" Thread-Topic: draft-ietf-netconf-server-model-05 Thread-Index: AQHQMfiDOOWWRch7+EWij4CRQEiXKg== Date: Sat, 17 Jan 2015 01:54:22 +0000 Message-ID: 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.241.13] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 04599F3534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(41574002)(43784003)(189002)(2656002)(19580395003)(83506001)(54356999)(62966003)(2501002)(97736003)(77156002)(101416001)(122556002)(64706001)(66066001)(230783001)(87936001)(92566002)(99286002)(105586002)(106116001)(15975445007)(2900100001)(102836002)(68736005)(50986999)(86362001)(36756003)(40100003)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <2CE4F3EF2FA83E4B863130C520D763D2@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2015 01:54:22.9048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Cc: "jshoenwaelder@jacobs-university.de" Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 01:54:52 -0000 Hi Alan, Another very thorough review - thank you! Below are responses to your questions. Thanks Kent >Page 6, Section 2.4, typo >------------------------- > >s/mapping to be configured."/mapping to be configured./ > >(Delete the quotation mark.) Done, thanks! >Page 7, Section 2.6.6, possible improper hyphenation >---------------------------------------------------- > >The text reads: > > If a persistent connection is desired, it is the responsibility of > the connection-initiator to actively test > >Not sure, but I think "connection-initiator" should not be hyphenated. Agreed, removed. >Page 8, Section 3.1.1, clarification >------------------------------------ > > module: ietf-netconf-server > +--rw netconf-server > +--rw session-options {session-options}? > +--rw hello-timeout? uint32 > +--rw idle-timeout? uint32 > > >The meaning of the braces { } around session-options initially was not >clear. It appeared to be a typo instead of brackets [ ]. After a lot >of looking at the usage of the braces, it appears to indicate when the >"session-options" feature is present? > >Perhaps adding something like the following explanation to section 1.2 >(on Pages 4 and 5): > > o Braces "{" and "}" enclose feature names, and indicate that the > named feature must be present for the following part of the data > model to be present. Agreed, added. >Page 14, Section 3.2, ietf-netconf-server.yang, nit >--------------------------------------------------- > > grouping session-options-container { > description > ""; > container session-options { > >I suggest removing the empty description. I think the reason/purpose of >the grouping is obvious enough that a description clause does not assist >the reader's understanding. > >Many of the grouping statements in the ietf-netconf-server.yang module >and the ietf-restconf-server.yang module have empty descriptions. This >same comment applies to them also. The empty descriptions are an annoying artifact of the `pyang --ietf` option requiring descriptions on these nodes. But I agree that no description is needed and that it looks odd as is. I could copy/paste the entire description or has one reference the other...hmm, how about this - look for "(see above)" below: OLD: grouping session-options-container { description ""; container session-options { description "NETCONF session options, independent of transport or connection strategy."; NEW: grouping session-options-container { description "NETCONF session options, independent of transport or connection strategy."; container session-options { description "(see above)"; If not, do yo have a better suggestion? >Page 18, Section 3.2, ietf-netconf-server.yang, nit >--------------------------------------------------- > > container connection-type { > description > "Indicates the kind of connection to be maintained."; > choice connection-type { > default persistent-connection; > >Possibly change "maintained" to "used"? > >Persistent connections might be "maintained"; but "maintaining" a >periodic connection seems confusing. Agreed - done. >Page 19, Section 3.2, ietf-netconf-server.yang, clarification >------------------------------------------------------------- > > leaf linger-secs { > type uint8; > units seconds; > default 30; > description > "The amount of time the NETCONF server should wait > after last receiving data from or sending data to > the NETCONF client's endpoint before closing its > connection to it. This is an optimization to > prevent unnecessary connections."; > } > >In the behavior of the periodic connection (with the 30 second >linger-secs),=20 >what happens if the NETCONF server holds the idle periodic connection >open=20 >for 29 seconds, then another message is exchanged on that connection? > >Based upon the description clause, I would expect the message would reset >a linger timer, so the server would wait another 30 seconds before closing >the connection. This behavior is not completely spelled out, though. Yes, this is the expected behavior - does it need to be spelled out? >In this scenario, if one of the NETCONF peers repeatedly sends a message >just before the linger timeout expires, the periodic connection will >never=20 >be closed. Is this the desired behavior for the periodic connection, or >would it make sense to have timer that forces a close after a certain >maximum time period? Yes, it could turn out that the "periodic" connection stays open forever due to always having activity. This is the desired behavior, as the goal is to avoid the computationally-expensive reconnection. >This same comment applies to other linger-secs values in the >ietf-netconf-server.yang module and the ietf-restconf-server.yang >module. Understood, but I currently don't believe the text is inaccurate. I'm not planning to make any changes yet... >Page 21, Section 3.2, ietf-netconf-server.yang, nit >--------------------------------------------------- > > grouping tls-container { > description > ""; > container tls { > description > "Configures TLS properties not specific to the listen > or call-home use-cases"; > >Perhaps change the description text to: > > description > "Configures TLS properties for authenticating clients."; Agreed - done! >Are there other possibilities are there other than the listen or call-home >use cases? There may be, but your point is that it's better to say what you do rather than what you don't do, which is spot on. >Page 23, Section 3.2, ietf-netconf-server.yang, question >-------------------------------------------------------- > > grouping certificates-container { > description > ""; > container certificates { > description > "Parent container for the list of certificates."; > leaf-list certificate { > type string; > min-elements 1; > description > "An unordered list of certificates the TLS server can pick > from when sending its Server Certificate message. The value > of the string is the unique identifier for a certificate > configured on the system. How valid values are discovered > is outside the scope of this module, but they are envisioned > to be the keys for a list of certificates provided > by another YANG module"; > reference > "RFC 5246: The TLS Protocol, Section 7.4.2"; > } > } > } > > >What happens if the min-elements is not satisfied? How is this possible? A TLS server must have a server-cert defined... >Also, what is the use case for the server having more than one >certificate=20 >it can send in it Server Certificate message? How would the server >choose=20 >which certificate to send in its Server Certificate message? Does this >description need a comment about "How a certificate is chosen for sending >in a Server Certificate message is outside the scope of this module"? The server may have more than one certificate using different algorithms or key-strengths. The server may use one certificate for when listening on port 6513 and another when it calls home. >These questions also apply to the certificates-container grouping in the >ietf-restconf-server.yang module. Understood, but no change planned yet. >Page 25, Section 3.2, ietf-netconf-server.yang, clarification >------------------------------------------------------------- > > strategy). The interval timer is reset after each > transmission, thus an unresponsive NETCONF client will > be dropped after ~count-max * interval-secs seconds."; > >I suggest changing the text to: > > strategy). The interval timer is reset after each > transmission, thus an unresponsive NETCONF client will > be dropped after approximately (count-max * interval-secs) > seconds."; > >Upon a first read of this description, the tilde ~ looked like the >C-language operator. I had to think about the text a bit more. > >This same comment applies in the ietf-restconf-server.yang module, on >page 36. Right you are, this was slang text - fixed. >Page 26, Section 4.1.1, typo >---------------------------- > >The text reads: > > module enables configuration for listening for remote connections, as > described in [draft-ietf-netconf-restconf] and > [draft-ietf-netconf-call-home]. Feature statements are used to limit > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >Should the text be changed to delete the flagged text above and read >as follows? > > module enables configuration for listening for remote connections, as > described in [draft-ietf-netconf-restconf]. Yes, done. >Also, the text reads: > > to use (i.e. SSH, TLS), and the IP address and port to listen on. > ^^^ > >Should the text be changed to delete the flagged text above and read >as follows? > > to use (i.e. TLS), and the IP address and port to listen on. Correct, for RESTCONF, only TLS is supported (copy/paste error) >Page 27, Section 4.1.2, typo >---------------------------- > >The text reads: > > the transport to be used (i.e. SSH, TLS), and a list of remote > ^^^ > >Should the text be changed to delete the flagged text above and read >as follows? > > the transport to be used (i.e. TLS), and a list of remote Correct again, for RESTCONF, only TLS is supported (copy/paste error) >Page 30, Section 4.2, ietf-restconf-server.yang, nit >---------------------------------------------------- > > list endpoint { > key name; > description > "List of endpoints to listen for connections on."; > leaf name { > type string; > description > "An arbitrary name for the listen endpoint."; > } > >Should RESTCONF be added to these descriptions like so? > > list endpoint { > key name; > description > "List of endpoints to listen for RESTCONF connections on."; > leaf name { > type string; > description > "An arbitrary name for the RESTCONF listen endpoint."; > } Sure, and I made the comparable change to the ietf-netconf-server.yanf file as well >Page 30, Section 4.2, ietf-restconf-server.yang, question >--------------------------------------------------------- > >The following snippet of the data model uses "mandatory true;". > > choice transport { > mandatory true; > description > "Selects between available transports."; > case tls { > container tls { > >I have no idea, but should more schema nodes in both the ietf-restconf- >server.yang module and the ietf-netconf-server.yang module be marked by >"mandatory true;"? I think that they are all set correctly...I just checked >The correct use of the "mandatory true" is unclear to me, based upon >the description of the "mandatory" statement in sections 3.1, 7.6.5, >7.9.4, of RFC 6020. But that is a side issue. Key fields are implicitly mandatory. Fields that have default values are explicitly not-mandatory. Marking a node mandatory means that end-user config is required. For instance, the end-user *must* supply an IP address to connect to for call-home connections (that's mandatory=3Dtrue) >Correctly identifying schema nodes with "mandatory true" seems high-effort >and relatively low value. The best way to address this particular >comment=20 >might be to ignore it. Too late! ;) >Page 30, Section 4.2, ietf-restconf-server.yang, question >---------------------------------------------------------- > > case tls { > container tls { > description > "TLS-specific listening configuration for inbound > connections."; > uses address-and-port-grouping { > refine port { > default 6513; > } > } > uses certificates-container; > } > } > >Is refining the default value for the port to 6513 intentional, or a >cut-and-paste error? This is the same port number IANA assigned for >NETCONF over TLS. It was. This was previously fixed here: https://github.com/netconf-wg/server-model/issues/26 >Page 31, Section 4.2, ietf-restconf-server.yang, typo >----------------------------------------------------- > > choice transport { > mandatory true; > description > "Selects between SSH and TLS transports."; > ^^^^^^^^^^^ > >Should the "SSH and TLS" be removed? Is it envisioned that RESTCONF >may operate over transports other than TLS, or should this not even >be a choice because only TLS is supported? Fixed. I had purposely left the choice to cover future augmentations. >Page 36, Section 4.2, ietf-restconf-server.yang, wording >-------------------------------------------------------- > > grouping keep-alives-container { > description > ""; > container keep-alives { > description > "Configures the keep-alive policy, to proactively test the > aliveness of the RESTCONF client, in order to know when a > new call home connection should be established."; > ^^^^^^^^^ > >The listen-container grouping on Page 30 also uses the >keep-alives-container, >so perhaps this description text should not be specific to call home. Right you are. Fixed in ietf-netconf-server.yang as well. >Page 38, Section 6, "Security Considerations", technical >-------------------------------------------------------- > >The text reads: > > There are a number of data nodes defined in the "ietf-netconf-server" > YANG module which are readable and/or writable that may be considered > sensitive or vulnerable in some network environments. Write and read > operations to these data nodes can have a negative effect on network > operations. It is thus important to control write and read access to > these data nodes. Below are the data nodes and their sensitivity/ > vulnerability. > >Then lists a few containers considered security sensitive. > >Am I missing something, but shouldn't way more schema nodes than just >the few listed in section 6 be recognized as security sensitive? > >As an example, in the ietf-netconf-server.yang module, aren't the >following >nodes security sensitive? > > module: ietf-netconf-server > +--rw netconf-server > +--rw listen {listen}? > +--rw max-sessions? uint16 > +--rw endpoint* [name] > +--rw name string > +--rw (transport) > | +--:(ssh) {ssh}? > | | +--rw ssh > | | +--rw address? inet:ip-address > | | +--rw port? inet:port-number > | | +--rw host-keys > | | +--rw host-key* string > | +--:(tls) {tls}? > | +--rw tls > | +--rw address? inet:ip-address > | +--rw port? inet:port-number > | +--rw certificates > | +--rw certificate* string > +--rw keep-alives > +--rw interval-secs? uint8 > +--rw count-max? uint8 > >If these nodes aren't properly secured, then couldn't an attacker >just delete all of the listen endpoints, and disable access to the >server? Losing control of the NETCONF server (and presumably the >network device it runs on) seems like it fits the description of >adversely affect network operations, and so should be listed under >security considerations. > >The same could be said of the call-home nodes, and probably other nodes. This issue is addressed here: https://github.com/netconf-wg/server-model/issues/24 This is a bit tricky. On one hand, the entire configuration has to be protected from unauthorized access and modification. But with NACM, the issue is notched up a level to cover what *authorized* users are allowed to access and/or modify. I'll look at this again when working on #24... Thanks again, Kent From nobody Fri Jan 16 19:34:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71E1B2A20 for ; Fri, 16 Jan 2015 19:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 daP018p4hFzh for ; Fri, 16 Jan 2015 19:34:10 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183071B2A13 for ; Fri, 16 Jan 2015 19:34:10 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so19917693qcv.8 for ; Fri, 16 Jan 2015 19:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=2AEjuqZPXbfe7ztlLcCT0gcN7tgl5K/dW7k4jJO1EA0=; b=MGhPssUIkZcZKuMny3Qjx6mlmjDPsO1pNXNCGxZiciOFtbdFOp3Y5KPNnChL/WtM0/ NRlCZo/RQp5pYW92tjb83+XjzKbiZSjg+B1AXTAgzqFn7XH5+fSJoSeTXNAp8lufnew0 WAUBMYu1oGid9i2pnb/C2onZhhfQPldI1HadYBeE5ar+/fGKnc5Rnu2zvplbIuG35eJy 2Ec5L97F+XcVv6tsEDmQV9uvykSBTIb2hGJf5TTb8DIj9MtjdL+zwSV21XdNYesXTEPW D43gxwLNvl1SlMYzWE8MPVnzQ9QRFQJSXgs1FeaJDVniMpbpqhk6oJhY6Ekt6+W3GWfp +RMw== X-Received: by 10.140.109.164 with SMTP id l33mr15924300qgf.91.1421465649300; Fri, 16 Jan 2015 19:34:09 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id o34sm5926274qge.29.2015.01.16.19.34.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Jan 2015 19:34:08 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_E52EADF3-BDE2-4470-94B6-46ADE15BE592" Date: Fri, 16 Jan 2015 19:34:06 -0800 Message-Id: To: Netconf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [Netconf] NETCONF Virtual Meeting for Monday, January 19 is canceled. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 03:34:11 -0000 --Apple-Mail=_E52EADF3-BDE2-4470-94B6-46ADE15BE592 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Monday turns out to be a national holiday in the US, with many companies = shut down that day. The virtual meeting for this Monday, January 19th is = therefore canceled. We will discuss the agenda already posted (with any = additions that come up) in the next meeting, currently scheduled to = happen on February 2. Cheers. Mahesh & Mehmet. --Apple-Mail=_E52EADF3-BDE2-4470-94B6-46ADE15BE592 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Monday turns out to be a national holiday in the US, with many companies shut down that day. The virtual meeting for this Monday, January 19th is therefore canceled. We will discuss the agenda already posted (with any additions that come up) in the next meeting, currently scheduled to happen on February 2.

Cheers.

Mahesh & Mehmet.





--Apple-Mail=_E52EADF3-BDE2-4470-94B6-46ADE15BE592-- From nobody Sun Jan 18 07:50:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484001B2A0E for ; Sun, 18 Jan 2015 07:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 FPB6CLYztNTu for ; Sun, 18 Jan 2015 07:50:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990781B2A0D for ; Sun, 18 Jan 2015 07:50:44 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t0IFog3E017049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 18 Jan 2015 15:50:42 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0IFofY4016502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 18 Jan 2015 16:50:42 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0195.001; Sun, 18 Jan 2015 16:50:41 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AdApKKHQsmh1voQ5Sgudn5IwYOG+2QEX2N2gAWsoaTA= Date: Sun, 18 Jan 2015 15:50:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8195D1A2BDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 45597 X-purgate-ID: 151667::1421596242-000067C4-DC047289/0/0 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 15:50:48 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195D1A2BDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, we did not get any comments yet on rfc5539bis draft during the WGLC. Please review and provide your comments on the document and/or please indicate if you think the document is ready for publication. If we do not get any comments or support by the deadline (January 19, 2015 = EOB PT) the WGLC will be seen as unsuccessful. Regards, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Sunday, January 11, 2015 5:58 PM To: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 All, this is a friendly reminder on the WGLC we started on January 5th for draft= -ietf-netconf-rfc5539bis-07. Please review and send your comments to the WG mailing. If you have read the document but don't have any comments, please state whe= ther you support the publication. Thanks, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Monday, January 05, 2015 9:46 PM To: netconf@ietf.org Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Dear NETCONF Members, we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. The document can be found at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 Please review and send your comments to the WG mailing list by January 19, = 2015 EOB PT. The document is planned to publish as a standard track document. As a minimum please state that you have read/reviewed and whether you suppo= rt the publication. Please indicate also if you plan to implement or have already implementatio= n experience with the rfc5539bis draft. Thank you. Mehmet and Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F8195D1A2BDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear NETCONF WG,

=  

= we did not get any comments yet on rfc5539bis draft during the WGLC.

=  

Please review and provide your comments on the document and/or=

please indicate if you think the document is ready for publication<= /span>.        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      

=  

= If we do not get any comments or support by the deadline (January 19, 2015 EOB PT) the WGLC will be seen as unsuccessful.<= o:p>

=  

= Regards,
Mehmet

=  

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Sunday, January 11, 20= 15 5:58 PM
To: netconf@ietf.org
Subject: Re: [Netconf] WG La= st Call for draft-ietf-netconf-rfc5539bis-07

 

= All,=

=  

= this is a friendly rem= inder on the WGLC we started on January 5th for draft-ietf-netco= nf-rfc5539bis-07.

=  

= Please review= and send your comments to the WG mailing.

If you have read the document but don’t have any comments, please= state whether you support the publication.=   

=  

= Thanks,
Mehmet

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Ersue, Mehm= et (NSN - DE/Munich)
Sent: Monday, January 05, 20= 15 9:46 PM
To: netconf@ietf.org
Subject: [Netconf] WG Last C= all for draft-ietf-netconf-rfc5539bis-07

 

= Dear NETCONF Members,

=  

= we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07.

=  

= The document can be found at:<= /o:p>

=  

= Please review and send your comments to the WG mailing list by January 19, 2015 EOB PT.

=  

= The document is planned to publish as a standard track document.<= /font>

= As a minimum please state that you have read/reviewed and whether you support the publication.

=  

= Please indicate also if you plan to implement or have already implementa= tion experience with the rfc5539bis draft.=  

= Thank you.=

= Mehmet and Mahesh=

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F8195D1A2BDEMUMBX005nsnin_-- From nobody Sun Jan 18 08:04:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549711B2A07 for ; Sun, 18 Jan 2015 08:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 qjSs6pH_qQsh for ; Sun, 18 Jan 2015 08:04:25 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8471C1B2A04 for ; Sun, 18 Jan 2015 08:04:24 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t0IG4M7A012391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 18 Jan 2015 16:04:22 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0IG4MR2022376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 18 Jan 2015 17:04:22 +0100 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 18 Jan 2015 17:04:21 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Sun, 18 Jan 2015 17:04:21 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AdApKKHQsmh1voQ5Sgudn5IwYOG+2QEX2N2gAWsoaTAAAHz5UA== Date: Sun, 18 Jan 2015 16:04:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8195D1A49DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 51368 X-purgate-ID: 151667::1421597062-00007286-B8FDAB95/0/0 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 16:04:28 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8195D1A49DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, technically spoken, I support the publication of 5539bis draft. It is well-written and addresses the issues we discussed appropriately. There are two minor issues concerning outdated references. - there is a -08 version available for draft-ietf-uta-tls-bcp-07 - RFC4742 has been replaced by RFC6242 Cheers, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Sunday, January 18, 2015 4:51 PM To: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Dear NETCONF WG, we did not get any comments yet on rfc5539bis draft during the WGLC. Please review and provide your comments on the document and/or please indicate if you think the document is ready for publication. If we do not get any comments or support by the deadline (January 19, 2015 = EOB PT) the WGLC will be seen as unsuccessful. Regards, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Sunday, January 11, 2015 5:58 PM To: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 All, this is a friendly reminder on the WGLC we started on January 5th for draft= -ietf-netconf-rfc5539bis-07. Please review and send your comments to the WG mailing. If you have read the document but don't have any comments, please state whe= ther you support the publication. Thanks, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Monday, January 05, 2015 9:46 PM To: netconf@ietf.org Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Dear NETCONF Members, we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. The document can be found at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 Please review and send your comments to the WG mailing list by January 19, = 2015 EOB PT. The document is planned to publish as a standard track document. As a minimum please state that you have read/reviewed and whether you suppo= rt the publication. Please indicate also if you plan to implement or have already implementatio= n experience with the rfc5539bis draft. Thank you. Mehmet and Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F8195D1A49DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi All,

=  

= technically spoken, I support the publication of 5539bis draft.

=  

= It is well-written and addresses the issues we discussed appropriately.

=  

= There are two minor issues concerning outdated references.

= - there is a -08 version available for draft-iet= f-uta-tls-bcp-07

= - RFC4742 has been replaced by RFC6242

=  

= Cheers,
Mehmet

=  

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Sunday, January 18, 20= 15 4:51 PM
To: netconf@ietf.org
Subject: Re: [Netconf] WG La= st Call for draft-ietf-netconf-rfc5539bis-07

 

= Dear NETCONF WG,<= /o:p>

=  

= we did not get any com= ments yet on rfc5539bis draft during the WGLC.

=  

Please review and provide your comments on the document and/or=

please indicate if you think the document is ready for publication<= /span>.        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      

=  

= If we do not get any c= omments or support by the deadline (January 19, 2015 EOB PT) the WGLC will be seen as unsuccessful.

=  

= Regards,
Mehmet

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Ersue, Mehm= et (NSN - DE/Munich)
Sent: Sunday, January 11, 20= 15 5:58 PM
To: netconf@ietf.org
Subject: Re: [Netconf] WG La= st Call for draft-ietf-netconf-rfc5539bis-07

 

= All,=

=  

= this is a friendly rem= inder on the WGLC we started on January 5th for draft-ietf-netco= nf-rfc5539bis-07.

=  

= Please review= and send your comments to the WG mailing.

If you have read the document but don’t have any comments, please= state whether you support the publication.=   

=  

= Thanks,
Mehmet

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Ersue, Mehm= et (NSN - DE/Munich)
Sent: Monday, January 05, 20= 15 9:46 PM
To: netconf@ietf.org
Subject: [Netconf] WG Last C= all for draft-ietf-netconf-rfc5539bis-07

 

= Dear NETCONF Members,

=  

= we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07.

=  

= The document can be found at:<= /o:p>

=  

= Please review and send your comments to the WG mailing list by January 19, 2015 EOB PT.

=  

= The document is planned to publish as a standard track document.<= /font>

= As a minimum please state that you have read/reviewed and whether you support the publication.

=  

= Please indicate also if you plan to implement or have already implementa= tion experience with the rfc5539bis draft.=  

= Thank you.=

= Mehmet and Mahesh=

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F8195D1A49DEMUMBX005nsnin_-- From nobody Sun Jan 18 12:09:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99E21ACE13 for ; Sun, 18 Jan 2015 12:09:14 -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 p3s7mQJtcf6b for ; Sun, 18 Jan 2015 12:09:12 -0800 (PST) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) by ietfa.amsl.com (Postfix) with ESMTP id BB3F01ACE09 for ; Sun, 18 Jan 2015 12:09:12 -0800 (PST) Received: from [192.168.2.35] ([73.8.162.228]) by p3plsmtpa07-07.prod.phx3.secureserver.net with id hY9A1p00A4vySjM01Y9BP2; Sun, 18 Jan 2015 13:09:11 -0700 Message-ID: <54BC12E7.1010103@seguesoft.com> Date: Sun, 18 Jan 2015 14:09:11 -0600 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: netconf@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050406080604090905000501" Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 20:09:15 -0000 This is a multi-part message in MIME format. --------------050406080604090905000501 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi I have read this draft. I support its publication as a RFC. We will implement it. Just a minor comment : In "Introduction", currently it reads: ... Implementations MUST support mutual TLS certificate-based authentication [RFC5246]. This assures the NETCONF server of the identity of the principal who wishes to manipulate the management information. It assures the NETCONF client of the identity of the server for which it wishes to manipulate the management information. I think an "also" should be added in the last sentence in the paragraph above. I.e.: ... Implementations MUST support mutual TLS certificate-based authentication [RFC5246]. This assures the NETCONF server of the identity of the principal who wishes to manipulate the management information. It*also* assures the NETCONF client of the identity of the server for which it wishes to manipulate the management information. Thanks -Xiang On 1/5/2015 2:46 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF Members, > we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. > The document can be found at: > _http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis__-07_ > > Please review and send your comments to the WG mailing list by January > 19, 2015 EOB PT. > The document is planned to publish as a standard track document. > As a minimum please state that you have read/reviewed and whether you > support the publication. > Please indicate also if you plan to implement or have already > implementation experience with the rfc5539bis draft. > Thank you. > Mehmet and Mahesh > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- -- Xiang Li, Seguesoft, Champaign, IL (217) 721-5341 --------------050406080604090905000501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi

I have read this draft. I support its publication as a RFC.  We will implement it.

Just a minor comment :

In "Introduction", currently it reads:

   ... Implementations MUST support mutual TLS certificate-based authentication [RFC5246].  This
   assures the NETCONF server of the identity of the principal who
   wishes to manipulate the management information.  It assures the
   NETCONF client of the identity of the server for which it wishes to
   manipulate the management information.

I think an "also" should be added in the last sentence in the paragraph above. I.e.:

   ... Implementations MUST support mutual TLS certificate-based authentication [RFC5246].  This
   assures the NETCONF server of the identity of the principal who
   wishes to manipulate the management information.  It also assures the
   NETCONF client of the identity of the server for which it wishes to
   manipulate the management information.


Thanks

-Xiang


On 1/5/2015 2:46 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:
Dear NETCONF Members,
 
we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07.
 
The document can be found at:
 
Please review and send your comments to the WG mailing list by January 19, 2015 EOB PT.
 
The document is planned to publish as a standard track document.
As a minimum please state that you have read/reviewed and whether you support the publication.
 
Please indicate also if you plan to implement or have already implementation experience with the rfc5539bis draft.
 
Thank you.
Mehmet and Mahesh
 
 
 

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


-- 
--
Xiang Li, 
Seguesoft, Champaign, IL
(217) 721-5341
--------------050406080604090905000501-- From nobody Mon Jan 19 04:45:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDC11B2A51 for ; Mon, 19 Jan 2015 04:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 gr6Dfi6T6mwZ for ; Mon, 19 Jan 2015 04:45:41 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1B01B2A26 for ; Mon, 19 Jan 2015 04:45:41 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id ACDA7F91; Mon, 19 Jan 2015 13:45: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 uEkLZ3jpnKNz; Mon, 19 Jan 2015 13:45:37 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 19 Jan 2015 13:45:39 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DF112002F; Mon, 19 Jan 2015 13:45:39 +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 JN3_8GVwYfeJ; Mon, 19 Jan 2015 13:37: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 2BD092002C; Mon, 19 Jan 2015 13:45:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C06A330BFEA7; Mon, 19 Jan 2015 13:45:38 +0100 (CET) Date: Mon, 19 Jan 2015 13:45:38 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20150119124538.GB13496@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@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: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 12:45:43 -0000 On Sun, Jan 18, 2015 at 04:04:21PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > technically spoken, I support the publication of 5539bis draft. > > It is well-written and addresses the issues we discussed appropriately. > > There are two minor issues concerning outdated references. > - there is a -08 version available for draft-ietf-uta-tls-bcp-07 This is a tool synchronization issue and will resolve itself. > - RFC4742 has been replaced by RFC6242 The reference to RFC4742 must stay as is, see the text in section 3. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 19 04:47:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA231B2A18 for ; Mon, 19 Jan 2015 04:46: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 c1Gd--ubSyme for ; Mon, 19 Jan 2015 04:46:57 -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 CA3CD1B2A26 for ; Mon, 19 Jan 2015 04:46: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 9DD301013; Mon, 19 Jan 2015 13:46:55 +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 Lke2SOFVeM7c; Mon, 19 Jan 2015 13:46: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; Mon, 19 Jan 2015 13:46:54 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB59C2002F; Mon, 19 Jan 2015 13:46:54 +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 Z3R2Sm4a1BYl; Mon, 19 Jan 2015 13:46: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 90EDB2002C; Mon, 19 Jan 2015 13:46:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3225A30BFEE4; Mon, 19 Jan 2015 13:46:54 +0100 (CET) Date: Mon, 19 Jan 2015 13:46:54 +0100 From: Juergen Schoenwaelder To: Xiang Li Message-ID: <20150119124654.GC13496@elstar.local> Mail-Followup-To: Xiang Li , netconf@ietf.org References: <54BC12E7.1010103@seguesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BC12E7.1010103@seguesoft.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 12:46:58 -0000 OK /js On Sun, Jan 18, 2015 at 02:09:11PM -0600, Xiang Li wrote: > Hi > > I have read this draft. I support its publication as a RFC. We will > implement it. > > Just a minor comment : > > In "Introduction", currently it reads: > > ... Implementations MUST support mutual TLS certificate-based > authentication [RFC5246]. This > assures the NETCONF server of the identity of the principal who > wishes to manipulate the management information. It assures the > NETCONF client of the identity of the server for which it wishes to > manipulate the management information. > > I think an "also" should be added in the last sentence in the paragraph > above. I.e.: > > ... Implementations MUST support mutual TLS certificate-based > authentication [RFC5246]. This > assures the NETCONF server of the identity of the principal who > wishes to manipulate the management information. It*also* assures the > NETCONF client of the identity of the server for which it wishes to > manipulate the management information. > > > Thanks > > -Xiang > > > On 1/5/2015 2:46 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > >Dear NETCONF Members, > >we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. > >The document can be found at: > >_http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis__-07_ > > > >Please review and send your comments to the WG mailing list by January > >19, 2015 EOB PT. > >The document is planned to publish as a standard track document. > >As a minimum please state that you have read/reviewed and whether you > >support the publication. > >Please indicate also if you plan to implement or have already > >implementation experience with the rfc5539bis draft. > >Thank you. > >Mehmet and Mahesh > > > > > >_______________________________________________ > >Netconf mailing list > >Netconf@ietf.org > >https://www.ietf.org/mailman/listinfo/netconf > > -- > -- > Xiang Li, > Seguesoft, Champaign, IL > (217) 721-5341 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 19 04:52:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C515F1AD218 for ; Mon, 19 Jan 2015 01:26:57 -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 Ba3SV04ter69 for ; Mon, 19 Jan 2015 01:26:55 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9016A1AD37C for ; Mon, 19 Jan 2015 01:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3516; q=dns/txt; s=iport; t=1421659614; x=1422869214; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iH4/+HwQ/9Bcb9eTNWX4CcUChkJr75GB2PE6BM4OZOo=; b=EHMKyl9Ff9HioSbFojO/OtmOytIAPQI8B9h5U5hS5fWRTSd0hmhauwUZ Qhz846F+4bGLfRnx+02Zo8JLX9rk6rUdmQOttY2/y4Hv+R22bA+ubnRsZ dOLxZfP7UJHuroskY0GGwoImliiTo+v6xJHSnCLoK9DufS0B70tDbxMpi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsFAGXNvFStJA2G/2dsb2JhbABbgwZSXIMCwQaCGwqFJ0oCHIEEQwEBAQEBfYQMAQEBAwEBAQEgETMHCwwEAgEIEQQBAQECAgYdAwICAiULFAEICAEBBA4FCIgcCA26VJNlAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhjicxBwaCYi6BEwWOWZtBIoNubwGBRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,425,1418083200"; d="scan'208";a="384978992" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jan 2015 09:26:53 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t0J9QrnX031498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Jan 2015 09:26:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 03:26:53 -0600 From: "Julius Milan -X (jumilan - Pantheon Technologies SRO at Cisco)" To: Andy Bierman Thread-Topic: [Netconf] message-id attribute value normalization Thread-Index: AdAxtS/196KFVEGPQJGaq2NUav0z1QAQ1GqAAHN/SxA= Date: Mon, 19 Jan 2015 09:26:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.163.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 19 Jan 2015 04:52:27 -0800 Cc: "Rastislav Szabo -X \(raszabo - Pantheon Technologies SRO at Cisco\)" , "Stefan Kobza -X \(skobza - Pantheon Technologies SRO at Cisco\)" , "netconf@ietf.org" , "Anna Medvedova -X \(amedvedo - Pantheon Technologies SRO at Cisco\)" Subject: Re: [Netconf] message-id attribute value normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 09:26:57 -0000 T2ssDQpCdXQgc3RpbGwgcmVtYWlucyBmb2xsb3dpbmcgaW5jb25zaXN0ZW5jeSwgd2hpY2ggY291 bGQgbGl0dGxlIGJpdCBjb25mdXNlIG5ldGNvbmYgdXNlciBvciBkZXZlbG9wZXI6DQoNCjEuKSDi gJxUaGUgc2VuZGVyIE1VU1QgZW5zdXJlIHRoYXQgdGhlICJtZXNzYWdlLWlkIiB2YWx1ZSBpcyBu b3JtYWxpemVkDQphY2NvcmRpbmcgdG8g4oCmIGlmIHRoZSBzZW5kZXIgd2FudHMgdGhlIHN0cmlu ZyB0byBiZSByZXR1cm5lZCB1bm1vZGlmaWVkLuKAnQ0KDQoyLikgQW5kIHRoZSBmYWN0IHRoYXQg bWVzc2FnZS1pZCBzaG91bGQgbm90IGJlIG5vcm1hbGl6ZWQgYWNjb3JkaW5nIHRvIHNjaGVtYSAo bmV0Y29uZi54c2QpLg0KDQpJdCdzIGp1c3QgYSBkZXRhaWwsIGJ1dCB0aGVzZSAyIGZhY3RzIGFy ZSBpbiBjb25mbGljdC4NCg0KUmVnYXJkcywNCkp1bGl1cw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21d IA0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDE2LCAyMDE1IDg6NTQgUE0NClRvOiBKdWxpdXMgTWls YW4gLVggKGp1bWlsYW4gLSBQYW50aGVvbiBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKQ0KQ2M6 IG5ldGNvbmZAaWV0Zi5vcmc7IHVsZmJlcmh0LWRldihtYWlsZXIgbGlzdCk7IEFubmEgTWVkdmVk b3ZhIC1YIChhbWVkdmVkbyAtIFBhbnRoZW9uIFRlY2hub2xvZ2llcyBTUk8gYXQgQ2lzY28pDQpT dWJqZWN0OiBSZTogW05ldGNvbmZdIG1lc3NhZ2UtaWQgYXR0cmlidXRlIHZhbHVlIG5vcm1hbGl6 YXRpb24NCg0KT24gRnJpLCBKYW4gMTYsIDIwMTUgYXQgOTo1MiBBTSwgSnVsaXVzIE1pbGFuIC1Y IChqdW1pbGFuIC0gUGFudGhlb24gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbykgPGp1bWlsYW5A Y2lzY28uY29tPiB3cm90ZToNCj4gSGkgYWxsLA0KPg0KPg0KPg0KPiBJIGhhdmUgb25lIGRldGFp bCByZWdhcmRpbmcgUkZDIDYyNDEuDQo+DQo+IEluIG5ldGNvbmYueHNkIGlzIGF0dHJpYnV0ZSBt ZXNzYWdlLWlkIGRlZmluZWQgYXMgc3RyaW5nLg0KPg0KPiBUeXBlIHN0cmluZyBpcyBkZWZpbmVk DQo+IChodHRwOi8vd3d3LnNjaGVtYWNlbnRyYWwuY29tL3NjL3hzZC90LXhzZF9zdHJpbmcuaHRt bCkgdG8gYmUgDQo+IG5vbi1ub3JtYWxpemVkLg0KPg0KPiBTbyBhbGwgd2hpdGVzcGFjZSBjaGFy YWN0ZXJzIChzcGFjZXMsIHRhYnMsIGNhcnJpYWdlIHJldHVybnMsIGFuZCBsaW5lDQo+IGZlZWRz KSBtdXN0IGJlIHByZXNlcnZlZCBieSB0aGUgcHJvY2Vzc29yLg0KPg0KPg0KPg0KPiBIb3dldmVy IGluIHJmYyBpcyBhbHNvIHdyaXR0ZW46DQo+DQo+IOKAnFRoZSBzZW5kZXIgTVVTVCBlbnN1cmUg dGhhdCB0aGUgIm1lc3NhZ2UtaWQiIHZhbHVlIGlzIG5vcm1hbGl6ZWQNCj4NCj4gYWNjb3JkaW5n IHRvIOKApiBpZiB0aGUgc2VuZGVyIHdhbnRzIHRoZSBzdHJpbmcgdG8gYmUgcmV0dXJuZWQgdW5t b2RpZmllZC7igJ0NCj4NCj4NCj4NCj4gSXMgaXQgaW50ZW5kZWQgdG8gaGF2ZSBhIG1lc3NhZ2Ut aWQgbm9uLW5vcm1hbGl6ZWQ/DQo+DQo+IFdvdWxkbuKAmXQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0 byBkZWZpbmUgaXQgYXMgbm9ybWFsaXplZFN0cmluZyANCj4gKGh0dHA6Ly93d3cuZGF0eXBpYy5j b20vc2MveHNkL3QteHNkX25vcm1hbGl6ZWRTdHJpbmcuaHRtbCk/DQo+DQo+IFdoaWNoIGlzIGJh c2ljYWxseSB0aGUgc2FtZSwganVzdCBwcm92aWRlcyBub3JtYWxpemF0aW9uIG9mIGFsbG93ZWQg DQo+IHdoaXRlc3BhY2UgY2hhcmFjdGVycw0KPg0KPiBhbmQgYXMgd3JpdHRlbiBpbiBzcGVjaWZp Y2F0aW9uIGFib3ZlOg0KPg0KPiDigJxUaGlzIHByb2Nlc3NpbmcgaXMgZXF1aXZhbGVudCB0byB0 aGUgcHJvY2Vzc2luZyBvZiBDREFUQSBhdHRyaWJ1dGUgDQo+IHZhbHVlcyBpbiBYTUwgMS4wLuKA nQ0KPg0KDQpUaGUgaW50ZW50IGlzIHRoYXQgPHJwYy1yZXBseT4gaGFzIGFsbCB0aGUgYXR0cmli dXRlcyB0aGF0IGFyZSBpbiA8cnBjPiBzdGFydC10YWcsIHVuY2hhbmdlZCBieSB0aGUgc2VydmVy LiBUaGUgc2VydmVyIHBhcnNlcyB0aGUgaW5wdXQgcGFyYW1ldGVycyBhbmQgdGhlbiByZXR1cm5z IHRoZSBhdHRyaWJ1dGUgZW5jb2Rpbmcgb2YgdGhlIHBhcnNlZCB2YWx1ZSBpbiA8cnBjLXJlcGx5 Pi4NCg0KVGhlIHNlcnZlciBpcyBub3Qgc3VwcG9zZWQgdG8gYWx0ZXIgdGhlc2UgYXR0cmlidXRl cy4NCg0KSXQgaXMgbm90IGNsZWFyIHdoZXRoZXIgInhtbG5zIiBhdHRyaWJ1dGVzIGhhdmUgdG8g YmUgcmV0dXJuZWQgdW5jaGFuZ2VkLg0KQSB2YWxpZCBYTUwgcGFyc2VyIHNob3VsZCBub3QgcmVs eSBvbiBzcGVjaWZpYyBwcmVmaXggbWFwcGluZ3MuDQoNCg0KPg0KPg0KPiBUaGFua3MsDQo+DQo+ IEp1bGl1cw0KPg0KDQpBbmR5DQoNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4N Cg== From rwilton@cisco.com Mon Jan 19 01:40:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E601AD370 for ; Mon, 19 Jan 2015 01:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.878 X-Spam-Level: X-Spam-Status: No, score=-6.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_ASCII_ART_SPACINGc=0.833, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, MANGLED_MEDS=2.3, 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 unzl_HMZUZ_H for ; Mon, 19 Jan 2015 01:40:36 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0021AD49F for ; Mon, 19 Jan 2015 01:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=204985; q=dns/txt; s=iport; t=1421660434; x=1422870034; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=8HrueF9UB0dzIKMQfcvDVsWifZSzy+oxszjCqEq7kPc=; b=dbuLDYdOE3aRjJlB8+isOvc4FuwRMixIt1xxCrvilxHRoq2uhVUXcNgQ 1IxK7NxqodCCIl5hQ7zlAPjXD1luStaq1/fdufcWvBLtj2U+n+X5qNtOG 1b8QIKNLDkOihYymAMyh3ZvJneE2k1f+I0DqJP577jlQ8ur6w3aZ+N81v 4=; X-Files: draft-ietf-netconf-restconf-04-rw.txt : 196963 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGAJPPvFStJssW/2dsb2JhbABRAQEIg1i9TYk8hWsEAgKBYwEBAQEBfYQNAQEEGgEMICsGARALDgYECQQLBwgHCQMCAQIBNBEGAQkDAQMCAgEBF4gRDb1ugX+OUAEBAQEBAQEBAQEBAQEBAQEBAQEBAReKD4R9AQoGAQMBAQQCAQYjFQwFBwkPhBEBBIQNgS2BDolggXiCCIFRgXeBFBAmgkaCHyGFLIJxgz0ig24+BC0BgQIBAQcXBoEaAQEB X-IronPort-AV: E=Sophos;i="5.09,425,1418083200"; d="txt'?scan'208";a="317593362" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 19 Jan 2015 09:40:28 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0J9eSfx030144; Mon, 19 Jan 2015 09:40:28 GMT Message-ID: <54BCD10B.1070408@cisco.com> Date: Mon, 19 Jan 2015 09:40:27 +0000 From: Robert Wilton 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 , netconf@ietf.org References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------030607030104020907040007" Archived-At: X-Mailman-Approved-At: Mon, 19 Jan 2015 04:52:27 -0800 Cc: "draft-ietf-netconf-restconf@tools.ietf.org" Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 09:49:00 -0000 This is a multi-part message in MIME format. --------------030607030104020907040007 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit [Adding netconf working group at Andy Bierman's request] Hi Kent, I've read though the attached draft (up to the point that the yang modules were defined), and I've attached a draft with some inline comments (marked with "RW:", 20 locations) where the intent of the text wasn't completely clear to me. In some places I found that it was clarified later in the doc, so may just need some forward references. Anyway, hopefully these are helpful and self explanatory, but let me know if you need me to clarify any of my comments. Cheers, Rob On 16/01/2015 17:40, Kent Watsen wrote: > No problem. > > Also, in case you are unaware, we're trying to put the final touches on > the draft now in preparation for last-call. As it seems you are looking > at it pretty carefully now, please report any other issues found. > > BTW, -03 is a bit outdated. The current, but not yet released, draft is > attached. > > Cheers, > Kent > > > > On 1/16/15, 12:35 PM, "Robert Wilton" wrote: > >> Thanks for the quick confirmation. >> >> Rob >> >> On 16/01/2015 16:47, Kent Watsen wrote: >>> Yes, this appears to be a typo - the "genre" line should've been >>> omitted. >>> >>> Thanks for reporting it! >>> >>> Kent >>> >>> >>> >>> On 1/16/15, 8:51 AM, "Robert Wilton" wrote: >>> >>>> Hi, >>>> >>>> I was just skimming over draft-ietf-netconf-restconf-03, for the >>>> description of "3.6. PATCH" on page 29, and the example was slightly >>>> confusing in that the description talks about just replacing the "year" >>>> field but the JSON patch includes both "genre" and "year". >>>> >>>> Is this just a typo? >>>> >>>> Thanks, >>>> Rob >>>> --------------030607030104020907040007 Content-Type: text/plain; charset=windows-1252; name="draft-ietf-netconf-restconf-04-rw.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-netconf-restconf-04-rw.txt" Network Working Group A. Bierman Internet-Draft YumaWorks Intended status: Standards Track M. Bjorklund Expires: July 20, 2015 Tail-f Systems K. Watsen Juniper Networks January 16, 2015 RESTCONF Protocol draft-ietf-netconf-restconf-04 Abstract This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 20, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bierman, et al. Expires July 20, 2015 [Page 1] Internet-Draft RESTCONF January 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Simple Subset of NETCONF Functionality . . . . . . . . . 5 1.2. Data Model Driven API . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.2. HTTP . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.4. Terms . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.5. URI Template . . . . . . . . . . . . . . . . . . . . 10 1.3.6. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 11 2. Transport Protocol Requirements . . . . . . . . . . . . . . . 11 2.1. Integrity and Confidentiality . . . . . . . . . . . . . . 11 2.2. HTTPS with X.509v3 Certificates . . . . . . . . . . . . . 11 2.3. Certificate Validation . . . . . . . . . . . . . . . . . 11 2.4. Authenticated Server Identity . . . . . . . . . . . . . . 12 2.5. Authenticated Client Identity . . . . . . . . . . . . . . 12 3. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Root Resource Discovery . . . . . . . . . . . . . . . . . 13 3.2. RESTCONF Resource Types . . . . . . . . . . . . . . . . . 14 3.3. API Resource . . . . . . . . . . . . . . . . . . . . . . 15 3.3.1. {+restconf}/data . . . . . . . . . . . . . . . . . . 15 3.3.2. {+restconf}/operations . . . . . . . . . . . . . . . 16 3.4. Datastore Resource . . . . . . . . . . . . . . . . . . . 16 3.4.1. Edit Collision Detection . . . . . . . . . . . . . . 17 3.5. Data Resource . . . . . . . . . . . . . . . . . . . . . . 18 3.5.1. Encoding YANG Instance Identifiers in the Request URI 18 3.5.2. Defaults Handling . . . . . . . . . . . . . . . . . . 21 3.6. Operation Resource . . . . . . . . . . . . . . . . . . . 21 3.6.1. Encoding Operation Input Parameters . . . . . . . . . 22 3.6.2. Encoding Operation Output Parameters . . . . . . . . 23 3.7. Schema Resource . . . . . . . . . . . . . . . . . . . . . 24 3.8. Event Stream Resource . . . . . . . . . . . . . . . . . . 25 3.9. Errors Resource . . . . . . . . . . . . . . . . . . . . . 25 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.4. POST . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4.1. Create Resource Mode . . . . . . . . . . . . . . . . 28 4.4.2. Invoke Operation Mode . . . . . . . . . . . . . . . . 29 4.5. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.6. PATCH . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 32 Bierman, et al. Expires July 20, 2015 [Page 2] Internet-Draft RESTCONF January 2015 4.8. Query Parameters . . . . . . . . . . . . . . . . . . . . 33 4.8.1. Query Parameter URIs . . . . . . . . . . . . . . . . 34 4.8.2. The "defaults" Protocol Capability URI . . . . . . . 34 4.8.3. The "content" Query Parameter . . . . . . . . . . . . 35 4.8.4. The "depth" Query Parameter . . . . . . . . . . . . . 36 4.8.5. The "fields" Query Parameter . . . . . . . . . . . . 36 4.8.6. The "insert" Query Parameter . . . . . . . . . . . . 37 4.8.7. The "point" Query Parameter . . . . . . . . . . . . . 38 4.8.8. The "filter" Query Parameter . . . . . . . . . . . . 38 4.8.9. The "start-time" Query Parameter . . . . . . . . . . 39 4.8.10. The "stop-time" Query Parameter . . . . . . . . . . . 40 4.8.11. The "with-defaults" Query Parameter . . . . . . . . . 40 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.1. Request URI Structure . . . . . . . . . . . . . . . . . . 41 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 43 5.3. Message Encoding . . . . . . . . . . . . . . . . . . . . 44 5.4. RESTCONF Meta-Data . . . . . . . . . . . . . . . . . . . 44 5.5. Return Status . . . . . . . . . . . . . . . . . . . . . . 44 5.6. Message Caching . . . . . . . . . . . . . . . . . . . . . 45 6. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 45 6.1. Server Support . . . . . . . . . . . . . . . . . . . . . 45 6.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 45 6.3. Subscribing to Receive Notifications . . . . . . . . . . 48 6.3.1. NETCONF Event Stream . . . . . . . . . . . . . . . . 49 6.4. Receiving Event Notifications . . . . . . . . . . . . . . 49 7. Error Reporting . . . . . . . . . . . . . . . . . . . . . . . 51 7.1. Error Response Message . . . . . . . . . . . . . . . . . 52 8. RESTCONF module . . . . . . . . . . . . . . . . . . . . . . . 54 9. RESTCONF Monitoring . . . . . . . . . . . . . . . . . . . . . 61 9.1. restconf-state/capabilities . . . . . . . . . . . . . . . 61 9.2. restconf-state/streams . . . . . . . . . . . . . . . . . 61 9.3. RESTCONF Monitoring Module . . . . . . . . . . . . . . . 62 10. YANG Module Library . . . . . . . . . . . . . . . . . . . . . 65 10.1. modules . . . . . . . . . . . . . . . . . . . . . . . . 66 10.1.1. modules/module . . . . . . . . . . . . . . . . . . . 66 10.2. YANG Library Module . . . . . . . . . . . . . . . . . . 67 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 11.1. The "restconf" Relation Type . . . . . . . . . . . . . . 71 11.2. YANG Module Registry . . . . . . . . . . . . . . . . . . 71 11.3. application/yang Media Sub Types . . . . . . . . . . . . 72 11.4. NETCONF Capability URNs . . . . . . . . . . . . . . . . 73 12. Security Considerations . . . . . . . . . . . . . . . . . . . 73 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 74 14.1. Normative References . . . . . . . . . . . . . . . . . . 74 14.2. Informative References . . . . . . . . . . . . . . . . . 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 77 A.1. 03 - 04 . . . . . . . . . . . . . . . . . . . . . . . . . 77 Bierman, et al. Expires July 20, 2015 [Page 3] Internet-Draft RESTCONF January 2015 A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 78 A.3. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 78 A.4. 00 - 01 . . . . . . . . . . . . . . . . . . . . . . . . . 79 A.5. bierman:restconf-04 to ietf:restconf-00 . . . . . . . . . 80 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 80 Appendix C. Example YANG Module . . . . . . . . . . . . . . . . 80 C.1. example-jukebox YANG Module . . . . . . . . . . . . . . . 81 Appendix D. RESTCONF Message Examples . . . . . . . . . . . . . 86 D.1. Resource Retrieval Examples . . . . . . . . . . . . . . . 87 D.1.1. Retrieve the Top-level API Resource . . . . . . . . . 87 D.1.2. Retrieve The Server Module Information . . . . . . . 88 D.1.3. Retrieve The Server Capability Information . . . . . 89 D.2. Edit Resource Examples . . . . . . . . . . . . . . . . . 90 D.2.1. Create New Data Resources . . . . . . . . . . . . . . 90 D.2.2. Detect Resource Entity Tag Change . . . . . . . . . . 91 D.3. Query Parameter Examples . . . . . . . . . . . . . . . . 92 D.3.1. "content" Parameter . . . . . . . . . . . . . . . . . 92 D.3.2. "depth" Parameter . . . . . . . . . . . . . . . . . . 95 D.3.3. "fields" Parameter . . . . . . . . . . . . . . . . . 98 D.3.4. "insert" Parameter . . . . . . . . . . . . . . . . . 99 D.3.5. "point" Parameter . . . . . . . . . . . . . . . . . . 100 D.3.6. "filter" Parameter . . . . . . . . . . . . . . . . . 100 D.3.7. "start-time" Parameter . . . . . . . . . . . . . . . 101 D.3.8. "stop-time" Parameter . . . . . . . . . . . . . . . . 101 D.3.9. "with-defaults" Parameter . . . . . . . . . . . . . . 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 1. Introduction There is a need for standard mechanisms to allow WEB applications to access the configuration data, operational data, data-model specific protocol operations, and notification events within a networking device, in a modular and extensible manner. This document describes an HTTP [RFC7230] based protocol called RESTCONF, for accessing data defined in YANG [RFC6020], using datastores defined in NETCONF [RFC6241]. The NETCONF protocol defines configuration datastores and a set of Create, Retrieve, Update, Delete (CRUD) operations that can be used to access these datastores. The YANG language defines the syntax and semantics of datastore content, operational data, protocol operations, and notification events. RESTCONF uses HTTP operations to provide CRUD operations on a NETCONF datastore containing YANG- defined data. Since NETCONF protocol operations are not relevant, the user should not need any prior knowledge of NETCONF in order to use RESTCONF. Bierman, et al. Expires July 20, 2015 [Page 4] Internet-Draft RESTCONF January 2015 Configuration data and state data are exposed as resources that can be retrieved with the GET method. Resources representing configuration data can be modified with the DELETE, PATCH, POST, and PUT methods. Data is encoded with either XML [W3C.REC-xml-20081126] or JSON [RFC7158]. Data-model specific protocol operations defined with the YANG "rpc" statement can be invoked with the POST method. Data-model specific notification events defined with the YANG "notification" statement can be accessed. 1.1. Simple Subset of NETCONF Functionality The framework and meta-model used for an HTTP-based API does not need to mirror those used by the NETCONF protocol, but it needs to be compatible with NETCONF. Instead, a simplified framework and protocol is needed that co-exists with the three NETCONF datastores (candidate, running, startup), but hides the complexity of multiple datastores from the client. A simplified transaction model is needed that allows basic CRUD operations on a hierarchy of conceptual resources. This represents a limited subset of the transaction capabilities of the NETCONF protocol. The HTTP POST, PUT, PATCH, and DELETE methods are used to edit data resources represented by YANG data models. These basic edit operations allow the running configuration to be altered in an all- or-none fashion. This is similar to the "rollback-on-error" capability in NETCONF. Edits are usually applied to one data resource instance at a time. RW: Check whether there are options to modify multiple resources. Applications that require more complex transaction capabilities might consider NETCONF instead of RESTCONF. The following transaction features are not directly provided in RESTCONF: o datastore locking (full or partial) o candidate datastore o startup datastore o validate operation o confirmed-commit procedure Bierman, et al. Expires July 20, 2015 [Page 5] Internet-Draft RESTCONF January 2015 RESTCONF is not intended to replace NETCONF, but rather provide an additional simplified interface that follows REST principles and is compatible with a resource-oriented device abstraction. The following figure shows the system components: +-----------+ +-----------------+ | WEB app | <-------> | | +-----------+ HTTP | network device | | | +-----------+ | +-----------+ | | NMS app | <-------> | | datastore | | +-----------+ NETCONF | +-----------+ | +-----------------+ 1.2. Data Model Driven API RESTCONF combines the simplicity of the HTTP protocol with the predictability and automation potential of a schema-driven API. Using YANG, a client can predict all resource endpoints, much like using URI Templates [RFC6570], but in a more holistic manner. This strategy obviates the need for responses provided by the server to contain HATEOAS links, originally described in Roy Fielding's doctoral dissertation [rest-dissertation]. A REST client using HATEOAS principles would not use any data modeling language to define the application-specific content of the API. The client would discover each new child resource as it traverses the URIs returned as Location IDs to discover the server capabilities. This approach has 3 significant weaknesses with regards to control of complex networking devices: o inefficient performance: configuration APIs will be quite complex and may require thousands of protocol messages to discover all the schema information. Typically the data type information has to be passed in the protocol messages, which is also wasteful overhead. o no data model richness: without a data model, the schema-level semantics and validation constraints are not available to the application. o no tool automation: API automation tools need some sort of content schema to function. Such tools can automate various programming and documentation tasks related to specific data models. Data model modules such as YANG modules serve as an "API contract" that will be honored by the server. An application designer can code to the data model, knowing in advance important details about the Bierman, et al. Expires July 20, 2015 [Page 6] Internet-Draft RESTCONF January 2015 exact protocol operations and datastore content a conforming server implementation will support. RESTCONF provides the YANG module capability information supported by the server, in case the client wants to use it. The URIs for custom protocol operations and datastore content are predictable, based on the YANG module definitions. Operational experience with CLI and SNMP indicates that operators learn the 'location' of specific service or device related data and do not expect such information to be arbitrary and discovered each time the client opens a management session to a server. The RESTCONF protocol operates on a conceptual datastore defined with the YANG data modeling language. The server lists each YANG module it supports under "/modules" defined in the "ietf-yang-library" YANG module. The conceptual datastore contents, data-model-specific operations and notification events are identified by this set of YANG modules. All RESTCONF content identified as either a data resource, operation resource, or event stream resource is defined with the YANG language. The classification of data as configuration or non-configuration is derived from the YANG "config" statement. Data ordering behavior is derived from the YANG "ordered-by" statement. The RESTCONF datastore editing model is simple and direct, similar to the behavior of the ":writable-running" capability in NETCONF. Each RESTCONF edit of a datastore resource is activated upon successful completion of the transaction. RW: Is there a capability of bulking updates together? 1.3. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. 1.3.1. NETCONF The following terms are defined in [RFC6241]: o candidate configuration datastore o client o configuration data Bierman, et al. Expires July 20, 2015 [Page 7] Internet-Draft RESTCONF January 2015 o datastore o configuration datastore o protocol operation o running configuration datastore o server o startup configuration datastore o state data o user 1.3.2. HTTP The following terms are defined in [RFC3986]: o fragment o path o query The following terms are defined in [RFC7230]: o header o message-body o Request-Line o request URI The following terms are defined in [RFC7231]: o method o request o resource The following terms are defined in [RFC7232]: o entity tag Bierman, et al. Expires July 20, 2015 [Page 8] Internet-Draft RESTCONF January 2015 1.3.3. YANG The following terms are defined in [RFC6020]: o container o data node o key leaf o leaf o leaf-list o list o presence container (or P-container) o RPC operation (now called protocol operation) o non-presence container (or NP-container) o ordered-by system o ordered-by user 1.3.4. Terms The following terms are used within this document: o API resource: a resource with the media type "application/ yang.api+xml" or "application/yang.api+json". o data resource: a resource with the media type "application/ yang.data+xml" or "application/yang.data+json". Containers, leafs, list entries and anyxml nodes can be data resources. o datastore resource: a resource with the media type "application/ yang.datastore+xml" or "application/yang.datastore+json". Represents a datastore. o edit operation: a RESTCONF operation on a data resource using the POST, PUT, PATCH, or DELETE method. o event stream resource: This resource represents an SSE (Server- Sent Events) event stream. The content consists of text using the media type "text/event-stream", as defined by the HTML5 specification. Each event represents one message Bierman, et al. Expires July 20, 2015 [Page 9] Internet-Draft RESTCONF January 2015 generated by the server. It contains a conceptual system or data- model specific event that is delivered within a notification event stream. Also called a "stream resource". o operation: the conceptual RESTCONF operation for a message, derived from the HTTP method, request URI, headers, and message- body. o operation resource: a resource with the media type "application/ yang.operation+xml" or "application/yang.operation+json". o patch: a generic PATCH request on the target datastore or data resource. The media type of the message-body content will identify the patch type in use. o plain patch: a PATCH request where the media type is "application/ yang.data+xml" or "application/yang.data+json". RW: "plain patch" is one patch type that is identified, what other ones are there, if any? The description of patch above (and where the PATCH operation is described implies that there will be more than one patch type.) o query parameter: a parameter (and its value if any), encoded within the query component of the request URI. o retrieval request: a request using the GET or HEAD methods. o target resource: the resource that is associated with a particular message, identified by the "path" component of the request URI. o unified datastore: A conceptual representation of the device running configuration. The server will hide all NETCONF datastore details for edit operations, such as the ":candidate" and ":startup" capabilities. o schema resource: a resource with the media type "application/ yang". The YANG representation of the schema can be retrieved by the client with the GET method. o stream list: the set of data resource instances that describe the event stream resources available from the server. This information is defined in the "ietf-restconf-monitoring" module as the "stream" list. It can be retrieved using the target resource "{+restconf}/data/ietf-restconf-monitoring:restconf-state/streams/ stream". The stream list contains information about each stream, such as the URL to retrieve the event stream data. RW: It might add clarity if "media type" was also defined. 1.3.5. URI Template Throughout this document, the URI template [RFC6570] syntax "{+restconf}" is used to refer to the RESTCONF API entry point outside of an example. See Section 3.1 for details. Bierman, et al. Expires July 20, 2015 [Page 10] Internet-Draft RESTCONF January 2015 All of the examples in this document assume "/restconf" as the discovered RESTCONF API root path. 1.3.6. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration data (read-write) and "ro" state data (read-only). o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 2. Transport Protocol Requirements 2.1. Integrity and Confidentiality HTTP [RFC7230] is an application layer protocol that may be layered on any reliable transport-layer protocol. RESTCONF is defined on top of HTTP, but due to the sensitive nature of the information conveyed, RESTCONF requires that the transport-layer protocol provides both data integrity and confidentiality, such as is provided by the TLS protocol [RFC5246]. 2.2. HTTPS with X.509v3 Certificates Given the nearly ubiquitous support for HTTP over TLS [RFC7230], RESTCONF implementations MUST support the "https" URI scheme, which has the IANA assigned default port 443. Consistent with the exclusive use of X.509v3 certificates for NETCONF over TLS [draft-ietf-netconf-rfc5539bis-07], use of certificates in RESTCONF is also limited to X.509v3 certificates. 2.3. Certificate Validation When presented an X.509 certificate, the RESTCONF peer MUST use X.509 certificate path validation [RFC5280] to verify the integrity of the certificate. The presented X.509 certificate MAY also be considered Bierman, et al. Expires July 20, 2015 [Page 11] Internet-Draft RESTCONF January 2015 valid if it matches a locally configured certificate fingerprint. If X.509 certificate path validation fails and the presented X.509 certificate does not match a locally configured certificate fingerprint, the connection MUST be terminated as defined in [RFC5246]. 2.4. Authenticated Server Identity The RESTCONF client MUST carefully examine the certificate presented by the RESTCONF server to determine if it meets the client's expectations. If the RESTCONF client has external information as to the expected identity of the RESTCONF server, the hostname check MAY be omitted. Otherwise, the RESTCONF client MUST check its understanding of the RESTCONF server hostname against the server's identity as presented in the server certificate message. Matching is performed according to the rules and guidelines defined in [RFC6125]. If the match fails, the RESTCONF client MUST either ask for explicit user confirmation or terminate the connection with an indication that the RESTCONF server's identity is suspect. 2.5. Authenticated Client Identity The RESTCONF server MUST authenticate the client access to any protected resource using HTTP Authentication [RFC7235]. If the RESTCONF client is not authenticated to access a resource, the server MUST send a response with status code 401 (Unauthorized) and a WWW- Authenticate header field containing at least one challenge applicable to the target resource. The RESTCONF server MAY advertise support for any number of authentication schemes but, in order to ensure interoperability, the RESTCONF server MUST advertise at least one of the following authentication schemes: o Basic [draft-ietf-httpauth-basicauth-update-03] o Digest [draft-ietf-httpauth-digest-09] o ClientCertificate [draft-thomson-httpbis-cant-01] These authentication schemes are selected due to their similarity to authentication schemes supported by NETCONF. In particular, the Basic and Digest authentication schemes both directly provide an identity and verification of a shared secret, much like NETCONF over SSH, when using the SSH "password" authentication method [RFC4252]. Similarly, the ClientCertificate authentication scheme is much like NETCONF over TLS's use of X.509 client-certificates. When using the ClientCertificate authentication scheme, the RESTCONF server MUST verify the identity of the RESTCONF client using the algorithm defined in section 7 of [draft-ietf-netconf-rfc5539bis-07]. Bierman, et al. Expires July 20, 2015 [Page 12] Internet-Draft RESTCONF January 2015 The RESTCONF client identity determined from any HTTP authentication scheme is hereafter known as the "RESTCONF username" and subject to the NETCONF Access Control Module (NACM) [RFC6536]. 3. Resources The RESTCONF protocol operates on a hierarchy of resources, starting with the top-level API resource itself (Section 3.1). Each resource represents a manageable component within the device. A resource can be considered a collection of conceptual data and the set of allowed methods on that data. It can contain nested child resources. The child resource types and methods allowed on them are data-model specific. A resource has its own media type identifier, represented by the "Content-Type" header in the HTTP response message. A resource can contain zero or more nested resources. A resource can be created and deleted independently of its parent resource, as long as the parent resource exists. RW: Is it worth clarifying that child resources included in an HTTP response could be a different datatype to media type identifier? All RESTCONF resources are defined in this document except datastore contents, protocol operations, and notification events. The syntax and semantics for these resource types are defined in YANG modules. The RESTCONF resources are accessed via a set of URIs defined in this document. The set of YANG modules supported by the server will determine the data model specific operations, top-level data node resources, and notification event messages supported by the server. The resources used in the RESTCONF protocol are identified by the "path" component in the request URI. Each operation is performed on a target resource. The RESTCONF protocol does not include a resource discovery mechanism. Instead, the definitions within the YANG modules advertised by the server are used to construct a predictable operation or data resource identifier. 3.1. Root Resource Discovery In line with the best practices defined by [get-off-my-lawn], RESTCONF enables deployments to specify where the RESTCONF API is located. When first connecting to a RESTCONF server, a RESTCONF client MUST determine the root of the RESTCONF API. The client discovers this by getting the "/.well-known/host-meta" resource ([RFC6415]) and using the element containing the "restconf" attribute : Bierman, et al. Expires July 20, 2015 [Page 13] Internet-Draft RESTCONF January 2015 Request ------- GET /.well-known/host-meta users HTTP/1.1 Host: example.com Accept: application/xrd+xml Response -------- HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn Once discovering the RESTCONF API root, the client MUST prepend it to any subsequent request to a RESTCONF resource. For instance, using the "/restconf" path discovered above, the client can now determine the operations supported by the the server: Request ------- GET /restconf/operations HTTP/1.1 Host: example.com Accept: application/yang.api+json, application/yang.errors+json Response -------- HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Last-Modified: Sun, 22 Apr 2012 01:00:14 GMT Content-Type: application/yang.api+json { "operations" : { "play" : [ null ] } } RW: Unclear what the "play" operation is here. RW: The description of "3.3 API Resource" (below) implies that "data" is mandatory here, so I was wondering if it should have also been included in the response? 3.2. RESTCONF Resource Types The RESTCONF protocol defines a set of application specific media types to identify each of the available resource types. The following resource types are defined in RESTCONF: Bierman, et al. Expires July 20, 2015 [Page 14] Internet-Draft RESTCONF January 2015 +-----------+----------------------------+ | Resource | Media Type | +-----------+----------------------------+ | API | application/yang.api | | Datastore | application/yang.datastore | | Data | application/yang.data | | Errors | application/yang.errors | | Operation | application/yang.operation | | Schema | application/yang | +-----------+----------------------------+ RESTCONF Media Types 3.3. API Resource The API resource contains the state and access points for the RESTCONF features. It is the top-level resource and has the media type "application/yang.api+xml" or "application/yang.api+json". YANG Tree Diagram for "application/yang.api" Resource Type: +--rw restconf +--rw data +--rw operations The "application/yang.api" restconf-resource extension in the "ietf-restconf" module defined in Section 8 is used to specify the structure and syntax of the conceptual child resources within the API resource. This resource has the following child resources: +----------------+--------------------------------+ | Child Resource | Description | +----------------+--------------------------------+ | data | Contains all data resources | | operations | Data-model specific operations | +----------------+--------------------------------+ RESTCONF API Resource 3.3.1. {+restconf}/data This mandatory resource represents the combined configuration and operational data resources that can be accessed by a client. It cannot be created or deleted by the client. The datastore resource type is defined in Section 3.4. RW: Perhaps clarify in some way here that the {+restconf}/data is the datastore resource. (But, it is explicitly described below, so it may be unnecessary.) Bierman, et al. Expires July 20, 2015 [Page 15] Internet-Draft RESTCONF January 2015 Example: This example request by the client would retrieve only the non- configuration data nodes that exist within the "library" resource, using the "content" query parameter (see Section 4.8.3). GET /restconf/data/example-jukebox:jukebox/library ?content=nonconfig HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:30 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.data+json { "example-jukebox:library" : { "artist-count" : 42, "album-count" : 59, "song-count" : 374 } } 3.3.2. {+restconf}/operations This optional resource is a container that provides access to the data-model specific protocol operations supported by the server. The server MAY omit this resource if no data-model specific operations are advertised. Any data-model specific operations defined in the YANG modules advertised by the server MAY be available as child nodes of this resource. Operation resources are defined in Section 3.6. 3.4. Datastore Resource The "{+restconf}/data" subtree represents the datastore resource type, which is a collection of configuration and operational data nodes. Bierman, et al. Expires July 20, 2015 [Page 16] Internet-Draft RESTCONF January 2015 A "unified datastore" interface is used to simplify resource editing for the client. The RESTCONF unified datastore is a conceptual interface to the native configuration datastores that are present on the device. The underlying NETCONF datastores (i.e., candidate, running, startup) can be used to implement the unified datastore, but the server design is not limited to the exact datastore procedures defined in NETCONF. The "candidate" and "startup" datastores are not visible in the RESTCONF protocol. Transaction management and configuration persistence are handled by the server and not controlled by the client. A datastore resource can only be written directly with the PATCH method. Only the configuration data resources within the datastore resource can be edited directly with all methods. Each RESTCONF edit of a datastore resource is saved to non-volatile storage in an implementation-specific matter by the server. There is no guarantee that configuration changes are saved immediately, or that the saved configuration is always a mirror of the running configuration. 3.4.1. Edit Collision Detection Two "edit collision detection" mechanisms are provided in RESTCONF, for datastore and data resources. RW: The description below was slightly confusing as to whether it was refering to both datastore and data resources or just datastore. In particular, here it states that a server MUST maintain a last-modified timestamp for this resource, whereas this appears to be optional for data resources. 3.4.1.1. Timestamp The last change time is maintained and the "Last-Modified" and "Date" headers are returned in the response for a retrieval request. The "If-Unmodified-Since" header can be used in edit operation requests to cause the server to reject the request if the resource has been modified since the specified timestamp. The server MUST maintain a last-modified timestamp for this resource, and return the "Last-Modified" header when this resource is retrieved with the GET or HEAD methods. Only changes to configuration data resources within the datastore affect this timestamp. 3.4.1.2. Entity tag A unique opaque string is maintained and the "ETag" header is returned in the response for a retrieval request. The "If-Match" header can be used in edit operation requests to cause the server to Bierman, et al. Expires July 20, 2015 [Page 17] Internet-Draft RESTCONF January 2015 reject the request if the resource entity tag does not match the specified value. The server MUST maintain a resource entity tag for this resource, and return the "ETag" header when this resource is retrieved with the GET or HEAD methods. The resource entity tag MUST be changed to a new previously unused value if changes to any configuration data resources within the datastore are made. RW: It is unclear to me what this Entity tag is meant to be? I had assumed that it would identify who last updated the resource so it was possible to determine if a resource had been updated between reading it and patching it, but then the comment that it has to be a new previously unused value, implies that each value has to be unique in somewhat and hence perhaps it is just a counter, or a session id? 3.5. Data Resource A data resource represents a YANG data node that is a descendant node of a datastore resource. Containers, leafs, list entries and anyxml nodes are data resources. For configuration data resources, the server MAY maintain a last- modified timestamp for the resource, and return the "Last-Modified" header when it is retrieved with the GET or HEAD methods. If maintained, the resource timestamp MUST be set to the current time whenever the resource or any configuration resource within the resource is altered. For configuration data resources, the server MAY maintain a resource entity tag for the resource, and return the "ETag" header when it is retrieved as the target resource with the GET or HEAD methods. If maintained, the resource entity tag MUST be updated whenever the resource or any configuration resource within the resource is altered. A data resource can be retrieved with the GET method. Data resources are accessed via the "{+restconf}/data" entry point. This sub-tree is used to retrieve and edit data resources. A configuration data resource can be altered by the client with some or all of the edit operations, depending on the target resource and the specific operation. Refer to Section 4 for more details on edit operations. The resource definition version for a data resource is identified by the revision date of the YANG module containing the YANG definition for the data resource. 3.5.1. Encoding YANG Instance Identifiers in the Request URI In YANG, data nodes are named with an absolute XPath expression, defined in [XPath], starting from the document root to the target resource. In RESTCONF, URL encoded Location header expressions are used instead. Bierman, et al. Expires July 20, 2015 [Page 18] Internet-Draft RESTCONF January 2015 The YANG "instance-identifier" (i-i) data type is represented in RESTCONF with the path expression format defined in this section. +-------+-------------------------------------------+ | Name | Comments | +-------+-------------------------------------------+ | point | Insertion point is always a full i-i | | path | Request URI path is a full or partial i-i | +-------+-------------------------------------------+ RESTCONF instance-identifier Type Conversion The "path" component of the request URI contains the absolute path expression that identifies the target resource. A predictable location for a data resource is important, since applications will code to the YANG data model module, which uses static naming and defines an absolute path location for all data nodes. A RESTCONF data resource identifier is not an XPath expression. It is encoded from left to right, starting with the top-level data node, according to the "api-path" rule in Section 3.5.1.1. The node name of each ancestor of the target resource node is encoded in order, ending with the node name for the target resource. If a data node in the path expression is a YANG list node, then the key values for the list (if any) MUST be encoded according to the following rules. o The key leaf values for a data resource representing a YANG list MUST be encoded using one path segment [RFC3986]. o If there is only one key leaf value, the path segment is constructed by having the list name followed by an "=" followed by the single key leaf value. o If there are multiple key leaf values, the value of each leaf identified in the "key" statement is encoded in the order specified in the YANG "key" statement, with a comma separating them. o All the components in the "key" statement MUST be encoded. Partial instance identifiers are not supported. o Quoted strings are supported in the key leaf values. Quoted strings MUST be used to express empty strings. (example: list=foo,'',baz). Bierman, et al. Expires July 20, 2015 [Page 19] Internet-Draft RESTCONF January 2015 o The "list-instance" ABNF rule defined in Section 3.5.1.1 represents the syntax of a list instance identifier. o Resource URI values returned in Location headers for data resources MUST identify the module name, even if there are no conflicting local names when the resource is created. This ensures the correct resource will be identified even if the server loads a new module that the old client does not know about. Examples: container top { list list1 { key "key1 key2 key3"; ... list list2 { key "key4 key5"; ... leaf X { type string; } } } RW: Perhaps indent list2 to make it clear that it is a child of list1? For the above YANG definition, URI with key leaf values will be encoded as follows (line wrapped for display purposes only): /restconf/data/example-top:top/list1=key1val,key2val,key3val3/ list2=key4val,key5val/X 3.5.1.1. ABNF For Data Resource Identifiers The "api-path" ABNF syntax is used to construct RESTCONF path identifiers: Bierman, et al. Expires July 20, 2015 [Page 20] Internet-Draft RESTCONF January 2015 api-path = "/" | ("/" api-identifier 0*("/" (api-identifier | list-instance ))) api-identifier = [module-name ":"] identifier ;; note 1 module-name = identifier list-instance = api-identifier "=" key-value ["," key-value]* key-value = string string = ;; An identifier MUST NOT start with ;; (('X'|'x') ('M'|'m') ('L'|'l')) identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") Note 1: The syntax for "api-identifier" MUST conform to the JSON identifier encoding rules in section 4 of [I-D.ietf-netmod-yang-json]. 3.5.2. Defaults Handling RESTCONF requires that a server report its default handling mode. See Section 4.8.2 for details. The optional "with-defaults" query parameter is also available to report default leaf node values that are in effect within a data model. See Section 4.8.11 for details on using the "with-defaults" query parameter to control retrieval of default values. If the target of a GET method is a data node that represents a leaf that has a default value, and the leaf has not been given a value yet, the server MUST return the default value that is in use by the server. If the target of a GET method is a data node that represents a container or list that has any child resources with default values, for the child resources that have not been given value yet, the server MAY return the default values that are in use by the server. RW: Will the client be able to know whether default values have been returned for the children nodes? Would it be better to force all defaults to be returned, otherwise the client may have to query for each and every node? 3.6. Operation Resource An operation resource represents a protocol operation defined with the YANG "rpc" statement. Bierman, et al. Expires July 20, 2015 [Page 21] Internet-Draft RESTCONF January 2015 All operation resources share the same module namespace as any top- level data resources, so the name of an operation resource cannot conflict with the name of a top-level data resource defined within the same module. If 2 different YANG modules define the same "rpc" identifier, then the module name MUST be used in the request URI. For example, if "module-A" and "module-B" both defined a "reset" operation, then invoking the operation from "module-A" would be requested as follows: POST /restconf/operations/module-A:reset HTTP/1.1 Server example.com Any usage of an operation resource from the same module, with the same name, refers to the same "rpc" statement definition. This behavior can be used to design protocol operations that perform the same general function on different resource types. If the "rpc" statement has an "input" section, then a message-body MAY be sent by the client in the request, otherwise the request message MUST NOT include a message-body. If the "rpc" statement has an "output" section, then a message-body MAY be sent by the server in the response. Otherwise the server MUST NOT include a message-body in the response message, and MUST send a "204 No Content" Status-Line instead. RW: Is "204 No Content" only sent back on success? Presumably it could also return an error instead (e.g. not authorized, or perhaps some other error to indicate that the system cannot comply)? 3.6.1. Encoding Operation Input Parameters If the "rpc" statement has an "input" section, then the "input" node is provided in the message-body, corresponding to the YANG data definition statements within the "input" section. Example: The following YANG definition is used for the examples in this section. rpc reboot { input { leaf delay { units seconds; type uint32; default 0; } leaf message { type string; } leaf language { type string; } } } Bierman, et al. Expires July 20, 2015 [Page 22] Internet-Draft RESTCONF January 2015 The client might send the following POST request message: POST /restconf/operations/example-ops:reboot HTTP/1.1 Host: example.com Content-Type: application/yang.operation+json { "example-ops:input" : { "delay" : 600, "message" : "Going down for system maintenance", "language" : "en-US" } } The server might respond: HTTP/1.1 204 No Content Date: Mon, 25 Apr 2012 11:01:00 GMT Server: example-server 3.6.2. Encoding Operation Output Parameters If the "rpc" statement has an "output" section, then the "output" node is provided in the message-body, corresponding to the YANG data definition statements within the "output" section. Example: The following YANG definition is used for the examples in this section. rpc get-reboot-info { output { leaf reboot-time { units seconds; type uint32; } leaf message { type string; } leaf language { type string; } } } The client might send the following POST request message: POST /restconf/operations/example-ops:get-reboot-info HTTP/1.1 Host: example.com Accept: application/yang.operation+json, application/yang.errors+json Bierman, et al. Expires July 20, 2015 [Page 23] Internet-Draft RESTCONF January 2015 The server might respond: HTTP/1.1 200 OK Date: Mon, 25 Apr 2012 11:10:30 GMT Server: example-server Content-Type: application/yang.operation+json { "example-ops:output" : { "reboot-time" : 30, "message" : "Going down for system maintenance", "language" : "en-US" } } 3.7. Schema Resource The server can optionally support retrieval of the YANG modules it supports. To retrieve a YANG module, a client first needs to get the URL for retrieving the schema. The client might send the following GET request message: GET /restconf/data/ietf-yang-library:modules/module= example-jukebox,2014-07-03/schema HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond: HTTP/1.1 200 OK Date: Mon, 25 Apr 2012 11:10:30 GMT Server: example-server Content-Type: application/yang.data+json { "ietf-yang-library:schema": "http://example.com/mymodules/example-jukebox/2014-07-03" } Next the client needs to retrieve the actual YANG schema. The client might send the following GET request message: Bierman, et al. Expires July 20, 2015 [Page 24] Internet-Draft RESTCONF January 2015 GET http://example.com/mymodules/example-jukebox/2014-07-03 HTTP/1.1 Host: example.com Accept: application/yang, application/yang.errors+json The server might respond: module example-jukebox { namespace "http://example.com/ns/example-jukebox"; prefix "jbox"; // rest of YANG module content deleted... } 3.8. Event Stream Resource An "event stream" resource represents a source for system generated event notifications. Each stream is created and modified by the server only. A client can retrieve a stream resource or initiate a long-poll server sent event stream, using the procedure specified in Section 6.3. A notification stream functions according to the NETCONF Notifications specification [RFC5277]. The available streams can be retrieved from the stream list, which specifies the syntax and semantics of a stream resource. 3.9. Errors Resource An "errors" resource is a collection of error information that is sent as the message-body in a server response message, if an error occurs while processing a request message. The "ietf-restconf" YANG module contains the "application/ yang.errors" restconf-resource extension which specifies the syntax and semantics of an "errors" resource. RESTCONF error handling behavior is defined in Section 7. 4. Operations The RESTCONF protocol uses HTTP methods to identify the CRUD operation requested for a particular resource. The following table shows how the RESTCONF operations relate to NETCONF protocol operations: Bierman, et al. Expires July 20, 2015 [Page 25] Internet-Draft RESTCONF January 2015 +----------+-------------------------------------+ | RESTCONF | NETCONF | +----------+-------------------------------------+ | OPTIONS | none | | HEAD | none | | GET | , | | POST | (operation="create") | | PUT | (operation="replace") | | PATCH | (operation="merge") | | DELETE | (operation="delete") | +----------+-------------------------------------+ Table 1: CRUD Methods in RESTCONF The NETCONF "remove" operation attribute is not supported by the HTTP DELETE method. The resource must exist or the DELETE method will fail. The PATCH method is equivalent to a "merge" operation for a plain patch. Access control mechanisms may be used to limit what operations can be used. In particular, RESTCONF is compatible with the NETCONF Access Control Model (NACM) [RFC6536], as there is a specific mapping between RESTCONF and NETCONF operations, defined in Table 1. The resource path needs to be converted internally by the server to the corresponding YANG instance-identifier. Using this information, the server can apply the NACM access control rules to RESTCONF messages. The server MUST NOT allow any operation to any resources that the client is not authorized to access. Implementation of all methods (except PATCH) are defined in [RFC7231]. This section defines the RESTCONF protocol usage for each HTTP method. 4.1. OPTIONS The OPTIONS method is sent by the client to discover which methods are supported by the server for a specific resource. If supported, it SHOULD be implemented for all media types. RW: What it mean by all media types here? Does this mean both JSON and XML or something else? The server SHOULD implement this method, however the same information could be extracted from the YANG modules and the RESTCONF protocol specification. If the PATCH method is supported, then the "Accept-Patch" header MUST be supported and returned in the response to the OPTIONS request, as defined in [RFC5789]. Bierman, et al. Expires July 20, 2015 [Page 26] Internet-Draft RESTCONF January 2015 4.2. HEAD The HEAD method is sent by the client to retrieve just the headers that would be returned for the comparable GET method, without the response message-body. It is supported for all resource types, except operation resources. The request MUST contain a request URI that contains at least the entry point component. The same query parameters supported by the GET method are supported by the HEAD method. The access control behavior is enforced as if the method was GET instead of HEAD. The server MUST respond the same as if the method was GET instead of HEAD, except that no response message-body is included. 4.3. GET The GET method is sent by the client to retrieve data and meta-data for a resource. It is supported for all resource types, except operation resources. The request MUST contain a request URI that contains at least the entry point component. The server MUST NOT return any data resources for which the user does not have read privileges. If the user is not authorized to read the target resource, an error response containing a "403 Forbidden" or "404 Not Found" Status-Line is returned to the client. If the user is authorized to read some but not all of the target resource, the unauthorized content is omitted from the response message-body, and the authorized content is returned to the client. Example: The client might request the response headers for a JSON representation of the "library" resource: GET /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond: Bierman, et al. Expires July 20, 2015 [Page 27] Internet-Draft RESTCONF January 2015 HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:02:40 GMT Server: example-server Content-Type: application/yang.data+json Cache-Control: no-cache Pragma: no-cache ETag: a74eefc993a2b Last-Modified: Mon, 23 Apr 2012 11:02:14 GMT { "example-jukebox:album" : [ { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2011 } ] } 4.4. POST The POST method is sent by the client to create a data resource or invoke an operation resource. The server uses the target resource media type to determine how to process the request. +-----------+------------------------------------------------+ | Type | Description | +-----------+------------------------------------------------+ | Datastore | Create a top-level configuration data resource | | Data | Create a configuration data child resource | | Operation | Invoke a protocol operation | +-----------+------------------------------------------------+ Resource Types that Support POST 4.4.1. Create Resource Mode If the target resource type is a datastore or data resource, then the POST is treated as a request to create a top-level resource or child resource, respectively. The message-body is expected to contain the content of a child resource to create within the parent (target resource). RW: Presumably you are allowed to create a resource with child resources as well (e.g. to POST a full configuration)? Is that worth clarifying here? The "insert" and "point" query parameters are supported by the POST method for datastore and data resource types, as specified in the YANG definition in Section 8. Bierman, et al. Expires July 20, 2015 [Page 28] Internet-Draft RESTCONF January 2015 If the POST method succeeds, a "201 Created" Status-Line is returned and there is no response message-body. A "Location" header identifying the child resource that was created MUST be present in the response in this case. If the user is not authorized to create the target resource, an error response containing a "403 Forbidden" or "404 Not Found" Status-Line is returned to the client. All other error responses are handled according to the procedures defined in Section 7. Example: To create a new "jukebox" resource, the client might send: POST /restconf/data HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:jukebox" : [null] } If the resource is created, the server might respond as follows: HTTP/1.1 201 Created Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Location: http://example.com/restconf/data/example-jukebox:jukebox Last-Modified: Mon, 23 Apr 2012 17:01:00 GMT ETag: b3a3e673be2 Refer to Appendix D.2.1 for more resource creation examples. 4.4.2. Invoke Operation Mode If the target resource type is an operation resource, then the POST method is treated as a request to invoke that operation. The message-body (if any) is processed as the operation input parameters. Refer to Section 3.6 for details on operation resources. If the POST request succeeds, a "200 OK" Status-Line is returned if there is a response message-body, and a "204 No Content" Status-Line is returned if there is no response message-body. If the user is not authorized to invoke the target operation, an error response containing a "403 Forbidden" or "404 Not Found" Status-Line is returned to the client. All other error responses are handled according to the procedures defined in Section 7. Example: Bierman, et al. Expires July 20, 2015 [Page 29] Internet-Draft RESTCONF January 2015 In this example, the client is invoking the "play" operation defined in the "example-jukebox" YANG module. A client might send a "play" request as follows: POST /restconf/operations/example-jukebox:play HTTP/1.1 Host: example.com Content-Type: application/yang.operation+json { "example-jukebox:input" : { "playlist" : "Foo-One", "song-number" : 2 } } The server might respond: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2012 17:50:00 GMT Server: example-server 4.5. PUT The PUT method is sent by the client to create or replace the target resource. The only target resource media type that supports PUT is the data resource. The message-body is expected to contain the content used to create or replace the target resource. The "insert" (Section 4.8.6) and "point" (Section 4.8.7) query parameters are supported by the PUT method for data resources. Consistent with [RFC7231], if the PUT request creates a new resource, a "201 Created" Status-Line is returned. If an existing resource is modified, either "200 OK" or "204 No Content" are returned. If the user is not authorized to create or replace the target resource an error response containing a "403 Forbidden" or "404 Not Found" Status-Line is returned to the client. All other error responses are handled according to the procedures defined in Section 7. Example: An "album" child resource defined in the "example-jukebox" YANG module is replaced or created if it does not already exist. Bierman, et al. Expires July 20, 2015 [Page 30] Internet-Draft RESTCONF January 2015 To replace the "album" resource contents, the client might send as follows. Note that the Request-Line is wrapped for display purposes only: PUT /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:album" : { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2011 } } If the resource is updated, the server might respond: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2012 17:04:00 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 17:04:00 GMT ETag: b27480aeda4c 4.6. PATCH RESTCONF uses the HTTP PATCH method defined in [RFC5789] to provide an extensible framework for resource patching mechanisms. It is optional to implement by the server. Each patch type needs a unique media type. Zero or more PATCH media types MAY be supported by the server. The media types supported by a server can be discovered by the client by sending an OPTIONS request (see Section 4.1). A plain patch is used to create or update a child resource within the target resource. If the target resource instance does not exist, the server MUST NOT create it. If the PATCH request succeeds, a "200 OK" Status-Line is returned if there is a message-body, and "204 No Content" is returned if no response message-body is sent. If the user is not authorized to alter the target resource an error response containing a "403 Forbidden" or "404 Not Found" Status-Line is returned to the client. All other error responses are handled according to the procedures defined in Section 7. Example: Bierman, et al. Expires July 20, 2015 [Page 31] Internet-Draft RESTCONF January 2015 To replace just the "year" field in the "album" resource (instead of replacing the entire resource with the PUT method), the client might send a plain patch as follows. Note that the Request-Line is wrapped for display purposes only: PATCH /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:album" : { "genre" : "example-jukebox:rock", "year" : 2011 } } If the field is updated, the server might respond: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2012 17:49:30 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 17:49:30 GMT ETag: b2788923da4c The XML encoding for the same request might be: PATCH /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com If-Match: b8389233a4c Content-Type: application/yang.data+xml example-jukebox:rock 2011 4.7. DELETE The DELETE method is used to delete the target resource. If the DELETE request succeeds, a "204 No Content" Status-Line is returned, and there is no response message-body. If the user is not authorized to delete the target resource then an error response containing a "403 Forbidden" or "404 Not Found" Status-Line is returned to the client. All other error responses are handled according to the procedures defined in Section 7. Bierman, et al. Expires July 20, 2015 [Page 32] Internet-Draft RESTCONF January 2015 Example: To delete a resource such as the "album" resource, the client might send: DELETE /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com If the resource is deleted, the server might respond: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2012 17:49:40 GMT Server: example-server 4.8. Query Parameters Each RESTCONF operation allows zero or more query parameters to be present in the request URI. The specific parameters that are allowed depends on the resource type, and sometimes the specific target resource used, in the request. +---------------+---------+-----------------------------------------+ | Name | Methods | Description | +---------------+---------+-----------------------------------------+ | content | GET | Select config and/or non-config data | | | | resources | | depth | GET | Request limited sub-tree depth in the | | | | reply content | | fields | GET | Request a subset of the target resource | | | | contents | | filter | GET | Boolean notification filter for event | | | | stream resources | | insert | POST, | Insertion mode for user-ordered data | | | PUT | resources | | point | POST, | Insertion point for user-ordered data | | | PUT | resources | | start-time | GET | Replay buffer start time for event | | | | stream resources | | stop-time | GET | Replay buffer stop time for event | | | | stream resources | | with-defaults | GET | Control retrieval of default values | +---------------+---------+-----------------------------------------+ RESTCONF Query Parameters Bierman, et al. Expires July 20, 2015 [Page 33] Internet-Draft RESTCONF January 2015 Query parameters can be given in any order. Each parameter can appear at most once in a request URI. A default value may apply if the parameter is missing. Refer to Appendix D.3 for examples of query parameter usage. If vendors define additional query parameters, they SHOULD use a prefix (such as the enterprise or organization name) for query parameter names in order to avoid collisions with other parameters. 4.8.1. Query Parameter URIs A new set of RESTCONF Capability URIs are defined to identify the specific query parameters supported by the server. One protocol capability URI is also defined called 'defaults'. +------------+------------------------------------------------------+ | Name | URI | +------------+------------------------------------------------------+ | defaults | urn:ietf:params:restconf:capability:defaults:1.0 | | depth | urn:ietf:params:restconf:capability:depth:1.0 | | fields | urn:ietf:params:restconf:capability:fields:1.0 | | filter | urn:ietf:params:restconf:capability:filter:1.0 | | insert | urn:ietf:params:restconf:capability:insert:1.0 | | replay | urn:ietf:params:restconf:capability:replay:1.0 | | with- | urn:ietf:params:restconf:capability:restconf-with- | | defaults | defaults:1.0 | +------------+------------------------------------------------------+ RW: Perhaps indent the last line of the table by 2 spaces to make it more clear? RESTCONF Query Parameter URIs 4.8.2. The "defaults" Protocol Capability URI This URI identifies the defaults handling mode that is used by the server for processing default leafs in the unified datastore. A parameter named "basic-mode" is required for this capability URI. The "basic-mode" definitions are specified in the "With-Defaults Capability for NETCONF" [RFC6243]. This protocol capability URI MUST be supported by the server, and the MUST be listed in the "capability" leaf-list in Section 9.3. Bierman, et al. Expires July 20, 2015 [Page 34] Internet-Draft RESTCONF January 2015 +------------+------------------------------------------------------+ | Value | Description | +------------+------------------------------------------------------+ | report-all | No data nodes are considered default | | trim | Values set to the YANG default-stmt value are | | | default | | explicit | Values set by the client are never considered | | | default | +------------+------------------------------------------------------+ If the "basic-mode" is set to "report-all" then the server MUST adhere to the defaults handling behavior defined in section 2.1 of [RFC6243]. If the "basic-mode" is set to "trim" then the server MUST adhere to the defaults handling behavior defined in section 2.2 of [RFC6243]. If the "basic-mode" is set to "explicit" then the server MUST adhere to the defaults handling behavior defined in section 2.3 of [RFC6243]. Example: (split for display purposes only) urn:ietf:params:restconf:capability:defaults:1.0? basic-mode=explicit 4.8.3. The "content" Query Parameter The "content" parameter controls how descendant nodes of the requested data nodes will be processed in the reply. The allowed values are: +-----------+-----------------------------------------------------+ | Value | Description | +-----------+-----------------------------------------------------+ | config | Return only configuration descendant data nodes | | nonconfig | Return only non-configuration descendant data nodes | | all | Return all descendant data nodes | +-----------+-----------------------------------------------------+ This parameter is only allowed for GET methods on datastore and data resources. A 400 Bad Request error is returned if used for other methods or resource types. The default value is determined by the "config" statement value of the requested data nodes. If the "config" value is "false", then the Bierman, et al. Expires July 20, 2015 [Page 35] Internet-Draft RESTCONF January 2015 default for the "content" parameter is "nonconfig". If "config" is "true" then the default for the "content" parameter is "config". This query parameter MUST be supported by the server. 4.8.4. The "depth" Query Parameter The "depth" parameter is used to specify the number of nest levels returned in a response for a GET method. The first nest-level consists of the requested data node itself. Any child nodes which are contained within a parent node have a depth value that is 1 greater than its parent. The value of the "depth" parameter is either an integer between 1 and 65535, or the string "unbounded". "unbounded" is the default. This parameter is only allowed for GET methods on API, datastore, and data resources. A 400 Bad Request error is returned if it used for other methods or resource types. By default, the server will include all sub-resources within a retrieved resource, which have the same resource type as the requested resource. Only one level of sub-resources with a different media type than the target resource will be returned. If this query parameter is supported by the server, then the "depth" query parameter URI MUST be listed in the "capability" leaf-list in Section 9.3. 4.8.5. The "fields" Query Parameter The "fields" query parameter is used to optionally identify data nodes within the target resource to be retrieved in a GET method. The client can use this parameter to retrieve a subset of all nodes in a resource. A value of the "fields" query parameter matches the following rule: fields-expr = path '(' fields-expr / '*' ')' / path ';' fields-expr / path path = api-identifier [ '/' path ] "api-identifier" is defined in Section 3.5.1.1. ";" is used to select multiple nodes. For example, to retrieve only the "genre" and "year" of an album, use: "fields=genre;year". Bierman, et al. Expires July 20, 2015 [Page 36] Internet-Draft RESTCONF January 2015 Parentheses are used to specify sub-selectors of a node. For example, to retrieve only the "label" and "catalogue-number" of an album, use: "fields=admin(label;catalogue-number)". "/" is used in a path to retrieve a child node of a node. For example, to retrieve only the "label" of an album, use: "fields=admin/label". This parameter is only allowed for GET methods on api, datastore, and data resources. A 400 Bad Request error is returned if used for other methods or resource types. If this query parameter is supported by the server, then the "fields" query parameter URI MUST be listed in the "capability" leaf-list in Section 9.3. 4.8.6. The "insert" Query Parameter The "insert" parameter is used to specify how a resource should be inserted within a user-ordered list. The allowed values are: +--------+----------------------------------------------------------+ | Value | Description | +--------+----------------------------------------------------------+ | first | Insert the new data as the new first entry. | | last | Insert the new data as the new last entry. | | before | Insert the new data before the insertion point, as | | | specified by the value of the "point" parameter. | | after | Insert the new data after the insertion point, as | | | specified by the value of the "point" parameter. | +--------+----------------------------------------------------------+ The default value is "last". This parameter is only supported for the POST and PUT methods. It is also only supported if the target resource is a data resource, and that data represents a YANG list or leaf-list that is ordered by the user. If the values "before" or "after" are used, then a "point" query parameter for the insertion parameter MUST also be present, or a 400 Bad Request error is returned. If this query parameter is supported by the server, then the "insert" query parameter URI MUST be listed in the "capability" leaf-list in Bierman, et al. Expires July 20, 2015 [Page 37] Internet-Draft RESTCONF January 2015 Section 9.3. The "point" query parameter MUST also be supported by the server. 4.8.7. The "point" Query Parameter The "point" parameter is used to specify the insertion point for a data resource that is being created or moved within a user ordered list or leaf-list. The value of the "point" parameter is of type "data-resource-identifier", defined in the "ietf-restconf" YANG module Section 8. This parameter is only supported for the POST and PUT methods. It is also only supported if the target resource is a data resource, and that data represents a YANG list or leaf-list that is ordered by the user. If the "insert" query parameter is not present, or has a value other than "before" or "after", then a 400 Bad Request error is returned. This parameter contains the instance identifier of the resource to be used as the insertion point for a POST or PUT method. If the server includes the "insert" query parameter URI in the "capability" leaf-list in Section 9.3, then the "point" query parameter MUST be supported. 4.8.8. The "filter" Query Parameter The "filter" parameter is used to indicate which subset of all possible events are of interest. If not present, all events not precluded by other parameters will be sent. This parameter is only allowed for GET methods on a text/event-stream data resource. A 400 Bad Request error is returned if used for other methods or resource types. The format of this parameter is an XPath 1.0 expression, and is evaluated in the following context: o The set of namespace declarations is the set of prefix and namespace pairs for all supported YANG modules, where the prefix is the YANG module name, and the namespace is as defined by the "namespace" statement in the YANG module. o The function library is the core function library defined in XPath 1.0. Bierman, et al. Expires July 20, 2015 [Page 38] Internet-Draft RESTCONF January 2015 o The set of variable bindings is empty. o The context node is the root node. The filter is used as defined in [RFC5277], section 3.6. If the boolean result of the expression is true when applied to the conceptual "notification" document root, then the notification event is delivered to the client. If this query parameter is supported by the server, then the "filter" query parameter URI MUST be listed in the "capability" leaf-list in Section 9.3. RW: I wonder if implementations would rather choose to implement an easier syntax than full XPath, perhaps in future these is scope for a simple-filter. 4.8.9. The "start-time" Query Parameter The "start-time" parameter is used to trigger the notification replay feature and indicate that the replay should start at the time specified. If the stream does not support replay, per the "replay-support" attribute returned by stream list entry for the stream resource, then the server MUST return the HTTP error code 400 Bad Request. The value of the "start-time" parameter is of type "date-and-time", defined in the "ietf-yang" YANG module [RFC6991]. This parameter is only allowed for GET methods on a text/event-stream data resource. A 400 Bad Request error is returned if used for other methods or resource types. If this parameter is not present, then a replay subscription is not being requested. It is not valid to specify start times that are later than the current time. If the value specified is earlier than the log can support, the replay will begin with the earliest available notification. If this query parameter is supported by the server, then the "replay" query parameter URI MUST be listed in the "capability" leaf-list in Section 9.3. The "stop-time" query parameter MUST also be supported by the server. If the "replay-support" leaf is present in the "stream" entry (defined in Section 9.3) then the server MUST support the "start-time" and "stop-time" query parameters for that stream. Bierman, et al. Expires July 20, 2015 [Page 39] Internet-Draft RESTCONF January 2015 4.8.10. The "stop-time" Query Parameter The "stop-time" parameter is used with the replay feature to indicate the newest notifications of interest. This parameter MUST be used with and have a value later than the "start-time" parameter. The value of the "stop-time" parameter is of type "date-and-time", defined in the "ietf-yang" YANG module [RFC6991]. This parameter is only allowed for GET methods on a text/event-stream data resource. A 400 Bad Request error is returned if used for other methods or resource types. If this parameter is not present, the notifications will continue until the subscription is terminated. Values in the future are valid. If this query parameter is supported by the server, then the "replay" query parameter URI MUST be listed in the "capability" leaf-list in Section 9.3. The "start-time" query parameter MUST also be supported by the server. If the "replay-support" leaf is present in the "stream" entry (defined in Section 9.3) then the server MUST support the "start-time" and "stop-time" query parameters for that stream. 4.8.11. The "with-defaults" Query Parameter The "with-defaults" parameter is used to specify how information about default data nodes should be returned in response to GET requests on data resources. If the server supports this capability, then it MUST implement the behavior in section 4.5.1 of [RFC6243], except applied to the RESTCONF GET operation, instead of the NETCONF operations. +-------------------+-----------------------------------------------+ | Value | Description | +-------------------+-----------------------------------------------+ | report-all | All data nodes are reported | | trim | Data nodes set to the YANG default are not | | | reported | | explicit | Data nodes set by the client are not reported | | report-all-tagged | All data nodes are reported and defaults are | | | tagged | +-------------------+-----------------------------------------------+ Bierman, et al. Expires July 20, 2015 [Page 40] Internet-Draft RESTCONF January 2015 If the "with-defaults" parameter is set to "report-all" then the server MUST adhere to the defaults reporting behavior defined in section 3.1 of [RFC6243]. If the "with-defaults" parameter is set to "trim" then the server MUST adhere to the defaults reporting behavior defined in section 3.2 of [RFC6243]. If the "with-defaults" parameter is set to "explicit" then the server MUST adhere to the defaults reporting behavior defined in section 3.3 of [RFC6243]. If the "with-defaults" parameter is set to "report-all-tagged" then the server MUST adhere to the defaults reporting behavior defined in section 3.4 of [RFC6243]. RW: I can understand how this works if XML data is being returned, but what is the equivalent on a XML attribute in JSON to tag a particular field as being default? If the "with-defaults" parameter is not present then the server MUST adhere to the defaults reporting behavior defined in its "basic-mode" parameter for the "defaults" protocol capability URI, defined in Section 4.8.2. If the server includes the "restconf-with-defaults" query parameter URI in the "capability" leaf-list in Section 9.3, then the "with-defaults" query parameter MUST be supported. 5. Messages The RESTCONF protocol uses HTTP entities for messages. A single HTTP message corresponds to a single protocol method. Most messages can perform a single task on a single resource, such as retrieving a resource or editing a resource. The exception is the PATCH method, which allows multiple datastore edits within a single message. RW: Where is it documented how multiple updates are possible with a single PATCH method? I've found it later - perhaps cross reference section 5.4 5.1. Request URI Structure Resources are represented with URIs following the structure for generic URIs in [RFC3986]. A RESTCONF operation is derived from the HTTP method and the request URI, using the following conceptual fields: //?# Bierman, et al. Expires July 20, 2015 [Page 41] Internet-Draft RESTCONF January 2015 ^ ^ ^ ^ ^ | | | | | method entry resource query fragment M M O O I M=mandatory, O=optional, I=ignored replaced by client with real values o method: the HTTP method identifying the RESTCONF operation requested by the client, to act upon the target resource specified in the request URI. RESTCONF operation details are described in Section 4. o entry: the root of the RESTCONF API configured on this HTTP server, discovered by getting the ".well-known/host-meta" resource, as described in Section 3.1. o resource: the path expression identifying the resource that is being accessed by the operation. If this field is not present, then the target resource is the API itself, represented by the media type "application/yang.api". o query: the set of parameters associated with the RESTCONF message. These have the familiar form of "name=value" pairs. All query parameters are optional to implement by the server and optional to use by the client. Each query parameter is identified by a URI. The server MUST list the query parameter URIs it supports in the "capabilities" list defined in Section 9.3. There is a specific set of parameters defined, although the server MAY choose to support query parameters not defined in this document. The contents of the any query parameter value MUST be encoded according to [RFC2396], section 3.4. Any reserved characters MUST be encoded with escape sequences, according to [RFC2396], section 2.4. o fragment: This field is not used by the RESTCONF protocol. When new resources are created by the client, a "Location" header is returned, which identifies the path of the newly created resource. The client MUST use this exact path identifier to access the resource once it has been created. The "target" of an operation is a resource. The "path" field in the request URI represents the target resource for the operation. Bierman, et al. Expires July 20, 2015 [Page 42] Internet-Draft RESTCONF January 2015 5.2. Message Headers There are several HTTP header lines utilized in RESTCONF messages. Messages are not limited to the HTTP headers listed in this section. HTTP defines which header lines are required for particular circumstances. Refer to each operation definition section in Section 4 for examples on how particular headers are used. There are some request headers that are used within RESTCONF, usually applied to data resources. The following tables summarize the headers most relevant in RESTCONF message requests: +---------------------+---------------------------------------------+ | Name | Description | +---------------------+---------------------------------------------+ | Accept | Response Content-Types that are acceptable | | Content-Type | The media type of the request body | | Host | The host address of the server | | If-Match | Only perform the action if the entity | | | matches ETag | | If-Modified-Since | Only perform the action if modified since | | | time | | If-Unmodified-Since | Only perform the action if un-modified | | | since time | +---------------------+---------------------------------------------+ RESTCONF Request Headers The following tables summarize the headers most relevant in RESTCONF message responses: +---------------+---------------------------------------------------+ | Name | Description | +---------------+---------------------------------------------------+ | Allow | Valid actions when 405 error returned | | Cache-Control | The cache control parameters for the response | | Content-Type | The media type of the response message-body | | Date | The date and time the message was sent | | ETag | An identifier for a specific version of a | | | resource | | Last-Modified | The last modified date and time of a resource | | Location | The resource identifier for a newly created | | | resource | +---------------+---------------------------------------------------+ RESTCONF Response Headers Bierman, et al. Expires July 20, 2015 [Page 43] Internet-Draft RESTCONF January 2015 5.3. Message Encoding RESTCONF messages are encoded in HTTP according to [RFC7230]. The "utf-8" character set is used for all messages. RESTCONF message content is sent in the HTTP message-body. Content is encoded in either JSON or XML format. A server MUST support XML encoding and MAY support JSON encoding. XML encoding rules for data nodes are defined in [RFC6020]. The same encoding rules are used for all XML content. JSON encoding rules are defined in [I-D.ietf-netmod-yang-json]. This encoding is valid JSON, but also has special encoding rules to identify module namespaces and provide consistent type processing of YANG data. RW: Why is support for XML encoding mandatory? I thought that XML was quickly going out of fashion - shouldn't this be left to the implementation. Request input content encoding format is identified with the Content- Type header. This field MUST be present if a message-body is sent by the client. Response output content encoding format is identified with the Accept header in the request, or if is not specified, the request input encoding format is used. If there was no request input, then the default output encoding is XML. File extensions encoded in the request are not used to identify format encoding. 5.4. RESTCONF Meta-Data The RESTCONF protocol needs to retrieve the same meta-data that is used in the NETCONF protocol. Information about default leafs, last- modified timestamps, etc. are commonly used to annotate representations of the datastore contents. This meta-data is not defined in the YANG schema because it applies to the datastore, and is common across all data nodes. This information is encoded as attributes in XML. JSON encoding of meta-data is defined in [I-D.lhotka-netmod-yang-metadata]. 5.5. Return Status Each message represents some sort of resource access. An HTTP "Status-Line" header line is returned for each request. If a 4xx or 5xx range status code is returned in the Status-Line, then the error information will be returned in the response, according to the format defined in Section 7.1. Bierman, et al. Expires July 20, 2015 [Page 44] Internet-Draft RESTCONF January 2015 5.6. Message Caching Since the datastore contents change at unpredictable times, responses from a RESTCONF server generally SHOULD NOT be cached. The server SHOULD include a "Cache-Control" header in every response that specifies whether the response should be cached. A "Pragma" header specifying "no-cache" MAY also be sent in case the "Cache-Control" header is not supported. Instead of using HTTP caching, the client SHOULD track the "ETag" and/or "Last-Modified" headers returned by the server for the datastore resource (or data resource if the server supports it). A retrieval request for a resource can include the "If-None-Match" and/ or "If-Modified-Since" headers, which will cause the server to return a "304 Not Modified" Status-Line if the resource has not changed. The client MAY use the HEAD method to retrieve just the message headers, which SHOULD include the "ETag" and "Last-Modified" headers, if this meta-data is maintained for the target resource. 6. Notifications The RESTCONF protocol supports YANG-defined event notifications. The solution preserves aspects of NETCONF Event Notifications [RFC5277] while utilizing the Server-Sent Events [W3C.CR-eventsource-20121211] transport strategy. 6.1. Server Support A RESTCONF server is not required to support RESTCONF notifications. Clients may determine if a server supports RESTCONF notifications by using the HTTP operation OPTIONS, HEAD, or GET on the stream list. The server does not support RESTCONF notifications if an HTTP error code is returned (e.g., 404 Not Found). 6.2. Event Streams A RESTCONF server that supports notifications will populate a stream resource for each notification delivery service access point. A RESTCONF client can retrieve the list of supported event streams from a RESTCONF server using the GET operation on the stream list. The "restconf-state/streams" container definition in the "ietf-restconf-monitoring" module (defined in Section 9.3) is used to specify the structure and syntax of the conceptual child resources within the "streams" resource. For example: Bierman, et al. Expires July 20, 2015 [Page 45] Internet-Draft RESTCONF January 2015 The client might send the following request: GET /restconf/data/ietf-restconf-monitoring:restconf-state/ streams HTTP/1.1 Host: example.com Accept: application/yang.data+xml, application/yang.errors+xml The server might send the following response: HTTP/1.1 200 OK Content-Type: application/yang.api+xml Bierman, et al. Expires July 20, 2015 [Page 46] Internet-Draft RESTCONF January 2015 NETCONF default NETCONF event stream true 2007-07-08T00:00:00Z xml http://example.com/streams/NETCONF json http://example.com/streams/NETCONF-JSON SNMP SNMP notifications false xml http://example.com/streams/SNMP syslog-critical Critical and higher severity true 2007-07-01T00:00:00Z xml http://example.com/streams/syslog-critical Bierman, et al. Expires July 20, 2015 [Page 47] Internet-Draft RESTCONF January 2015 6.3. Subscribing to Receive Notifications RESTCONF clients can determine the URL for the subscription resource (to receive notifications) by sending an HTTP GET request for the "events" leaf with the stream list entry. The value returned by the server can be used for the actual notification subscription. The client will send an HTTP GET request for the URL returned by the server with the "Accept" type "text/event-stream". The server will treat the connection as an event stream, using the Server Sent Events [W3C.CR-eventsource-20121211] transport strategy. The server MAY support query parameters for a GET method on this resource. These parameters are specific to each notification stream. For example: The client might send the following request: GET /restconf/data/ietf-restconf-monitoring:restconf-state/ streams/stream=NETCONF/encoding=xml/events HTTP/1.1 Host: example.com Accept: application/yang.data+xml, application/yang.errors+xml The server might send the following response: HTTP/1.1 200 OK Content-Type: application/yang.api+xml http://example.com/streams/NETCONF The RESTCONF client can then use this URL value to start monitoring the event stream: GET /streams/NETCONF HTTP/1.1 Host: example.com Accept: text/event-stream Cache-Control: no-cache Connection: keep-alive A RESTCONF client MAY request the server compress the events using the HTTP header field "Accept-Encoding". For instance: Bierman, et al. Expires July 20, 2015 [Page 48] Internet-Draft RESTCONF January 2015 GET /streams/NETCONF HTTP/1.1 Host: example.com Accept: text/event-stream Cache-Control: no-cache Connection: keep-alive Accept-Encoding: gzip, deflate 6.3.1. NETCONF Event Stream The server SHOULD support the "NETCONF" notification stream defined in [RFC5277]. For this stream, RESTCONF notification subscription requests MAY specify parameters indicating the events it wishes to receive. These query parameters are optional to implement, and only available if the server supports them. +------------+---------+-------------------------+ | Name | Section | Description | +------------+---------+-------------------------+ | start-time | 4.8.9 | replay event start time | | stop-time | 4.8.10 | replay event stop time | | filter | 4.8.8 | boolean content filter | +------------+---------+-------------------------+ NETCONF Stream Query Parameters The semantics and syntax for these query parameters are defined in the sections listed above. The YANG encoding MUST be converted to URL-encoded string for use in the request URI. Refer to Appendix D.3.6 for filter parameter examples. 6.4. Receiving Event Notifications RESTCONF notifications are encoded according to the definition of the event stream. The NETCONF stream defined in [RFC5277] is encoded in XML format. The structure of the event data is based on the "notification" element definition in section 4 of [RFC5277]. It MUST conform to the schema for the "notification" element in section 4 of [RFC5277], except the XML namespace for this element is defined as: urn:ietf:params:xml:ns:yang:ietf-restconf For JSON encoding purposes, the module name is "ietf-restconf". An example SSE notification encoded using XML: Bierman, et al. Expires July 20, 2015 [Page 49] Internet-Draft RESTCONF January 2015 data: data: 2013-12-21T00:01:00Z data: data: fault data: data: Ethernet0 data: data: major data: data: An example SSE notification encoded using JSON: data: { data: "ietf-restconf:notification": { data: "event-time": "2013-12-21T00:01:00Z", data: "example-mod:event": { data: "event-class": "fault", data: "reporting-entity": { "card": "Ethernet0" }, data: "severity": "major" data: } data: } data: } Alternatively, since neither XML nor JSON are whitespace sensitive, the above messages can be encoded onto a single line. For example: For example: ('\' line wrapping added for formatting only) XML: data: 2013-12-21T00:01:00ZfaultEthernet0\ major JSON: data: {"ietf-restconf:notification":{"event-time":"2013-12-21\ T00:01:00Z","example-mod:event":{"event-class": "fault","repor\ tingEntity":{"card":"Ethernet0"},"severity":"major"}}} The SSE specifications supports the following additional fields: event, id and retry. A RESTCONF server MAY send the "retry" field and, if it does, RESTCONF clients SHOULD use it. A RESTCONF server SHOULD NOT send the "event" or "id" fields, as there are no Bierman, et al. Expires July 20, 2015 [Page 50] Internet-Draft RESTCONF January 2015 meaningful values that could be used for them that would not be redundant to the contents of the notification itself. RESTCONF servers that do not send the "id" field also do not need to support the HTTP header "Last-Event-Id". RESTCONF servers that do send the "id" field MUST still support the "startTime" query parameter as the preferred means for a client to specify where to restart the event stream. 7. Error Reporting HTTP Status-Lines are used to report success or failure for RESTCONF operations. The element returned in NETCONF error responses contains some useful information. This error information is adapted for use in RESTCONF, and error information is returned for "4xx" class of status codes. The following table summarizes the return status codes used specifically by RESTCONF operations: +---------------------------+---------------------------------------+ | Status-Line | Description | +---------------------------+---------------------------------------+ | 100 Continue | POST accepted, 201 should follow | | 200 OK | Success with response message-body | | 201 Created | POST to create a resource success | | 202 Accepted | POST to create a resource accepted | | 204 No Content | Success without response message-body | | 304 Not Modified | Conditional operation not done | | 400 Bad Request | Invalid request message | | 403 Forbidden | Access to resource denied | | 404 Not Found | Resource target or resource node not | | | found | | 405 Method Not Allowed | Method not allowed for target | | | resource | | 409 Conflict | Resource or lock in use | | 412 Precondition Failed | Conditional method is false | | 413 Request Entity Too | too-big error | | Large | | | 414 Request-URI Too Large | too-big error | | 415 Unsupported Media | non RESTCONF media type | | Type | | | 500 Internal Server Error | operation-failed | | 501 Not Implemented | unknown-operation | | 503 Service Unavailable | Recoverable server error | +---------------------------+---------------------------------------+ HTTP Status Codes used in RESTCONF Bierman, et al. Expires July 20, 2015 [Page 51] Internet-Draft RESTCONF January 2015 Since an operation resource is defined with a YANG "rpc" statement, a mapping between the NETCONF value and the HTTP status code is needed. The specific error condition and response code to use are data-model specific and might be contained in the YANG "description" statement for the "rpc" statement. +-------------------------+-------------+ | | status code | +-------------------------+-------------+ | in-use | 409 | | invalid-value | 400 | | too-big | 413 | | missing-attribute | 400 | | bad-attribute | 400 | | unknown-attribute | 400 | | bad-element | 400 | | unknown-element | 400 | | unknown-namespace | 400 | | access-denied | 403 | | lock-denied | 409 | | resource-denied | 409 | | rollback-failed | 500 | | data-exists | 409 | | data-missing | 409 | | operation-not-supported | 501 | | operation-failed | 500 | | partial-operation | 500 | | malformed-message | 400 | +-------------------------+-------------+ Mapping from error-tag to status code 7.1. Error Response Message When an error occurs for a request message on a data resource or an operation resource, and a "4xx" class of status codes (except for status code "403 Forbidden"), then the server SHOULD send a response message-body containing the information described by the "errors" container definition within the YANG module Section 8. The Content- Type of this response message MUST be application/yang.errors. YANG Tree Diagram for Data: Bierman, et al. Expires July 20, 2015 [Page 52] Internet-Draft RESTCONF January 2015 +--ro errors +--ro error +--ro error-type enumeration +--ro error-tag string +--ro error-app-tag? string +--ro (error-node)? | +--:(error-path) | | +--ro error-path? instance-identifier | +--:(error-urlpath) | +--ro error-urlpath? data-resource-identifier +--ro error-message? string +--ro error-info The semantics and syntax for RESTCONF error messages are defined in the "application/yang.errors" restconf-resource extension in Section 8. Examples: The following example shows an error returned for an "lock-denied" error that can occur if a NETCONF client has locked a datastore. The RESTCONF client is attempting to delete a data resource. DELETE /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1 Host: example.com The server might respond: HTTP/1.1 409 Conflict Date: Mon, 23 Apr 2012 17:11:00 GMT Server: example-server Content-Type: application/yang.errors+json { "ietf-restconf:errors": { "error": { "error-type": "protocol", "error-tag": "lock-denied", "error-message": "Lock failed, lock already held" } } } The following example shows an error returned for a "data-exists" error on a data resource. The "jukebox" resource already exists so it cannot be created. Bierman, et al. Expires July 20, 2015 [Page 53] Internet-Draft RESTCONF January 2015 The client might send: POST /restconf/data/example-jukebox:jukebox HTTP/1.1 Host: example.com The server might respond: HTTP/1.1 409 Conflict Date: Mon, 23 Apr 2012 17:11:00 GMT Server: example-server Content-Type: application/yang.errors+json { "ietf-restconf:errors": { "error": { "error-type": "protocol", "error-tag": "data-exists", "error-urlpath": "http://example.com/restconf/data/ example-jukebox:jukebox", "error-message": "Data already exists, cannot create new resource" } } } 8. RESTCONF module The "ietf-restconf" module defines conceptual definitions within an extension and two groupings, which are not meant to be implemented as datastore contents by a server. E.g., the "restconf" container is not intended to be implemented as a top-level data node (under the "/restconf/data" entry point). RFC Ed.: update the date below with the date of RFC publication and remove this note. file "ietf-restconf@2015-01-13.yang" module ietf-restconf { namespace "urn:ietf:params:xml:ns:yang:ietf-restconf"; prefix "rc"; organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: Bierman, et al. Expires July 20, 2015 [Page 54] Internet-Draft RESTCONF January 2015 WG Chair: Bert Wijnen WG Chair: Mehmet Ersue Editor: Andy Bierman Editor: Martin Bjorklund Editor: Kent Watsen "; description "This module contains conceptual YANG specifications for basic RESTCONF resource definitions used in RESTCONF protocol messages. Note that the YANG definitions within this module do not represent configuration data of any kind. The YANG grouping statements provide a normative syntax for XML and JSON message encoding purposes. Copyright (c) 2015 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: remove this note // Note: extracted from draft-ietf-netconf-restconf-04.txt // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2015-01-13 { description Bierman, et al. Expires July 20, 2015 [Page 55] Internet-Draft RESTCONF January 2015 "Initial revision."; reference "RFC XXXX: RESTCONF Protocol."; } extension restconf-resource { argument resource-id { yin-element true; } description "This extension is used to specify a YANG data structure which represents a specific RESTCONF resource type. Data definition statements within this extension specify the syntax for the specific resource type. The namespace URI and module name for the module containing this extension statement are used for encoding purposes. The 'resource-id' parameter value identifies the RESTCONF resource media type that is defined being defined. This extension is ignored unless it appears as a top-level statement. It SHOULD contain data definition statements that result in exactly one container or leaf data node definition. The module name and namespace value for the YANG module using the extension statement is assigned to instance document data conforming to the data definition statements within this extension. The sub-statements of this extension MUST follow the 'data-def-stmt' rule in the YANG ABNF. The XPath document root is the extension statement itself, such that the child nodes of the document root are represented by the data-def-stmt sub-statements within this extension. This conceptual document is the context for the following YANG statements: - must-stmt - when-stmt - path-stmt - min-elements-stmt - max-elements-stmt - mandatory-stmt - unique-stmt Bierman, et al. Expires July 20, 2015 [Page 56] Internet-Draft RESTCONF January 2015 - ordered-by The following data-def-stmt sub-statements have special meaning when used within a restconf-resource extension statement. - The list-stmt is not required to have a key-stmt defined. - The if-feature-stmt is ignored if present. - The config-stmt is ignored if present. - The available identity values for any 'identityref' leaf or leaf-list nodes is limited to the module containing this extension statement, and the modules imported into that module. "; } rc:restconf-resource "application/yang.errors" { uses errors; } rc:restconf-resource "application/yang.api" { uses restconf; } typedef data-resource-identifier { type string { length "1 .. max"; } description "Contains a Data Resource Identifier formatted string to identify a specific data resource instance. The document root for all data resources is a datastore resource container. Each top-level YANG data nodes supported by the server will be represented as a child node of the document root. The canonical representation of a data resource identifier includes the full server specification that is returned in the Location header when a new data resource is created with the POST method. The abbreviated representation does not contain any server location identification. Instead the identifier will start with the '/' character to represent the datastore document root for the data resource instance. Bierman, et al. Expires July 20, 2015 [Page 57] Internet-Draft RESTCONF January 2015 The server MUST accept either representation and SHOULD return the canonical representation in any response message."; reference "RFC XXXX: [sec. 5.3.1.1 ABNF For Data Resource Identifiers]"; } grouping errors { description "A grouping that contains a YANG container representing the syntax and semantics of a YANG Patch errors report within a response message."; container errors { description "Represents an error report returned by the server if a request results in an error."; list error { description "An entry containing information about one specific error that occurred while processing a RESTCONF request."; reference "RFC 6241, Section 4.3"; leaf error-type { type enumeration { enum transport { description "The transport layer"; } enum rpc { description "The rpc or notification layer"; } enum protocol { description "The protocol operation layer"; } enum application { description "The server application layer"; } } mandatory true; description "The protocol layer where the error occurred."; } leaf error-tag { type string; mandatory true; Bierman, et al. Expires July 20, 2015 [Page 58] Internet-Draft RESTCONF January 2015 description "The enumerated error tag."; } leaf error-app-tag { type string; description "The application-specific error tag."; } choice error-node { description "The server will return the location of the error node in a format that is appropriate for the protocol. If no specific node within the request message body caused the error then this choice will not be present."; leaf error-path { type instance-identifier; description "The YANG instance identifier associated with the error node. This leaf will only be present if the error node is not a data resource, e.g., the error node is an input parameter for an operation resource."; } leaf error-urlpath { type data-resource-identifier; description "The target data resource identifier associated with the error node. This leaf will only be present if the error node is associated with a data resource (either within the server or in the request message)."; } } leaf error-message { type string; description "A message describing the error."; } anyxml error-info { description "Arbitrary XML that represents a container of additional information for the error report."; } Bierman, et al. Expires July 20, 2015 [Page 59] Internet-Draft RESTCONF January 2015 } } } // grouping errors grouping restconf { description "Conceptual container representing the application/yang.api resource type."; container restconf { description "Conceptual container representing the application/yang.api resource type."; container data { description "Container representing the application/yang.datastore resource type. Represents the conceptual root of all operational data and configuration data supported by the server. The child nodes of this container can be any data resource (application/yang.data), which are defined as top-level data nodes from the YANG modules advertised by the server in the ietf-restconf-monitoring module."; } container operations { description "Container for all operation resources (application/yang.operation), Each resource is represented as an empty leaf with the name of the RPC operation from the YANG rpc statement. E.g.; POST /restconf/operations/show-log-errors leaf show-log-errors { type empty; } "; } } // container restconf } // grouping restconf Bierman, et al. Expires July 20, 2015 [Page 60] Internet-Draft RESTCONF January 2015 } 9. RESTCONF Monitoring The "ietf-restconf-monitoring" module provides information about the RESTCONF protocol capabilities and notification event streams available from the server. Implementation is mandatory for RESTCONF servers, if any protocol capabilities or notification event streams are supported. YANG Tree Diagram for "ietf-restconf-monitoring" module: +--ro restconf-state +--ro capabilities | +--ro capability* inet:uri +--ro streams +--ro stream* [name] +--ro name string +--ro description? string +--ro replay-support? boolean +--ro replay-log-creation-time? yang:date-and-time +--ro encoding* [type] +--ro type string +--ro events inet:uri 9.1. restconf-state/capabilities This mandatory container holds the RESTCONF protocol capability URIs supported by the server. The server MUST maintain a last-modified timestamp for this container, and return the "Last-Modified" header when this data node is retrieved with the GET or HEAD methods. The server SHOULD maintain an entity-tag for this container, and return the "ETag" header when this data node is retrieved with the GET or HEAD methods. 9.2. restconf-state/streams This optional container provides access to the notification event streams supported by the server. The server MAY omit this container if no notification event streams are supported. The server will populate this container with a stream list entry for each stream type it supports. Each stream contains a leaf called Bierman, et al. Expires July 20, 2015 [Page 61] Internet-Draft RESTCONF January 2015 "events" which contains a URI that represents an event stream resource. Stream resources are defined in Section 3.8. Notifications are defined in Section 6. 9.3. RESTCONF Monitoring Module The "ietf-restconf-monitoring" module defines monitoring information for the RESTCONF protocol. The "ietf-yang-types" and "ietf-inet-types" modules from [RFC6991] are used by this module for some type definitions. RFC Ed.: update the date below with the date of RFC publication and remove this note. file "ietf-restconf-monitoring@2015-01-13.yang" module ietf-restconf-monitoring { namespace "urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring"; prefix "rcmon"; import ietf-yang-types { prefix yang; } import ietf-inet-types { prefix inet; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: WG Chair: Bert Wijnen WG Chair: Mehmet Ersue Editor: Andy Bierman Editor: Martin Bjorklund Editor: Kent Watsen "; Bierman, et al. Expires July 20, 2015 [Page 62] Internet-Draft RESTCONF January 2015 description "This module contains monitoring information for the RESTCONF protocol. Copyright (c) 2015 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: remove this note // Note: extracted from draft-ietf-netconf-restconf-04.txt // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2015-01-13 { description "Initial revision."; reference "RFC XXXX: RESTCONF Protocol."; } container restconf-state { config false; description "Contains RESTCONF protocol monitoring information."; container capabilities { description "Contains a list of protocol capability URIs"; leaf-list capability { type inet:uri; description "A RESTCONF protocol capability URI."; } } container streams { Bierman, et al. Expires July 20, 2015 [Page 63] Internet-Draft RESTCONF January 2015 description "Container representing the notification event streams supported by the server."; reference "RFC 5277, Section 3.4, element."; list stream { key name; description "Each entry describes an event stream supported by the server."; leaf name { type string; description "The stream name"; reference "RFC 5277, Section 3.4, element."; } leaf description { type string; description "Description of stream content"; reference "RFC 5277, Section 3.4, element."; } leaf replay-support { type boolean; description "Indicates if replay buffer supported for this stream. If 'true', then the server MUST support the 'start-time' and 'stop-time' query parameters for this stream."; reference "RFC 5277, Section 3.4, element."; } leaf replay-log-creation-time { when "../replay-support" { description "Only present if notification replay is supported"; } type yang:date-and-time; description "Indicates the time the replay log for this stream was created."; reference "RFC 5277, Section 3.4, element."; } Bierman, et al. Expires July 20, 2015 [Page 64] Internet-Draft RESTCONF January 2015 list encoding { key type; min-elements 1; description "The server will create an entry in this list for each encoding format that is supported for this stream. The media type 'application/yang.stream' is expected for all event streams. This list identifies the sub-types supported for this stream."; leaf type { type string; description "This is the secondary encoding format within the 'text/event-stream' encoding used by all streams. The type 'xml' is supported for the media type 'application/yang.stream+xml'. The type 'json' is supported for the media type 'application/yang.stream+json'."; } leaf events { type inet:uri; mandatory true; description "Contains a URL that represents the entry point for establishing notification delivery via server sent events."; } } } } } } 10. YANG Module Library The "ietf-yang-library" module provides information about the YANG modules and submodules used by the RESTCONF server. Implementation is mandatory for RESTCONF servers. All YANG modules and submodules used by the server MUST be identified in the YANG module library. YANG Tree Diagram for "ietf-yang-library" module: Bierman, et al. Expires July 20, 2015 [Page 65] Internet-Draft RESTCONF January 2015 +--ro modules +--ro module-set-id? string +--ro module* [name revision] +--ro name yang:yang-identifier +--ro revision union +--ro schema? inet:uri +--ro namespace inet:uri +--ro feature* yang:yang-identifier +--ro deviation* yang:yang-identifier +--ro conformance boolean +--ro submodules +--ro submodule* [name revision] +--ro name yang:yang-identifier +--ro revision union +--ro schema? inet:uri 10.1. modules This mandatory container holds the identifiers for the YANG data model modules supported by the server. The server MUST maintain a last-modified timestamp for this container, and return the "Last-Modified" header when this data node is retrieved with the GET or HEAD methods. The server SHOULD maintain an entity-tag for this container, and return the "ETag" header when this data node is retrieved with the GET or HEAD methods. 10.1.1. modules/module This mandatory list contains one entry for each YANG data model module supported by the server. There MUST be an instance of this list for every YANG module that is used by the server. The contents of the "module" list are defined in the "module" YANG list statement in Section 10.2. The server MAY maintain a last-modified timestamp for each instance of this list entry, and return the "Last-Modified" header when this data node is retrieved with the GET or HEAD methods. If not supported then the timestamp for the parent "modules" container MAY be used instead. The server MAY maintain an entity-tag for each instance of this list entry, and return the "ETag" header when this data node is retrieved with the GET or HEAD methods. If not supported then the timestamp for the parent "modules" container MAY be used instead. Bierman, et al. Expires July 20, 2015 [Page 66] Internet-Draft RESTCONF January 2015 10.2. YANG Library Module The "ietf-yang-library" module defines monitoring information for the YANG modules used by a RESTCONF server. The "ietf-yang-types" and "ietf-inet-types" modules from [RFC6991] are used by this module for some type definitions. RFC Ed.: update the date below with the date of RFC publication and remove this note. file "ietf-yang-library@2015-01-13.yang" module ietf-yang-library { namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library"; prefix "yanglib"; import ietf-yang-types { prefix yang; } import ietf-inet-types { prefix inet; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: WG Chair: Bert Wijnen WG Chair: Mehmet Ersue Editor: Andy Bierman Editor: Martin Bjorklund Editor: Kent Watsen "; description "This module contains monitoring information about the YANG modules and submodules that are used within a RESTCONF server. Copyright (c) 2015 IETF Trust and the persons identified as Bierman, et al. Expires July 20, 2015 [Page 67] Internet-Draft RESTCONF January 2015 authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; // RFC Ed.: replace XXXX with actual RFC number and remove this // note. // RFC Ed.: remove this note // Note: extracted from draft-ietf-netconf-restconf-04.txt // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2015-01-13 { description "Initial revision."; reference "RFC XXXX: RESTCONF Protocol."; } typedef revision-identifier { type string { pattern '\d{4}-\d{2}-\d{2}'; } description "Represents a specific date in YYYY-MM-DD format. TBD: make pattern more precise to exclude leading zeros."; } grouping module { description "The module data structure is represented as a grouping so it can be reused in configuration or another monitoring data structure."; grouping common-leafs { description "Common parameters for YANG modules and submodules."; leaf name { type yang:yang-identifier; Bierman, et al. Expires July 20, 2015 [Page 68] Internet-Draft RESTCONF January 2015 description "The YANG module or submodule name."; } leaf revision { type union { type revision-identifier; type string { length 0; } } description "The YANG module or submodule revision date. An empty string is used if no revision statement is present in the YANG module or submodule."; } leaf schema { type inet:uri; description "Contains a URL that represents the YANG schema resource for this module or submodule. This leaf will only be present if there is a URL available for retrieval of the schema for this entry."; } } list module { key "name revision"; description "Each entry represents one module currently supported by the server."; uses common-leafs; leaf namespace { type inet:uri; mandatory true; description "The XML namespace identifier for this module."; } leaf-list feature { type yang:yang-identifier; description "List of YANG feature names from this module that are supported by the server."; } leaf-list deviation { type yang:yang-identifier; description "List of YANG deviation module names used by this server to modify the conformance of the module Bierman, et al. Expires July 20, 2015 [Page 69] Internet-Draft RESTCONF January 2015 associated with this entry."; } leaf conformance { type boolean; mandatory true; description "If 'true', then the server is claiming conformance to the YANG module identified in this entry. If 'false', then the server is not claiming any conformance for the YANG module identified by this entry. The module may be needed for reusable definitions such as extensions, features, identifies, typedefs, or groupings."; } container submodules { description "Contains information about all the submodules used by the parent module entry"; list submodule { key "name revision"; description "Each entry represents one submodule within the parent module."; uses common-leafs; } } } // list module } // grouping module container modules { config false; description "Contains YANG module monitoring information."; leaf module-set-id { type string; description "Contains a server-specific identifier representing the current set of modules and submodules. The server MUST change the value of this leaf if the information represented by the 'module' list instances has changed."; } uses module; Bierman, et al. Expires July 20, 2015 [Page 70] Internet-Draft RESTCONF January 2015 } } 11. IANA Considerations 11.1. The "restconf" Relation Type This specification registers the "restconf" relation type in the Link Relation Type Registry defined by [RFC5988]: Relation Name: restconf Description: Identifies the root of RESTCONF API as configured on this HTTP server. The "restconf" relation defines the root of the API defined in RFCXXXX. Subsequent revisions of RESTCONF will use alternate relation values to support protocol versioning. Reference: RFC XXXX ` 11.2. YANG Module Registry This document registers three URIs in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is requested to be made. URI: urn:ietf:params:xml:ns:yang:ietf-restconf Registrant Contact: The NETMOD WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring Registrant Contact: The NETMOD WG of the IETF. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-yang-library Registrant Contact: The NETMOD WG of the IETF. XML: N/A, the requested URI is an XML namespace. This document registers three YANG modules in the YANG Module Names registry [RFC6020]. Bierman, et al. Expires July 20, 2015 [Page 71] Internet-Draft RESTCONF January 2015 name: ietf-restconf namespace: urn:ietf:params:xml:ns:yang:ietf-restconf prefix: rc // RFC Ed.: replace XXXX with RFC number and remove this note reference: RFC XXXX name: ietf-restconf-monitoring namespace: urn:ietf:params:xml:ns:yang:ietf-restconf-monitoring prefix: rcmon // RFC Ed.: replace XXXX with RFC number and remove this note reference: RFC XXXX name: ietf-yang-library namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library prefix: yanglib // RFC Ed.: replace XXXX with RFC number and remove this note reference: RFC XXXX 11.3. application/yang Media Sub Types The parent MIME media type for RESTCONF resources is application/ yang, which is defined in [RFC6020]. This document defines the following sub-types for this media type. - api - data - datastore - errors - operation - stream Type name: application Subtype name: yang.xxx Required parameters: TBD Optional parameters: TBD Encoding considerations: TBD Security considerations: TBD Interoperability considerations: TBD // RFC Ed.: replace XXXX with RFC number and remove this note Published specification: RFC XXXX Bierman, et al. Expires July 20, 2015 [Page 72] Internet-Draft RESTCONF January 2015 11.4. NETCONF Capability URNs This document registers several capability identifiers in "Network Configuration Protocol (NETCONF) Capability URNs" registry Index Capability Identifier ------------------------ :defaults urn:ietf:params:restconf:capability:defaults:1.0 :depth urn:ietf:params:restconf:capability:depth:1.0 :fields urn:ietf:params:restconf:capability:fields:1.0 :filter urn:ietf:params:restconf:capability:filter:1.0 :insert urn:ietf:params:restconf:capability:insert:1.0 :replay urn:ietf:params:restconf:capability:replay:1.0 :restconf-with-defaults urn:ietf:params:restconf:capability:restconf-with-defaults:1.0 12. Security Considerations This section provides security considerations for the resources defined by the RESTCONF protocol. Security considerations for HTTPS are defined in [RFC2818]. Security considerations for the content manipulated by RESTCONF can be found in the documents defining data models. This document does not specify an authentication scheme, but it does require that an authenticated NETCONF username be associated with each HTTP request. The authentication scheme MAY be implemented in the underlying transport layer (e.g., client certificates) or within the HTTP layer (e.g., Basic Auth, OAuth, etc.). RESTCONF does not itself define an authentication mechanism, authentication MUST occur in a lower layer. Implementors SHOULD provide a comprehensive authorization scheme with RESTCONF and ensure that the resulting NETCONF username is made available to the RESTCONF server. Bierman, et al. Expires July 20, 2015 [Page 73] Internet-Draft RESTCONF January 2015 Authorization of individual user access to operations and data MAY be configured via NETCONF Access Control Model (NACM) [RFC6536], as specified in Section 4. Other authorization models MAY be used, but are outside of the scope of this document. Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic eavesdropping and false data injection attacks. Configuration information often contains passwords, user names, service descriptions, and topological information, all of which are sensitive. Because of this, this protocol SHOULD be implemented carefully with adequate attention to all manner of attack one might expect to experience with other management interfaces. Different environments may well allow different rights prior to and then after authentication. When an operation is not properly authorized, the RESTCONF server MUST return HTTP error status code 401 Unauthorized. Note that authorization information can be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection. 13. Acknowledgements The authors would like to thank the following people for their contributions to this document: Ladislav Lhotka, Rex Fernando. 14. References 14.1. Normative References [I-D.ietf-netmod-yang-json] Lhotka, L., "JSON Encoding of Data Modeled with YANG", draft-ietf-netmod-yang-json-02 (work in progress), November 2014. [I-D.lhotka-netmod-yang-metadata] Lhotka, L., "Defining and Using Metadata with YANG", draft-lhotka-netmod-yang-metadata-00 (work in progress), September 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2818] Rescorla, E., "The IETF XML Registry", RFC 2818, May 2000. Bierman, et al. Expires July 20, 2015 [Page 74] Internet-Draft RESTCONF January 2015 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and T. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, March 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for NETCONF", RFC 6243, June 2011. [RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC 6415, October 2011. Bierman, et al. Expires July 20, 2015 [Page 75] Internet-Draft RESTCONF January 2015 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012. [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, March 2012. [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013. [RFC7158] Bray, T., Ed., "The JSON Data Interchange Format", RFC 7158, March 2013. [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014. [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014. [RFC7235] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014. [W3C.CR-eventsource-20121211] Hickson, I., "Server-Sent Events", World Wide Web Consortium CR CR-eventsource-20121211, December 2012, . [W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J., Sperberg-McQueen, C., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, . [draft-ietf-httpauth-basicauth-update-03] Reschke, J., "The 'Basic' HTTP Authentication Scheme", draft-ietf-httpauth-basicauth-update-03 (work in progress), Dec 2014. [draft-ietf-httpauth-digest-09] Shekh-Yusef, R., Reschke, D., and S. Bremer, "HTTP Digest Access Authentication", draft-ietf-httpauth-digest-09 (work in progress), Dec 2014. Bierman, et al. Expires July 20, 2015 [Page 76] Internet-Draft RESTCONF January 2015 [draft-ietf-netconf-rfc5539bis-07] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", draft-ietf-netconf- rfc5539bis-07 (work in progress), Dec 2014. [draft-thomson-httpbis-cant-01] Thomson, M., "Client Authentication over New TLS Connection", draft-thomson-httpbis-cant-01 (work in progress), Jul 2014. [get-off-my-lawn] Nottingham, M., "URI Design and Ownership", Best Current Practice draft-ietf-appsawg-uri-get-off-my-lawn-05, May 2014. [rest-dissertation] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000. 14.2. Informative References [XPath] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, . Appendix A. Change Log -- RFC Ed.: remove this section before publication. The RESTCONF issue tracker can be found here: https://github.com/ netconf-wg/restconf/issues A.1. 03 - 04 o renamed 'select' to 'fields' (#1) o moved collection resource and page capability to draft-ietf- netconf-restconf-collection-00 (#3) o added mandatory "defaults" protocol capability URI (#4) o added optional "with-defaults" query parameter URI (#4) o clarified authentication procedure (#9) Bierman, et al. Expires July 20, 2015 [Page 77] Internet-Draft RESTCONF January 2015 o clarified that JSON encoding of module name in a URI MUST follow the netmod-yang-json encoding rules (#14) o added restconf-resource extension (#15) o remove 'content" query parameter URI and made this parameter mandatory (#16) o clarified datastore usage o changed lock-denied error example o added with-defaults query parameter example A.2. 02 - 03 o added collection resource o added "page" query parameter capability o added "limit" and "offset" query parameters, which are available if the "page" capability is supported o added "stream list" term o fixed bugs in some examples o added "encoding" list within the "stream" list to allow different URLs for XML and JSON encoding. o made XML MUST implement and JSON MAY implement for servers o re-add JSON notification examples (previously removed) o updated JSON references A.3. 01 - 02 o moved query parameter definitions from the YANG module back to the plain text sections o made all query parameters optional to implement o defined query parameter capability URI o moved 'streams' to new YANG module (ietf-restconf-monitoring) Bierman, et al. Expires July 20, 2015 [Page 78] Internet-Draft RESTCONF January 2015 o added 'capabilities' container to new YANG module (ietf-restconf- monitoring) o moved 'modules' container to new YANG module (ietf-yang-library) o added new leaf 'module-set-id' (ietf-yang-library) o added new leaf 'conformance' (ietf-yang-library) o changed 'schema' leaf to type inet:uri that returns the location of the YANG schema (instead of returning the schema directly) o changed 'events' leaf to type inet:uri that returns the location of the event stream resource (instead of returning events directly) o changed examples for yang.api resource since the monitoring information is no longer in this resource o closed issue #1 'select parameter' since no objections to the proposed syntax o closed "encoding of list keys" issue since no objection to new encoding of list keys in a target resource URI. o moved open issues list to the issue tracker on github A.4. 00 - 01 o fixed content=nonconfig example (non-config was incorrect) o closed open issue 'message-id'. There is no need for a message-id field, and RFC 2392 does not apply. o closed open issue 'server support verification'. The headers used by RESTCONF are widely supported. o removed encoding rules from section on RESTCONF Meta-Data. This is now defined in "I-D.lhotka-netmod-yang-json". o added media type application/yang.errors to map to errors YANG grouping. Updated error examples to use new media type. o closed open issue 'additional datastores'. Support may be added in the future to identify new datastores. o closed open issue 'PATCH media type discovery'. The section on PATCH has an added sentence on the Accept-Patch header. Bierman, et al. Expires July 20, 2015 [Page 79] Internet-Draft RESTCONF January 2015 o closed open issue 'YANG to resource mapping'. Current mapping of all data nodes to resources will be used in order to allow mandatory DELETE support. The PATCH operation is optional, as well as the YANG Patch media type. o closed open issue '_self links for HATEOAS support'. It was decided that they are redundant because they can be derived from the YANG module for the specific data. o added explanatory text for the 'select' parameter. o added RESTCONF Path Resolution section for discovering the root of the RESTCONF API using the /.well-known/host-meta. o added an "error" media type to for structured error messages o added Secure Transport section requiring TLS o added Security Considerations section o removed all references to "REST-like" A.5. bierman:restconf-04 to ietf:restconf-00 o updated open issues section Appendix B. Open Issues -- RFC Ed.: remove this section before publication. The RESTCONF issues are tracked on github.com: https://github.com/netconf-wg/restconf/issues Appendix C. Example YANG Module The example YANG module used in this document represents a simple media jukebox interface. YANG Tree Diagram for "example-jukebox" Module Bierman, et al. Expires July 20, 2015 [Page 80] Internet-Draft RESTCONF January 2015 +--rw jukebox? +--rw library | +--rw artist [name] | | +--rw name string | | +--rw album [name] | | +--rw name string | | +--rw genre? identityref | | +--rw year? uint16 | | +--rw admin | | | +--rw label? string | | | +--rw catalogue-number? string | | +--rw song [name] | | +--rw name string | | +--rw location string | | +--rw format? string | | +--rw length? uint32 | +--ro artist-count? uint32 | +--ro album-count? uint32 | +--ro song-count? uint32 +--rw playlist [name] | +--rw name string | +--rw description? string | +--rw song [index] | +--rw index uint32 | +--rw id instance-identifier +--rw player +--rw gap? decimal64 rpcs: +---x play +--ro input +--ro playlist string +--ro song-number uint32 C.1. example-jukebox YANG Module module example-jukebox { namespace "http://example.com/ns/example-jukebox"; prefix "jbox"; import ietf-restconf { prefix rc; } organization "Example, Inc."; contact "support at example.com"; description "Example Jukebox Data Model Module"; revision "2014-07-03" { description "Initial version."; Bierman, et al. Expires July 20, 2015 [Page 81] Internet-Draft RESTCONF January 2015 reference "example.com document 1-4673"; } identity genre { description "Base for all genre types"; } // abbreviated list of genre classifications identity alternative { base genre; description "Alternative music"; } identity blues { base genre; description "Blues music"; } identity country { base genre; description "Country music"; } identity jazz { base genre; description "Jazz music"; } identity pop { base genre; description "Pop music"; } identity rock { base genre; description "Rock music"; } container jukebox { presence "An empty container indicates that the jukebox service is available"; description "Represents a jukebox resource, with a library, playlists, and a play operation."; container library { description "Represents the jukebox library resource."; list artist { key name; Bierman, et al. Expires July 20, 2015 [Page 82] Internet-Draft RESTCONF January 2015 description "Represents one artist resource within the jukebox library resource."; leaf name { type string { length "1 .. max"; } description "The name of the artist."; } list album { key name; description "Represents one album resource within one artist resource, within the jukebox library."; leaf name { type string { length "1 .. max"; } description "The name of the album."; } leaf genre { type identityref { base genre; } description "The genre identifying the type of music on the album."; } leaf year { type uint16 { range "1900 .. max"; } description "The year the album was released"; } container admin { description "Administrative information for the album."; leaf label { type string; description "The label that released the album."; } leaf catalogue-number { Bierman, et al. Expires July 20, 2015 [Page 83] Internet-Draft RESTCONF January 2015 type string; description "The album's catalogue number."; } } list song { key name; description "Represents one song resource within one album resource, within the jukebox library."; leaf name { type string { length "1 .. max"; } description "The name of the song"; } leaf location { type string; mandatory true; description "The file location string of the media file for the song"; } leaf format { type string; description "An identifier string for the media type for the file associated with the 'location' leaf for this entry."; } leaf length { type uint32; units "seconds"; description "The duration of this song in seconds."; } } // end list 'song' } // end list 'album' } // end list 'artist' leaf artist-count { type uint32; units "songs"; config false; description "Number of artists in the library"; } Bierman, et al. Expires July 20, 2015 [Page 84] Internet-Draft RESTCONF January 2015 leaf album-count { type uint32; units "albums"; config false; description "Number of albums in the library"; } leaf song-count { type uint32; units "songs"; config false; description "Number of songs in the library"; } } // end library list playlist { key name; description "Example configuration data resource"; leaf name { type string; description "The name of the playlist."; } leaf description { type string; description "A comment describing the playlist."; } list song { key index; ordered-by user; description "Example nested configuration data resource"; leaf index { // not really needed type uint32; description "An arbitrary integer index for this playlist song."; } leaf id { type rc:data-resource-identifier; mandatory true; description "Song identifier. Must identify an instance of Bierman, et al. Expires July 20, 2015 [Page 85] Internet-Draft RESTCONF January 2015 /jukebox/library/artist/album/song/name."; } } } container player { description "Represents the jukebox player resource."; leaf gap { type decimal64 { fraction-digits 1; range "0.0 .. 2.0"; } units "tenths of seconds"; description "Time gap between each song"; } } } rpc play { description "Control function for the jukebox player"; input { leaf playlist { type string; mandatory true; description "playlist name"; } leaf song-number { type uint32; mandatory true; description "Song number in playlist to play"; } } } } Appendix D. RESTCONF Message Examples The examples within this document use the normative YANG module defined in Section 8 and the non-normative example YANG module defined in Appendix C.1. This section shows some typical RESTCONF message exchanges. Bierman, et al. Expires July 20, 2015 [Page 86] Internet-Draft RESTCONF January 2015 D.1. Resource Retrieval Examples D.1.1. Retrieve the Top-level API Resource The client may start by retrieving the top-level API resource, using the entry point URI "{+restconf}". GET /restconf HTTP/1.1 Host: example.com Accept: application/yang.api+json, application/yang.errors+json The server might respond as follows: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Content-Type: application/yang.api+json { "ietf-restconf:restconf": { "data" : [ null ], "operations" : { "play" : [ null ] } } } To request that the response content to be encoded in XML, the "Accept" header can be used, as in this example request: GET /restconf HTTP/1.1 Host: example.com Accept: application/yang.api+xml, application/yang.errors+xml The server will return the same response either way, which might be as follows : HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.api+xml Bierman, et al. Expires July 20, 2015 [Page 87] Internet-Draft RESTCONF January 2015 D.1.2. Retrieve The Server Module Information In this example the client is retrieving the modules information from the server in JSON format: GET /restconf/data/ietf-yang-library:modules HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond as follows. HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Last-Modified: Sun, 22 Apr 2012 01:00:14 GMT Content-Type: application/yang.data+json { "ietf-yang-library:modules": { "module": [ { "name" : "foo", "revision" : "2012-01-02", "schema" : "http://example.com/mymodules/foo/2012-01-02", "namespace" : "http://example.com/ns/foo", "feature" : [ "feature1", "feature2" ], "conformance" : true }, { "name" : "foo-types", "revision" : "2012-01-05", "schema" : "http://example.com/mymodules/foo-types/2012-01-05", "schema" : [null], "namespace" : "http://example.com/ns/foo-types", "conformance" : false }, { Bierman, et al. Expires July 20, 2015 [Page 88] Internet-Draft RESTCONF January 2015 "name" : "bar", "revision" : "2012-11-05", "schema" : "http://example.com/mymodules/bar/2012-11-05", "namespace" : "http://example.com/ns/bar", "feature" : [ "bar-ext" ], "conformance" : true, "submodule" : [ { "name" : "bar-submod1", "revision" : "2012-11-05", "schema" : "http://example.com/mymodules/bar-submod1/2012-11-05" }, { "name" : "bar-submod2", "revision" : "2012-11-05", "schema" : "http://example.com/mymodules/bar-submod2/2012-11-05" } ] } ] } } D.1.3. Retrieve The Server Capability Information In this example the client is retrieving the capability information from the server in JSON format, and the server supports all the RESTCONF query parameters, plus one vendor parameter: GET /restconf/data/ietf-restconf-monitoring:restconf-state/ capabilities HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond as follows. Bierman, et al. Expires July 20, 2015 [Page 89] Internet-Draft RESTCONF January 2015 HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:02:00 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Last-Modified: Sun, 22 Apr 2012 01:00:14 GMT Content-Type: application/yang.data+json { "ietf-restconf-monitoring:capabilities": { "capability": [ "urn:ietf:params:restconf:capability:content:1.0", "urn:ietf:params:restconf:capability:depth:1.0", "urn:ietf:params:restconf:capability:fields:1.0", "urn:ietf:params:restconf:capability:filter:1.0", "urn:ietf:params:restconf:capability:insert:1.0", "urn:ietf:params:restconf:capability:point:1.0", "urn:ietf:params:restconf:capability:start-time:1.0", "urn:ietf:params:restconf:capability:stop-time:1.0", "http://example.com/capabilities/myparam" ] } } D.2. Edit Resource Examples D.2.1. Create New Data Resources To create a new "artist" resource within the "library" resource, the client might send the following request. POST /restconf/data/example-jukebox:jukebox/library HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:artist" : { "name" : "Foo Fighters" } } If the resource is created, the server might respond as follows. Note that the "Location" header line is wrapped for display purposes only: Bierman, et al. Expires July 20, 2015 [Page 90] Internet-Draft RESTCONF January 2015 HTTP/1.1 201 Created Date: Mon, 23 Apr 2012 17:02:00 GMT Server: example-server Location: http://example.com/restconf/data/ example-jukebox:jukebox/library/artist=Foo%20Fighters Last-Modified: Mon, 23 Apr 2012 17:02:00 GMT ETag: b3830f23a4c To create a new "album" resource for this artist within the "jukebox" resource, the client might send the following request. Note that the request URI header line is wrapped for display purposes only: POST /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:album" : { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2012 # note this is the wrong date } } If the resource is created, the server might respond as follows. Note that the "Location" header line is wrapped for display purposes only: HTTP/1.1 201 Created Date: Mon, 23 Apr 2012 17:03:00 GMT Server: example-server Location: http://example.com/restconf/data/ example-jukebox:jukebox/library/artist=Foo%20Fighters/ album=Wasting%20Light Last-Modified: Mon, 23 Apr 2012 17:03:00 GMT ETag: b8389233a4c D.2.2. Detect Resource Entity Tag Change In this example, the server just supports the mandatory datastore last-changed timestamp. The client has previously retrieved the "Last-Modified" header and has some value cached to provide in the following request to patch an "album" list entry with key value "Wasting Light". Only the "year" field is being updated. Bierman, et al. Expires July 20, 2015 [Page 91] Internet-Draft RESTCONF January 2015 PATCH /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album=Wasting%20Light/year HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json If-Unmodified-Since: Mon, 23 Apr 2012 17:01:00 GMT Content-Type: application/yang.data+json { "example-jukebox:year" : "2011" } In this example the datastore resource has changed since the time specified in the "If-Unmodified-Since" header. The server might respond: HTTP/1.1 412 Precondition Failed Date: Mon, 23 Apr 2012 19:01:00 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 17:45:00 GMT ETag: b34aed893a4c D.3. Query Parameter Examples D.3.1. "content" Parameter The "content" parameter is used to select the type of data child resources (configuration and/or not configuration) that are returned by the server for a GET method request. In this example, a simple YANG list that has configuration and non- configuration child resources. container events list event { key name; leaf name { type string; } leaf description { type string; } leaf event-count { type uint32; config false; } } } Example 1: content=all To retrieve all the child resources, the "content" parameter is set to "all". The client might send: Bierman, et al. Expires July 20, 2015 [Page 92] Internet-Draft RESTCONF January 2015 GET /restconf/data/example-events:events?content=all HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:11:30 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.data+json { "example-events:events" : { "event" : [ { "name" : "interface-up", "description" : "Interface up notification count", "event-count" : 42 }, { "name" : "interface-down", "description" : "Interface down notification count", "event-count" : 4 } ] } } Example 2: content=config To retrieve only the configuration child resources, the "content" parameter is set to "config" or omitted since this is the default value. Note that the "ETag" and "Last-Modified" headers are only returned if the content parameter value is "config". GET /restconf/data/example-events:events?content=config HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond: Bierman, et al. Expires July 20, 2015 [Page 93] Internet-Draft RESTCONF January 2015 HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:11:30 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 13:01:20 GMT ETag: eeeada438af Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.data+json { "example-events:events" : { "event" : [ { "name" : "interface-up", "description" : "Interface up notification count" }, { "name" : "interface-down", "description" : "Interface down notification count" } ] } } Example 3: content=nonconfig To retrieve only the non-configuration child resources, the "content" parameter is set to "nonconfig". Note that configuration ancestors (if any) and list key leafs (if any) are also returned. The client might send: GET /restconf/data/example-events:events?content=nonconfig HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond: Bierman, et al. Expires July 20, 2015 [Page 94] Internet-Draft RESTCONF January 2015 HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:11:30 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.data+json { "example-events:events" : { "event" : [ { "name" : "interface-up", "event-count" : 42 }, { "name" : "interface-down", "event-count" : 4 } ] } } D.3.2. "depth" Parameter The "depth" parameter is used to limit the number of levels of child resources that are returned by the server for a GET method request. This example shows how different values of the "depth" parameter would affect the reply content for retrieval of the top-level "jukebox" data resource. Example 1: depth=unbounded To retrieve all the child resources, the "depth" parameter is not present or set to the default value "unbounded". Note that some strings are wrapped for display purposes only. GET /restconf/data/example-jukebox:jukebox?depth=unbounded HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:11:30 GMT Server: example-server Bierman, et al. Expires July 20, 2015 [Page 95] Internet-Draft RESTCONF January 2015 Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.data+json { "example-jukebox:jukebox" : { "library" : { "artist" : [ { "name" : "Foo Fighters", "album" : [ { "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2011, "song" : [ { "name" : "Wasting Light", "location" : "/media/foo/a7/wasting-light.mp3", "format" : "MP3", "length" " 286 }, { "name" : "Rope", "location" : "/media/foo/a7/rope.mp3", "format" : "MP3", "length" " 259 } ] } ] } ] }, "playlist" : [ { "name" : "Foo-One", "description" : "example playlist 1", "song" : [ { "index" : 1, "id" : "http://example.com/restconf/data/ example-jukebox:jukebox/library/artist= Foo%20Fighters/album/Wasting%20Light/ song/Rope" }, { Bierman, et al. Expires July 20, 2015 [Page 96] Internet-Draft RESTCONF January 2015 "index" : 2, "id" : "http://example.com/restconf/data/ example-jukebox:jukebox/library/artist= Foo%20Fighters/album/Wasting%20Light/song/ Bridge%20Burning" } ] } ], "player" : { "gap" : 0.5 } } } Example 2: depth=1 To determine if 1 or more resource instances exist for a given target resource, the value "1" is used. GET /restconf/data/example-jukebox:jukebox?depth=1 HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:11:30 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.data+json { "example-jukebox:jukebox" : [null] } Example 3: depth=3 To limit the depth level to the target resource plus 2 child resource layers the value "3" is used. GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json Bierman, et al. Expires July 20, 2015 [Page 97] Internet-Draft RESTCONF January 2015 The server might respond: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:11:30 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.data+json { "example-jukebox:jukebox" : { "library" : { "artist" : [ null ] }, "playlist" : [ { "name" : "Foo-One", "description" : "example playlist 1", "song" : [ null ] } ], "player" : { "gap" : 0.5 } } } D.3.3. "fields" Parameter In this example the client is retrieving the API resource, but retrieving only the "name" and "revision" nodes from each module, in JSON format: GET /restconf/data?fields=modules/module(name;revision) HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond as follows. Bierman, et al. Expires July 20, 2015 [Page 98] Internet-Draft RESTCONF January 2015 HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Content-Type: application/yang.data+json { "ietf-yang-library:modules": { "module": [ { "name" : "example-jukebox", "revision" : "2014-07-03" }, { "name" : "ietf-restconf-monitoring", "revision" : "2015-01-13" }, { "name" : "ietf-yang-library", "revision" : "2015-01-13" } ] } } D.3.4. "insert" Parameter In this example, a new first entry in the "Foo-One" playlist is being created. Request from client: POST /restconf/data/example-jukebox:jukebox/ playlist=Foo-One?insert=first HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:song" : { "index" : 1, "id" : "/example-jukebox:jukebox/library/ artist=Foo%20Fighters/album/Wasting%20Light/song/Rope" } } Response from server: Bierman, et al. Expires July 20, 2015 [Page 99] Internet-Draft RESTCONF January 2015 HTTP/1.1 201 Created Date: Mon, 23 Apr 2012 13:01:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 13:01:20 GMT Location: http://example.com/restconf/data/ example-jukebox:jukebox/playlist=Foo-One/song=1 ETag: eeeada438af D.3.5. "point" Parameter In this example, the client is inserting a new "song" resource within an "album" resource after another song. The request URI is split for display purposes only. Request from client: POST /restconf/data/example-jukebox:jukebox/ library/artist=Foo%20Fighters/album/Wasting%20Light? insert=after&point=%2Fexample-jukebox%3Ajukebox%2F library%2Fartist%2FFoo%20Fighters%2Falbum%2F Wasting%20Light%2Fsong%2FBridge%20Burning HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:song" : { "name" : "Rope", "location" : "/media/foo/a7/rope.mp3", "format" : "MP3", "length" : 259 } } Response from server: HTTP/1.1 204 No Content Date: Mon, 23 Apr 2012 13:01:20 GMT Server: example-server Last-Modified: Mon, 23 Apr 2012 13:01:20 GMT ETag: abcada438af D.3.6. "filter" Parameter The following URIs show some examples of notification filter specifications (lines wrapped for display purposes only): Bierman, et al. Expires July 20, 2015 [Page 100] Internet-Draft RESTCONF January 2015 // filter = /event/event-class='fault' GET /mystreams/NETCONF?filter=%2Fevent%2Fevent-class%3D'fault' // filter = /event/severity<=4 GET /mystreams/NETCONF?filter=%2Fevent%2Fseverity%3C%3D4 // filter = /linkUp|/linkDown GET /mystreams/SNMP?filter=%2FlinkUp%7C%2FlinkDown // filter = /*/reporting-entity/card!='Ethernet0' GET /mystreams/NETCONF? filter=%2F*%2Freporting-entity%2Fcard%21%3D'Ethernet0' // filter = /*/email-addr[contains(.,'company.com')] GET /mystreams/critical-syslog? filter=%2F*%2Femail-addr[contains(.%2C'company.com')] // Note: the module name is used as prefix. // filter = (/example-mod:event1/name='joe' and // /example-mod:event1/status='online') GET /mystreams/NETCONF? filter=(%2Fexample-mod%3Aevent1%2Fname%3D'joe'%20and %20%2Fexample-mod%3Aevent1%2Fstatus%3D'online') D.3.7. "start-time" Parameter // start-time = 2014-10-25T10:02:00Z GET /mystreams/NETCONF?start-time=2014-10-25T10%3A02%3A00Z D.3.8. "stop-time" Parameter // stop-time = 2014-10-25T12:31:00Z GET /mystreams/NETCONF?stop-time=2014-10-25T12%3A31%3A00Z D.3.9. "with-defaults" Parameter Assume the same data model as defined in Appendix A.1 of [RFC6243]. Assume the same data set as defined in Appendix A.2 of [RFC6243]. If the server defaults-uri basic-mode is "trim", the the following request for interface "eth1" might be as follows: Without query parameter: GET /restconf/data/interfaces/interface=eth1 HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json Bierman, et al. Expires July 20, 2015 [Page 101] Internet-Draft RESTCONF January 2015 The server might respond as follows. HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Content-Type: application/yang.data+json { "example:interface": [ { "name" : "eth1", "status" : "up" } ] } Note that the "mtu" leaf is missing because it is set to the default "1500", and the server defaults handling basic-mode is "trim". With query parameter: GET /restconf/data/interfaces/interface=eth1 ?with-defaults=report-all HTTP/1.1 Host: example.com Accept: application/yang.data+json, application/yang.errors+json The server might respond as follows. HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Content-Type: application/yang.data+json { "example:interface": [ { "name" : "eth1", "mtu" : 1500, "status" : "up" } ] } Note that the server returns the "mtu" leaf because the "report-all" mode was requested with the "with-defaults" query parameter. Bierman, et al. Expires July 20, 2015 [Page 102] Internet-Draft RESTCONF January 2015 Authors' Addresses Andy Bierman YumaWorks Email: andy@yumaworks.com Martin Bjorklund Tail-f Systems Email: mbj@tail-f.com Kent Watsen Juniper Networks Email: kwatsen@juniper.net Bierman, et al. Expires July 20, 2015 [Page 103] --------------030607030104020907040007-- From nobody Mon Jan 19 05:05:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52231B2A55 for ; Mon, 19 Jan 2015 05:05:39 -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 PsgbyoYq7ceH for ; Mon, 19 Jan 2015 05:05:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9D23B1AD49B for ; Mon, 19 Jan 2015 05:05:37 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 8205F1280997; Mon, 19 Jan 2015 14:05:36 +0100 (CET) Date: Mon, 19 Jan 2015 14:05:36 +0100 (CET) Message-Id: <20150119.140536.1899748863425317662.mbj@tail-f.com> To: jumilan@cisco.com 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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: raszabo@cisco.com, skobza@cisco.com, amedvedo@cisco.com, netconf@ietf.org Subject: Re: [Netconf] message-id attribute value normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 13:05:39 -0000 Ikp1bGl1cyBNaWxhbiAtWCAoanVtaWxhbiAtIFBhbnRoZW9uIFRlY2hub2xvZ2llcyBTUk8gYXQg Q2lzY28pIiA8anVtaWxhbkBjaXNjby5jb20+IHdyb3RlOg0KPiBPaywNCj4gQnV0IHN0aWxsIHJl bWFpbnMgZm9sbG93aW5nIGluY29uc2lzdGVuY3ksIHdoaWNoIGNvdWxkIGxpdHRsZSBiaXQNCj4g Y29uZnVzZSBuZXRjb25mIHVzZXIgb3IgZGV2ZWxvcGVyOg0KPiANCj4gMS4pIOKAnFRoZSBzZW5k ZXIgTVVTVCBlbnN1cmUgdGhhdCB0aGUgIm1lc3NhZ2UtaWQiIHZhbHVlIGlzIG5vcm1hbGl6ZWQN Cj4gYWNjb3JkaW5nIHRvIOKApiBpZiB0aGUgc2VuZGVyIHdhbnRzIHRoZSBzdHJpbmcgdG8gYmUg cmV0dXJuZWQNCj4gdW5tb2RpZmllZC7igJ0NCj4gDQo+IDIuKSBBbmQgdGhlIGZhY3QgdGhhdCBt ZXNzYWdlLWlkIHNob3VsZCBub3QgYmUgbm9ybWFsaXplZCBhY2NvcmRpbmcgdG8NCj4gc2NoZW1h IChuZXRjb25mLnhzZCkuDQo+IA0KPiBJdCdzIGp1c3QgYSBkZXRhaWwsIGJ1dCB0aGVzZSAyIGZh Y3RzIGFyZSBpbiBjb25mbGljdC4NCg0KSSBkb24ndCB0aGluayB0aGVyZSdzIGEgY29uZmxpY3Qu DQoNClJlZ2FyZGxlc3Mgb2YgdGhlIFhTRCwgYW4gWE1MIGF0dHJpYnV0ZSBpcyBub3JtYWxpemVk IGFjY29yZGluZyB0byB0aGUNCnJ1bGVzIG9mIFhNTC4NCg0KVGhlIHRleHQgYmFzaWNhbGx5IHNh eXMgdGhhdCB0aGUgc2VuZGVyIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzLCB3aGVuDQpjcmVhdGlu ZyB0aGUgbWVzc2FnZS1pZCBzdHJpbmcuDQoNCk5vIFhTRCBub3JtYWxpemF0aW9uIGlzIGludm9s dmVkIGhlcmUuDQoNCg0KL21hcnRpbg0K From nobody Mon Jan 19 05:18:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9F01B2A60 for ; Mon, 19 Jan 2015 05:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vkvgPrEmx10S for ; Mon, 19 Jan 2015 05:18:33 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739CF1B2A5E for ; Mon, 19 Jan 2015 05:18:33 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t0JDISEO003739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Jan 2015 13:18:28 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0JDINR5010210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Jan 2015 14:18:25 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.32]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 14:18:24 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Julius Milan -X (jumilan - Pantheon Technologies SRO at Cisco)" , Martin Bjorklund Thread-Topic: [Netconf] message-id attribute value normalization Thread-Index: AdAxtS/196KFVEGPQJGaq2NUav0z1QAQ1GqAAHN/SxAAFRpOAAAMat7gABilLrA= Date: Mon, 19 Jan 2015 13:18:24 +0000 Message-ID: References: <20150119.140536.1899748863425317662.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.158] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2904 X-purgate-ID: 151667::1421673508-00007286-28BF4CA8/0/0 Archived-At: Cc: "Rastislav Szabo -X \(raszabo - Pantheon Technologies SRO at Cisco\)" , "Stefan Kobza -X \(skobza - Pantheon Technologies SRO at Cisco\)" , "Anna Medvedova -X \(amedvedo - Pantheon Technologies SRO at Cisco\)" , "netconf@ietf.org" Subject: Re: [Netconf] message-id attribute value normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 13:18:36 -0000 RGVhciBKdWxpdXMsIA0KDQpJIGZvcndhcmRlZCB5b3VyIGxhc3QgbWFpbCB0byBORVRDT05GIG1h aWxsaXN0Lg0KDQpQbGVhc2Ugc3Vic2NyaWJlIHRvIE5FVENPTkYgbWFpbGxpc3QgaWYgeW91IHdh bnQgdG8gc2VuZCBtYWlscyB0byBORVRDT05GIE1MLg0KDQpQbGVhc2UgbG9vayBhdCBORVRDT05G IFdpa2kgZm9yIHRoZSBzdWJzY3JpcHRpb24gaW5mbzoNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYu b3JnL3dnL25ldGNvbmYvdHJhYy93aWtpIA0KDQpDaGVlcnMsIA0KTWVobWV0IA0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKdWxpdXMgTWlsYW4gLVggKGp1bWlsYW4gLSBQ YW50aGVvbiBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKSBbbWFpbHRvOmp1bWlsYW5AY2lzY28u Y29tXSANClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxOSwgMjAxNSAyOjExIFBNDQpUbzogTWFydGlu IEJqb3JrbHVuZA0KQ2M6IGFuZHlAeXVtYXdvcmtzLmNvbTsgUmFzdGlzbGF2IFN6YWJvIC1YIChy YXN6YWJvIC0gUGFudGhlb24gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbyk7IFN0ZWZhbiBLb2J6 YSAtWCAoc2tvYnphIC0gUGFudGhlb24gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbyk7IG5ldGNv bmZAaWV0Zi5vcmc7IEFubmEgTWVkdmVkb3ZhIC1YIChhbWVkdmVkbyAtIFBhbnRoZW9uIFRlY2hu b2xvZ2llcyBTUk8gYXQgQ2lzY28pDQpTdWJqZWN0OiBSRTogW05ldGNvbmZdIG1lc3NhZ2UtaWQg YXR0cmlidXRlIHZhbHVlIG5vcm1hbGl6YXRpb24NCg0KT2ssIHRoYW5rcyBhIGxvdC4NCg0KSnVs aXVzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gQmpvcmtsdW5k IFttYWlsdG86bWJqQHRhaWwtZi5jb21dIA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDE5LCAyMDE1 IDI6MDYgUE0NClRvOiBKdWxpdXMgTWlsYW4gLVggKGp1bWlsYW4gLSBQYW50aGVvbiBUZWNobm9s b2dpZXMgU1JPIGF0IENpc2NvKQ0KQ2M6IGFuZHlAeXVtYXdvcmtzLmNvbTsgUmFzdGlzbGF2IFN6 YWJvIC1YIChyYXN6YWJvIC0gUGFudGhlb24gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbyk7IFN0 ZWZhbiBLb2J6YSAtWCAoc2tvYnphIC0gUGFudGhlb24gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNj byk7IG5ldGNvbmZAaWV0Zi5vcmc7IEFubmEgTWVkdmVkb3ZhIC1YIChhbWVkdmVkbyAtIFBhbnRo ZW9uIFRlY2hub2xvZ2llcyBTUk8gYXQgQ2lzY28pDQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIG1l c3NhZ2UtaWQgYXR0cmlidXRlIHZhbHVlIG5vcm1hbGl6YXRpb24NCg0KIkp1bGl1cyBNaWxhbiAt WCAoanVtaWxhbiAtIFBhbnRoZW9uIFRlY2hub2xvZ2llcyBTUk8gYXQgQ2lzY28pIiA8anVtaWxh bkBjaXNjby5jb20+IHdyb3RlOg0KPiBPaywNCj4gQnV0IHN0aWxsIHJlbWFpbnMgZm9sbG93aW5n IGluY29uc2lzdGVuY3ksIHdoaWNoIGNvdWxkIGxpdHRsZSBiaXQgDQo+IGNvbmZ1c2UgbmV0Y29u ZiB1c2VyIG9yIGRldmVsb3BlcjoNCj4gDQo+IDEuKSDigJxUaGUgc2VuZGVyIE1VU1QgZW5zdXJl IHRoYXQgdGhlICJtZXNzYWdlLWlkIiB2YWx1ZSBpcyBub3JtYWxpemVkIA0KPiBhY2NvcmRpbmcg dG8g4oCmIGlmIHRoZSBzZW5kZXIgd2FudHMgdGhlIHN0cmluZyB0byBiZSByZXR1cm5lZCANCj4g dW5tb2RpZmllZC7igJ0NCj4gDQo+IDIuKSBBbmQgdGhlIGZhY3QgdGhhdCBtZXNzYWdlLWlkIHNo b3VsZCBub3QgYmUgbm9ybWFsaXplZCBhY2NvcmRpbmcgdG8gDQo+IHNjaGVtYSAobmV0Y29uZi54 c2QpLg0KPiANCj4gSXQncyBqdXN0IGEgZGV0YWlsLCBidXQgdGhlc2UgMiBmYWN0cyBhcmUgaW4g Y29uZmxpY3QuDQoNCkkgZG9uJ3QgdGhpbmsgdGhlcmUncyBhIGNvbmZsaWN0Lg0KDQpSZWdhcmRs ZXNzIG9mIHRoZSBYU0QsIGFuIFhNTCBhdHRyaWJ1dGUgaXMgbm9ybWFsaXplZCBhY2NvcmRpbmcg dG8gdGhlIHJ1bGVzIG9mIFhNTC4NCg0KVGhlIHRleHQgYmFzaWNhbGx5IHNheXMgdGhhdCB0aGUg c2VuZGVyIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzLCB3aGVuIGNyZWF0aW5nIHRoZSBtZXNzYWdl LWlkIHN0cmluZy4NCg0KTm8gWFNEIG5vcm1hbGl6YXRpb24gaXMgaW52b2x2ZWQgaGVyZS4NCg0K DQovbWFydGluDQo= From nobody Mon Jan 19 05:48:25 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC701B2A61 for ; Mon, 19 Jan 2015 05:48:23 -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 kEDuOnBERSsC for ; Mon, 19 Jan 2015 05:48:21 -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 707881ACE94 for ; Mon, 19 Jan 2015 05:48:21 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 029FD13F653; Mon, 19 Jan 2015 14:48:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421675300; bh=MiOD3mhXUaq2MOuZlfyiTMZuvhMuisDjAxjRHs3ZdLo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CSpgNoNuUh7Ame0ba0hZZdVp6P/QARuBbvctXJhzQmB4FORRoNeuG2ZSmOebulx11 3H0hq06UmL6Rc+bGV7VR5oiHgBoNSYdzhtmDUQCidWaZbNpdq7htiBLSrnBWLe2d3/ AW7K2hGl9dpV/nqqbmH+eon20LAUiYbyxcZBmBKo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 19 Jan 2015 14:48:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <890FDFA5-003E-40A2-BC1B-2EA82AC527EF@nic.cz> References: <20150119.140536.1899748863425317662.mbj@tail-f.com> To: Mehmet Ersue X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: "Rastislav Szabo -X \(raszabo - Pantheon Technologies SRO at Cisco\)" , "Stefan Kobza -X \(skobza - Pantheon Technologies SRO at Cisco\)" , "Anna Medvedova -X \(amedvedo - Pantheon Technologies SRO at Cisco\)" , Netconf , "Julius Milan -X \(jumilan - Pantheon Technologies SRO at Cisco\)" Subject: Re: [Netconf] message-id attribute value normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 13:48:23 -0000 > On 19 Jan 2015, at 14:18, Ersue, Mehmet (NSN - DE/Munich) = wrote: >=20 > Dear Julius,=20 >=20 > I forwarded your last mail to NETCONF maillist. >=20 > Please subscribe to NETCONF maillist if you want to send mails to = NETCONF ML. >=20 > Please look at NETCONF Wiki for the subscription info: > http://trac.tools.ietf.org/wg/netconf/trac/wiki=20 >=20 > Cheers,=20 > Mehmet=20 >=20 >=20 > -----Original Message----- > From: Julius Milan -X (jumilan - Pantheon Technologies SRO at Cisco) = [mailto:jumilan@cisco.com]=20 > Sent: Monday, January 19, 2015 2:11 PM > To: Martin Bjorklund > Cc: andy@yumaworks.com; Rastislav Szabo -X (raszabo - Pantheon = Technologies SRO at Cisco); Stefan Kobza -X (skobza - Pantheon = Technologies SRO at Cisco); netconf@ietf.org; Anna Medvedova -X = (amedvedo - Pantheon Technologies SRO at Cisco) > Subject: RE: [Netconf] message-id attribute value normalization >=20 > Ok, thanks a lot. >=20 > Julius >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 > Sent: Monday, January 19, 2015 2:06 PM > To: Julius Milan -X (jumilan - Pantheon Technologies SRO at Cisco) > Cc: andy@yumaworks.com; Rastislav Szabo -X (raszabo - Pantheon = Technologies SRO at Cisco); Stefan Kobza -X (skobza - Pantheon = Technologies SRO at Cisco); netconf@ietf.org; Anna Medvedova -X = (amedvedo - Pantheon Technologies SRO at Cisco) > Subject: Re: [Netconf] message-id attribute value normalization >=20 > "Julius Milan -X (jumilan - Pantheon Technologies SRO at Cisco)" = wrote: >> Ok, >> But still remains following inconsistency, which could little bit=20 >> confuse netconf user or developer: >>=20 >> 1.) =E2=80=9CThe sender MUST ensure that the "message-id" value is = normalized=20 >> according to =E2=80=A6 if the sender wants the string to be returned=20= >> unmodified.=E2=80=9D >>=20 >> 2.) And the fact that message-id should not be normalized according = to=20 >> schema (netconf.xsd). >>=20 >> It's just a detail, but these 2 facts are in conflict. >=20 > I don't think there's a conflict. >=20 > Regardless of the XSD, an XML attribute is normalized according to the = rules of XML. Of course, an interesting question is how exactly the rules of sec. = 3.3.3 in XML spec apply to this case: should leading and trailing spaces = be discarded and multiple spaces collapsed to one space? See also pyang issue #64: https://code.google.com/p/pyang/issues/detail?id=3D64 Lada >=20 > The text basically says that the sender should be aware of this, when = creating the message-id string. >=20 > No XSD normalization is involved here. >=20 >=20 > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 19 07:09:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1C91B2A9B for ; Mon, 19 Jan 2015 07:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 V9f2ik5ogRpM for ; Mon, 19 Jan 2015 07:09:24 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE491B2A94 for ; Mon, 19 Jan 2015 07:09:22 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA17168; Mon, 19 Jan 2015 10:09:20 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t0JF9Kor009699; Mon, 19 Jan 2015 10:09:20 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t0JF9I4G009698; Mon, 19 Jan 2015 10:09:18 -0500 (EST) (envelope-from luchuk) Date: Mon, 19 Jan 2015 10:09:18 -0500 (EST) From: Alan Luchuk Message-Id: <201501191509.t0JF9I4G009698@mainfs.snmp.com> To: , In-Reply-To: Your message of Sun, 18 Jan 2015 15:50:40 +0000 References: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 15:09:25 -0000 Hello, >From: "Ersue, Mehmet (NSN - DE/Munich)" >To: "netconf@ietf.org" >Thread-Topic: WG Last Call for draft-ietf-netconf-rfc5539bis-07 >Date: Sun, 18 Jan 2015 15:50:40 +0000 > >Dear NETCONF WG, > >we did not get any comments yet on rfc5539bis draft during the WGLC. > >Please review and provide your comments on the document and/or >please indicate if you think the document is ready for publication. > >If we do not get any comments or support by the deadline (January 19, 2015 = >EOB PT) the WGLC will be seen as unsuccessful. SNMP Research has an implementation of RFC5539. We anticipate updating it to the latest standards as engineering resources allow. We support publishing draft-ietf-netconf-rfc5539bis-07. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From nobody Mon Jan 19 08:13:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E9A1B2AF7 for ; Mon, 19 Jan 2015 08:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 07Za7NVFbrfR for ; Mon, 19 Jan 2015 08:13:29 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBE21B2B47 for ; Mon, 19 Jan 2015 08:12:44 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA20491; Mon, 19 Jan 2015 11:12:42 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t0JGCgHF010290; Mon, 19 Jan 2015 11:12:42 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t0JGCgKk010289; Mon, 19 Jan 2015 11:12:42 -0500 (EST) (envelope-from luchuk) Date: Mon, 19 Jan 2015 11:12:42 -0500 (EST) From: Alan Luchuk Message-Id: <201501191612.t0JGCgKk010289@mainfs.snmp.com> To: , , In-Reply-To: Your message of Sat, 17 Jan 2015 00:18:30 +0000 References: <201501162128.t0GLSn2W060604@mainfs.snmp.com> X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 16:13:33 -0000 Hello, Thanks for considering the comments, and the replies and explanations. >From: Kent Watsen >To: Alan Luchuk , "netconf@ietf.org" >Subject: Re: [Netconf] draft-ietf-netconf-call-home-03.txt >Date: Sat, 17 Jan 2015 00:18:30 +0000 >>>>- The NETCONF/RESTCONF server _immediately_ starts the SSH-server or >>>> the TLS-server protocol; >>>> >>>>- The NETCONF/RESTCONF client _immediately_ starts the SSH-client or >>>> the TLS-client protocol; >>>> >>>>Is it possible for a race condition to occur that might cause SSH or TLS >>>>connection problems? >>> >>> >>>The "immediately" is meant to be interpreted more as "no more TPC data is >>>exchanged" than "without temporal delay". There isn't a race condition >>>here. Just like with a standard (not reversed) connection, the TCP >>>stacks >>>will buffer the data until the SSH/TLS layers get initialized. Do you >>>agree? >> >>Yes. > >Do you think the current text can be improved to make this interpretation >clearer? I think the text is clear as it is, and should not be changed. I made the comment because I wasn't certain whether or not a race condition existed. If there is no race condition, there is no need to change the existing text. >>Section 3.2, third paragraph: >>----------------------------- >> >>Would it be appropriate to change "credentials" to "identity"? This is >>the >>only paragraph where the term "credentials" is used. >> >>When I saw "credentials", I thought of something like a password, host >>key, >>or X.509 cert, rather than simply the server's identity. If changing >>"credentials" to "identity" is not appropriate, then perhaps adding one >>sentence that defines the term credentials. > >We could say "verify identity" as well. Think of the questions the client >is asking: > > - who is trying to connect to me? (identity) > - how do I know that it is really you? (verify identity) > Thanks! This explanation makes very good sense. These were not obvious to me upon a first read of the document. I think other new readers of the document would benefit if this explanation could be shoe-horned into the existing text, but I wouldn't delay the document to add it. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From nobody Mon Jan 19 12:04:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB88D1B2AB0 for ; Mon, 19 Jan 2015 12:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.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] 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 71XjiuwE1bAo for ; Mon, 19 Jan 2015 12:03:54 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id D806F1B2B6F for ; Mon, 19 Jan 2015 12:03:48 -0800 (PST) Received: from mainfs.snmp.com (mainfs.snmp.com [192.147.142.124]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA07437; Mon, 19 Jan 2015 15:03:34 -0500 (EST) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id t0JK3ZWb012655; Mon, 19 Jan 2015 15:03:35 -0500 (EST) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id t0JK3TR5012654; Mon, 19 Jan 2015 15:03:29 -0500 (EST) (envelope-from luchuk) Date: Mon, 19 Jan 2015 15:03:29 -0500 (EST) From: Alan Luchuk Message-Id: <201501192003.t0JK3TR5012654@mainfs.snmp.com> To: , , , "jshoenwaelder@jacobs-university.de" In-Reply-To: Your message of Sat, 17 Jan 2015 01:54:22 +0000 References: X-Mailer: mail (GNU Mailutils 2.2) Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 20:03:57 -0000 Hello, >>Page 14, Section 3.2, ietf-netconf-server.yang, nit >>--------------------------------------------------- >> >> grouping session-options-container { >> description >> ""; >> container session-options { >> >>I suggest removing the empty description. I think the reason/purpose of >>the grouping is obvious enough that a description clause does not assist >>the reader's understanding. >> >>Many of the grouping statements in the ietf-netconf-server.yang module >>and the ietf-restconf-server.yang module have empty descriptions. This >>same comment applies to them also. > >The empty descriptions are an annoying artifact of the `pyang --ietf` >option requiring descriptions on these nodes. But I agree that no >description is needed and that it looks odd as is. I could copy/paste the >entire description or has one reference the other...hmm, how about this - >look for "(see above)" below: > >OLD: > > grouping session-options-container { > description > ""; > container session-options { > description > "NETCONF session options, independent of transport or > connection strategy."; > > >NEW: > > grouping session-options-container { > description > "NETCONF session options, independent of transport or > connection strategy."; > container session-options { > description > "(see above)"; > > > >If not, do yo have a better suggestion? Leave the empty comments. No sense in making unnecessary changes. >>Page 19, Section 3.2, ietf-netconf-server.yang, clarification >>------------------------------------------------------------- >> >> leaf linger-secs { >> type uint8; >> units seconds; >> default 30; >> description >> "The amount of time the NETCONF server should wait >> after last receiving data from or sending data to >> the NETCONF client's endpoint before closing its >> connection to it. This is an optimization to >> prevent unnecessary connections."; >> } >> >>In the behavior of the periodic connection (with the 30 second >>linger-secs), >>what happens if the NETCONF server holds the idle periodic connection >>open >>for 29 seconds, then another message is exchanged on that connection? >> >>Based upon the description clause, I would expect the message would reset >>a linger timer, so the server would wait another 30 seconds before closing >>the connection. This behavior is not completely spelled out, though. > >Yes, this is the expected behavior - does it need to be spelled out? > > >>In this scenario, if one of the NETCONF peers repeatedly sends a message >>just before the linger timeout expires, the periodic connection will >>never >>be closed. Is this the desired behavior for the periodic connection, or >>would it make sense to have timer that forces a close after a certain >>maximum time period? > >Yes, it could turn out that the "periodic" connection stays open forever >due to always having activity. This is the desired behavior, as the goal >is to avoid the computationally-expensive reconnection. > > >>This same comment applies to other linger-secs values in the >>ietf-netconf-server.yang module and the ietf-restconf-server.yang >>module. > >Understood, but I currently don't believe the text is inaccurate. I'm not >planning to make any changes yet... I appreciate your clarification in this E-mail. I agree that leaving the current text unchanged unless someone else has the same question is a reasonable course of action. >>Page 23, Section 3.2, ietf-netconf-server.yang, question >>-------------------------------------------------------- >> >> grouping certificates-container { >> description >> ""; >> container certificates { >> description >> "Parent container for the list of certificates."; >> leaf-list certificate { >> type string; >> min-elements 1; >> description >> "An unordered list of certificates the TLS server can pick >> from when sending its Server Certificate message. The value >> of the string is the unique identifier for a certificate >> configured on the system. How valid values are discovered >> is outside the scope of this module, but they are envisioned >> to be the keys for a list of certificates provided >> by another YANG module"; >> reference >> "RFC 5246: The TLS Protocol, Section 7.4.2"; >> } >> } >> } >> >> >>What happens if the min-elements is not satisfied? > >How is this possible? A TLS server must have a server-cert defined... I'll have to study more about the usage of the YANG min-elements statement. For this particular case, I'm not clear on what happens if a NETCONF server is provisioned with NO certificates. In this case, the TLS components can't work, but the min-elements constraint can't be satisfied for NETCONF retrieval operations either (presumably exchanged over SSH). >>Also, what is the use case for the server having more than one >>certificate >>it can send in it Server Certificate message? How would the server >>choose >>which certificate to send in its Server Certificate message? Does this >>description need a comment about "How a certificate is chosen for sending >>in a Server Certificate message is outside the scope of this module"? > >The server may have more than one certificate using different algorithms >or key-strengths. The server may use one certificate for when listening >on port 6513 and another when it calls home. > > > >>These questions also apply to the certificates-container grouping in the >>ietf-restconf-server.yang module. > > >Understood, but no change planned yet. OK. Not trying to beat a dead horse, but it still seems like the data model would allow many (e.g., 12) certs to be provisioned on the NETCONF server. Let's say that all of the certs use the same cryptographic cipher suites and key strengths. The certs only differ in the keys (key pairs). It seems like any of the certs would be equally good for sending in the Server Certificate message. For this situation, I'm still not clear on how the NETCONF server would choose one of the certs to send in a Server Certificate message. I would probably write the code so that the server would always send the first certificate in an ordered list of some kind, and ignore all the subsequent certs. Have I missed documentation somewhere that describes how the server chooses the certificate to send? >>Page 30, Section 4.2, ietf-restconf-server.yang, question >>--------------------------------------------------------- >> >>The following snippet of the data model uses "mandatory true;". >> >> choice transport { >> mandatory true; >> description >> "Selects between available transports."; >> case tls { >> container tls { >> >>I have no idea, but should more schema nodes in both the ietf-restconf- >>server.yang module and the ietf-netconf-server.yang module be marked by >>"mandatory true;"? > >I think that they are all set correctly...I just checked Sounds fine. Thanks for checking. >>Page 38, Section 6, "Security Considerations", technical >>-------------------------------------------------------- >> >>The same could be said of the call-home nodes, and probably other nodes. > > >This issue is addressed here: >https://github.com/netconf-wg/server-model/issues/24 > >This is a bit tricky. On one hand, the entire configuration has to be >protected from unauthorized access and modification. But with NACM, the >issue is notched up a level to cover what *authorized* users are allowed >to access and/or modify. I'll look at this again when working on #24... OK. FWIW, my first quick thought about this is that unauthorized configuration of any of the data nodes could have a negative effect on network operations. I'd probably protect write access to all data nodes in the data model. Careful consideration of each node might show that some nodes are less critical, but the cost/benefit of analyzing each node would be insufficient to justify the analysis effort. Not sure about which nodes should be guarded against read access. I'd probably guard all nodes against read access. But again, an analysis would be a good, but possibly high-effort/low-benefit thing to do. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From nobody Mon Jan 19 12:45:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1D31ACE02 for ; Mon, 19 Jan 2015 12:45:26 -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 IxPJDnujd6kB for ; Mon, 19 Jan 2015 12:45: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 05B871B2C6A for ; Mon, 19 Jan 2015 12:45:22 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B9F21280997 for ; Mon, 19 Jan 2015 21:45:21 +0100 (CET) Date: Mon, 19 Jan 2015 21:46:30 +0100 (CET) Message-Id: <20150119.214630.606397666971707472.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 20:45:27 -0000 Hi, I have reviewed draft-ietf-netconf-rfc5539bis-07 and have the following mostly minor comments: o section 5 OLD: the integrity of the certificate presented by the peer. presented NEW: the integrity of the certificate presented by the peer. The presented o section 6 This section is still confusing to me. In the second sentence, the text states that "the hostname check MAY be omitted" - but the text hasn't mentioned any hostname checks so it is not clear what this refers to. The second paragraph talks about how matching is performed - but matching of what? Tom Petch suggested better text in an email from June 10, 2014, but that text was never finished, I think. o section 7 The text says: The NETCONF protocol [RFC6241] requires that the transport protocol's authentication process MUST result in an authenticated NETCONF client identity whose permissions are known to the server. I think this is an odd usage of 2119 MUST, since it merely states what NETCONF requires. I suggest: NEW: The NETCONF protocol [RFC6241] requires that the transport protocol's authentication process results in an authenticated NETCONF client identity whose permissions are known to the server. o section 7 OLD: The server maintains an ordered list of mappings of certificates to names. The username is derived by considering each list entry NEW: The server maintains an ordered list of mappings of certificates to NETCONF usernames. The username is derived by considering each list entry o section 7 The textual description of the algorithm refers to node names from the original YANG model, like 'map-type' and 'cert-to-name', without further explanation. These node names should be removed, and the intention explained instead. o section 7 I think the last sentence is wrong. The way I read it is that first we run the algorithm (matching certificates and extract a name), and then we validate this resulting name to see if it is valid. If it is not valid, we drop the session. I think that the idea is that for each list entry, we match the certificate, extract a name, and then check its validity. If the cert doesn't match, or if we cannot extract a name, or if the name is invalid, we continue to the next list entry. (in any case, the behavior described here should be clarified also in ietf-netconf-server-model) o nit s/base:1.1/:base:1.1/g (two occurences I believe - yes, this error is also present in RFC 6242, and it is really minor, but it is easy to fix here) /martin From nobody Mon Jan 19 12:53:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DC31B2C7A for ; Mon, 19 Jan 2015 12:53: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 FxakjuvQkqaR for ; Mon, 19 Jan 2015 12:53:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DB21C1B2C81 for ; Mon, 19 Jan 2015 12:53:14 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id EAC061280997; Mon, 19 Jan 2015 21:53:13 +0100 (CET) Date: Mon, 19 Jan 2015 21:54:23 +0100 (CET) Message-Id: <20150119.215423.792155738142290669.mbj@tail-f.com> To: kwatsen@juniper.net 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: netconf@ietf.org, jshoenwaelder@jacobs-university.de Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 20:53:25 -0000 Kent Watsen wrote: > >Page 14, Section 3.2, ietf-netconf-server.yang, nit > >--------------------------------------------------- > > > > grouping session-options-container { > > description > > ""; > > container session-options { > > > >I suggest removing the empty description. I think the reason/purpose of > >the grouping is obvious enough that a description clause does not assist > >the reader's understanding. > > > >Many of the grouping statements in the ietf-netconf-server.yang module > >and the ietf-restconf-server.yang module have empty descriptions. This > >same comment applies to them also. > > The empty descriptions are an annoying artifact of the `pyang --ietf` > option requiring descriptions on these nodes. But I agree that no > description is needed and that it looks odd as is. I could copy/paste the > entire description or has one reference the other...hmm, how about this - > look for "(see above)" below: pyang --ietf implements the rules defined in RFC 6087. If you really don't have anything to say, remove the statement and ignore the error - we do not want unnecessary noise in our modules! This said, I think that these groupings really should have a proper description. Or rather, I'd prefer to not define the groupings at all, but rather inline their definitions. But if you do think that these groupings are reusable, the description should explain what they are. /martin From nobody Mon Jan 19 17:42:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0A41ACE70 for ; Mon, 19 Jan 2015 17:42:47 -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 VWn-2N1_sbn4 for ; Mon, 19 Jan 2015 17:42:46 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2561B1ACE6C for ; Mon, 19 Jan 2015 17:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2458; q=dns/txt; s=iport; t=1421718166; x=1422927766; h=from:to:subject:date:message-id:mime-version; bh=Q2fuycc1uBlYqpLSgWKAoxDHGI1pQUgCktayP/Q3YsE=; b=UoEsrMnunikGWmBXvj4BglAjluugI2BQP4GAwZIKaw4D0nA0OeRWqImv gmRWyDG9k1+ZpObeBzUDn5qPZGGCQHOnuIWIVU3j3l79iG6fGa/ffWU0F BdHdrAecrwB0aub9RYXMlP2YczxjfU8dftdg5AJihVAgcb/CUFSAqrqiz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwGAICxvVStJA2K/2dsb2JhbABcgkNDgS7EHok2QwEBAQEBfYQTbR4BDAEgFj0nBIg/qkajYgEBCAIBH4xJh2AFjlmJF5IqIoIPI4E8gjR+AQEB X-IronPort-AV: E=Sophos;i="5.09,430,1418083200"; d="scan'208,217";a="388306852" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jan 2015 01:42:45 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t0K1gieY015741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 Jan 2015 01:42:45 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 19:42:44 -0600 From: "Alberto Gonzalez Prieto (albertgo)" To: "netconf@ietf.org" Thread-Topic: Question about RFC 5277: multiple concurrent subscriptions in a session and subscription identifiers Thread-Index: AQHQNFJiqg1FR/sg8ESVHOKYPbU4jA== Date: Tue, 20 Jan 2015 01:42:44 +0000 Message-ID: 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.236.56] Content-Type: multipart/alternative; boundary="_000_D0E2F2921C8F5albertgociscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Question about RFC 5277: multiple concurrent subscriptions in a session and subscription identifiers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 01:42:47 -0000 --_000_D0E2F2921C8F5albertgociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have a question about RFC 5277 and I would appreciate help with it. In the context of a single session, are multiple concurrent subscriptions s= upported? (E.g, a single client, interested in two streams, requesting two (one per stream) using a single session.) If so, how should a client determine to what subscription a notification co= rresponds to? (Based on the contents?) I see that there is no identifier for a subscription (which may facilitate = this determination) exchanged between client and server. (There is an rpc m= essage-id, but that is used in the context of the rpc/rpc-reply and there i= s not reference to it in the notifications). I would be interested in learning the reason(s) for this. Thanks, Alberto --_000_D0E2F2921C8F5albertgociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <22CCFE16FDAD674B81E72E4FB21CEE19@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hello,

I have a question about RFC 5277 and I would appreciate help with it.<= /div>

In the context of a single session, are multiple concurrent subscripti= ons supported? 
(E.g, a single client, interested in two streams, requesting two <c= reate-subscription> (one per stream) using a single session.)

If so, how should a client determine to what subscription a notificati= on corresponds to? (Based on the contents?)
I see that there is no identifier for a subscription (which may facili= tate this determination) exchanged between client and server. (There is an = rpc message-id, but that is used in the context of the rpc/rpc-reply and th= ere is not reference to it in the notifications). 
I would be interested in learning the reason(s) for this.

Thanks,

Alberto
--_000_D0E2F2921C8F5albertgociscocom_-- From nobody Mon Jan 19 23:03:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE82A1AD065 for ; Mon, 19 Jan 2015 23:03: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 k76SikSH8dwx for ; Mon, 19 Jan 2015 23:03:21 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4576D1ACE1E for ; Mon, 19 Jan 2015 23:03:21 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 1C37F1280B28; Tue, 20 Jan 2015 08:03:17 +0100 (CET) Date: Tue, 20 Jan 2015 08:04:30 +0100 (CET) Message-Id: <20150120.080430.210447671103596575.mbj@tail-f.com> To: albertgo@cisco.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: netconf@ietf.org Subject: Re: [Netconf] Question about RFC 5277: multiple concurrent subscriptions in a session and subscription identifiers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 07:03:23 -0000 "Alberto Gonzalez Prieto (albertgo)" wrote: > Hello, > > I have a question about RFC 5277 and I would appreciate help with it. > > In the context of a single session, are multiple concurrent > subscriptions supported? Short answer: no, not supported. For details, see second paragraph in section 1.3 and 6.5 /martin From nobody Tue Jan 20 00:01:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18A31B2D8B for ; Tue, 20 Jan 2015 00:01:54 -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 nxmMaCCu9phF for ; Tue, 20 Jan 2015 00:01:54 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9541B2D8A for ; Tue, 20 Jan 2015 00:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=472; q=dns/txt; s=iport; t=1421740910; x=1422950510; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=X+kzhC51+LGVDPPTfY7/q5/AgpxuCS3TYfb6c1NddT4=; b=LW4r/NV90rFDOlPAdliBJbcvCq+gb0nFhtwajnrm976RTrBwWKnCovdS 2O2jCA8lQuspJgcWKpZqp5dwXkKs1lQ7HL29FOCDsbPcF11HT7HKBygZo ED7erA81q1QcewlxBA/prr/hW+lzxBzIbpWtbLnDfgbvOGMF58jBn8RKM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFANIKvlStJV2Q/2dsb2JhbABbgwaBKgTEC4gWAoEfQwEBAQEBfYQNAQEEOj8SAQgOCg0RBT0lAgQOBYgsziQBAQEBAQEBAQEBAQEBAQEBAQEajEmDMAeEKQEEjlmJF5IqIoIPI4E8b4FFfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,432,1418083200"; d="scan'208";a="388570440" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jan 2015 08:01:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0K81m6r006530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Jan 2015 08:01:49 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.163]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 20 Jan 2015 02:01:48 -0600 From: "Alberto Gonzalez Prieto (albertgo)" To: Martin Bjorklund Thread-Topic: [Netconf] Question about RFC 5277: multiple concurrent subscriptions in a session and subscription identifiers Thread-Index: AQHQNFJiqg1FR/sg8ESVHOKYPbU4jJzI+pwA//+J54A= Date: Tue, 20 Jan 2015 08:01:47 +0000 Message-ID: In-Reply-To: <20150120.080430.210447671103596575.mbj@tail-f.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.236.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Question about RFC 5277: multiple concurrent subscriptions in a session and subscription identifiers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 08:01:55 -0000 Thanks Martin, Alberto On 1/19/15, 11:04 PM, "Martin Bjorklund" wrote: >"Alberto Gonzalez Prieto (albertgo)" wrote: >> Hello, >>=20 >> I have a question about RFC 5277 and I would appreciate help with it. >>=20 >> In the context of a single session, are multiple concurrent >> subscriptions supported? > >Short answer: no, not supported. > >For details, see second paragraph in section 1.3 and 6.5 > > >/martin From nobody Tue Jan 20 01:51:42 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E1F1AD2EE for ; Tue, 20 Jan 2015 01:51:41 -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 kyVOsxQS2In9 for ; Tue, 20 Jan 2015 01:51:39 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6479F1AD353 for ; Tue, 20 Jan 2015 01:51:38 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2A39F1CC0604; Tue, 20 Jan 2015 10:51:37 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , kwatsen@juniper.net In-Reply-To: <20150119.215423.792155738142290669.mbj@tail-f.com> References: <20150119.215423.792155738142290669.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: Tue, 20 Jan 2015 10:51:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netconf@ietf.org, jshoenwaelder@jacobs-university.de Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 09:51:42 -0000 Martin Bjorklund writes: > Kent Watsen wrote: >> >Page 14, Section 3.2, ietf-netconf-server.yang, nit >> >--------------------------------------------------- >> > >> > grouping session-options-container { >> > description >> > ""; >> > container session-options { >> > >> >I suggest removing the empty description. I think the reason/purpose of >> >the grouping is obvious enough that a description clause does not assist >> >the reader's understanding. >> > >> >Many of the grouping statements in the ietf-netconf-server.yang module >> >and the ietf-restconf-server.yang module have empty descriptions. This >> >same comment applies to them also. >> >> The empty descriptions are an annoying artifact of the `pyang --ietf` >> option requiring descriptions on these nodes. But I agree that no >> description is needed and that it looks odd as is. I could copy/paste the >> entire description or has one reference the other...hmm, how about this - >> look for "(see above)" below: > > pyang --ietf implements the rules defined in RFC 6087. I think enforcing descriptions via 2119 keywords is inappropriate and, as in this case, counter-productive. It should be left to the module author's judgement where to place descriptions. Some kind of general advice and explanation why descriptions are useful would IMO be more helpful. It is often the case that a grouping contains just a single data node, and then it mostly doesn't make sense to have a description on the grouping and then on the data node again. > > If you really don't have anything to say, remove the statement and > ignore the error - we do not want unnecessary noise in our modules! But we also don't want unnecessary noise in stderr - it's not only annoying but also useful warnings then can get lost. Lada > > This said, I think that these groupings really should have a proper > description. Or rather, I'd prefer to not define the groupings at > all, but rather inline their definitions. But if you do think that > these groupings are reusable, the description should explain what they > are. > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 20 02:06:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5437A1AD2EC for ; Tue, 20 Jan 2015 02:06:50 -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 mYIxiQ52KdKA for ; Tue, 20 Jan 2015 02:06: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 B501D1AD09C for ; Tue, 20 Jan 2015 02:06: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 78A1E72F; Tue, 20 Jan 2015 11:06: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 sGceXM4YGmQy; Tue, 20 Jan 2015 11:06: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; Tue, 20 Jan 2015 11:06:46 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7CE320035; Tue, 20 Jan 2015 11:06:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L_C38v_muCOA; Tue, 20 Jan 2015 11:06:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D355F20034; Tue, 20 Jan 2015 11:06:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7DC3130DDBD2; Tue, 20 Jan 2015 11:06:43 +0100 (CET) Date: Tue, 20 Jan 2015 11:06:42 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150120100641.GA29606@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , kwatsen@juniper.net, netconf@ietf.org, jshoenwaelder@jacobs-university.de References: <20150119.215423.792155738142290669.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: netconf@ietf.org, jshoenwaelder@jacobs-university.de Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 10:06:50 -0000 On Tue, Jan 20, 2015 at 10:51:38AM +0100, Ladislav Lhotka wrote: > > I think enforcing descriptions via 2119 keywords is inappropriate and, > as in this case, counter-productive. It should be left to the module > author's judgement where to place descriptions. Some kind of general > advice and explanation why descriptions are useful would IMO be more > helpful. > > It is often the case that a grouping contains just a single data node, > and then it mostly doesn't make sense to have a description on the > grouping and then on the data node again. > SMIv2 mandated descriptions and while sometimes one could have done without, I believe the fact that they were simply required was overall a big win and helped to avoid endless debates. In this particular case, the description of the grouping should explain what the grouping is good for and when to use it and the description of the container should describe what the container is good for. The container and its description is there after expansion of the grouping, the description of the grouping goes away with the expansion. In other words, I like to get a description of the container that says what the container does without having to worry whether the container was coming from a grouping or not. So I think both descriptions do actually serve different purposes and both make sense to have. /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 Jan 20 02:28:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A941AD370 for ; Tue, 20 Jan 2015 02:28:07 -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 P9Yua3DW4XJE for ; Tue, 20 Jan 2015 02:28:06 -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 4091A1AD36B for ; Tue, 20 Jan 2015 02:28:06 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 3DA05140C9C; Tue, 20 Jan 2015 11:28:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421749684; bh=3ik0rzM4tEcz9axiIl6dHfiwtwa5d8Qc95t4gM4wLOs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Bibr8/J6h5h20lDVZ4s/YelyVVkAslW7q4E8acWxZcvF7f/3RZs1HWJ+f4eiPnKzQ ykV8+pgklixvdTiC2SU8Oa3jmGCmgh6f8RllZyNx7pEyT625Tnojpho/Icme1VpCWN eTHsJwbudyKs3dkRiN+qSTsuSTUw3cw+jiLuoK9E= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150120100641.GA29606@elstar.local> Date: Tue, 20 Jan 2015 11:28:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150119.215423.792155738142290669.mbj@tail-f.com> <20150120100641.GA29606@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 10:28:08 -0000 > On 20 Jan 2015, at 11:06, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 20, 2015 at 10:51:38AM +0100, Ladislav Lhotka wrote: >>=20 >> I think enforcing descriptions via 2119 keywords is inappropriate = and, >> as in this case, counter-productive. It should be left to the module >> author's judgement where to place descriptions. Some kind of general >> advice and explanation why descriptions are useful would IMO be more >> helpful. >>=20 >> It is often the case that a grouping contains just a single data = node, >> and then it mostly doesn't make sense to have a description on the >> grouping and then on the data node again. >>=20 >=20 > SMIv2 mandated descriptions and while sometimes one could have done > without, I believe the fact that they were simply required was overall > a big win and helped to avoid endless debates. In this particular > case, the description of the grouping should explain what the grouping > is good for and when to use it and the description of the container > should describe what the container is good for. The container and its > description is there after expansion of the grouping, the description > of the grouping goes away with the expansion. In other words, I like > to get a description of the container that says what the container > does without having to worry whether the container was coming from a > grouping or not. So I think both descriptions do actually serve > different purposes and both make sense to have. OK, so let=E2=80=99s take RFC 7407 as an example, of which you are an = co-author: out of eight groupings defined in its modules, only *one* has = a description. This violates a MUST in RFC 6087. 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 Tue Jan 20 02:56:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A681AD377 for ; Tue, 20 Jan 2015 02:56:51 -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 0FahvHZvbKgK for ; Tue, 20 Jan 2015 02:56: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 6871D1AD376 for ; Tue, 20 Jan 2015 02:56: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 372D693D; Tue, 20 Jan 2015 11:56: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 i7PXwOvi-3ms; Tue, 20 Jan 2015 11:56: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, 20 Jan 2015 11:56:46 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5476820034; Tue, 20 Jan 2015 11:56:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VAVDWJ72LK5y; Tue, 20 Jan 2015 11:56:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCD632002F; Tue, 20 Jan 2015 11:56:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9E88C30DDCA4; Tue, 20 Jan 2015 11:56:44 +0100 (CET) Date: Tue, 20 Jan 2015 11:56:44 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150120105644.GA29731@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , Kent Watsen , Netconf References: <20150119.215423.792155738142290669.mbj@tail-f.com> <20150120100641.GA29606@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: Netconf Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 10:56:51 -0000 On Tue, Jan 20, 2015 at 11:28:03AM +0100, Ladislav Lhotka wrote: > > > On 20 Jan 2015, at 11:06, Juergen Schoenwaelder wrote: > > > > On Tue, Jan 20, 2015 at 10:51:38AM +0100, Ladislav Lhotka wrote: > >> > >> I think enforcing descriptions via 2119 keywords is inappropriate and, > >> as in this case, counter-productive. It should be left to the module > >> author's judgement where to place descriptions. Some kind of general > >> advice and explanation why descriptions are useful would IMO be more > >> helpful. > >> > >> It is often the case that a grouping contains just a single data node, > >> and then it mostly doesn't make sense to have a description on the > >> grouping and then on the data node again. > >> > > > > SMIv2 mandated descriptions and while sometimes one could have done > > without, I believe the fact that they were simply required was overall > > a big win and helped to avoid endless debates. In this particular > > case, the description of the grouping should explain what the grouping > > is good for and when to use it and the description of the container > > should describe what the container is good for. The container and its > > description is there after expansion of the grouping, the description > > of the grouping goes away with the expansion. In other words, I like > > to get a description of the container that says what the container > > does without having to worry whether the container was coming from a > > grouping or not. So I think both descriptions do actually serve > > different purposes and both make sense to have. > > OK, so let’s take RFC 7407 as an example, of which you are an co-author: out of eight groupings defined in its modules, only *one* has a description. This violates a MUST in RFC 6087. > This is why reviews are important. /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 Jan 20 03:32:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD01B29D9 for ; Tue, 20 Jan 2015 03:32:50 -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 o6UlMxojVFE0 for ; Tue, 20 Jan 2015 03:32:49 -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 EC71B1B29D1 for ; Tue, 20 Jan 2015 03:32:48 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4d8a:e817:b819:479e] (unknown [IPv6:2001:718:1a02:1:4d8a:e817:b819:479e]) by mail.nic.cz (Postfix) with ESMTPSA id A081013F862; Tue, 20 Jan 2015 12:32:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421753567; bh=MgFPWG3mHRc9ch/PKb9Tw86SKplGBtvhKtHa9VBDkjs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iAo9jq+YAgPbMZZD/zoVWaqr+5LqpMBsjbUf17kuUnHOKd6uwx0gD85xPylQIhWnV ioglr6M4UxaPLRrtgdGZELv4F/UEfm7v6BUtdwqyLgf3vSskkrU15oHSt/c+uhbhdd jV7Hj24jsraMXUoZVlk39l/zdj3TFFynXci9mfEQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: <20150120105644.GA29731@elstar.local> Date: Tue, 20 Jan 2015 12:32:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150119.215423.792155738142290669.mbj@tail-f.com> <20150120100641.GA29606@elstar.local> <20150120105644.GA29731@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 11:32:51 -0000 > On 20 Jan 2015, at 11:56, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 20, 2015 at 11:28:03AM +0100, Ladislav Lhotka wrote: >>=20 >>> On 20 Jan 2015, at 11:06, Juergen Schoenwaelder = wrote: >>>=20 >>> On Tue, Jan 20, 2015 at 10:51:38AM +0100, Ladislav Lhotka wrote: >>>>=20 >>>> I think enforcing descriptions via 2119 keywords is inappropriate = and, >>>> as in this case, counter-productive. It should be left to the = module >>>> author's judgement where to place descriptions. Some kind of = general >>>> advice and explanation why descriptions are useful would IMO be = more >>>> helpful. >>>>=20 >>>> It is often the case that a grouping contains just a single data = node, >>>> and then it mostly doesn't make sense to have a description on the >>>> grouping and then on the data node again. >>>>=20 >>>=20 >>> SMIv2 mandated descriptions and while sometimes one could have done >>> without, I believe the fact that they were simply required was = overall >>> a big win and helped to avoid endless debates. In this particular >>> case, the description of the grouping should explain what the = grouping >>> is good for and when to use it and the description of the container >>> should describe what the container is good for. The container and = its >>> description is there after expansion of the grouping, the = description >>> of the grouping goes away with the expansion. In other words, I like >>> to get a description of the container that says what the container >>> does without having to worry whether the container was coming from a >>> grouping or not. So I think both descriptions do actually serve >>> different purposes and both make sense to have. >>=20 >> OK, so let=E2=80=99s take RFC 7407 as an example, of which you are an = co-author: out of eight groupings defined in its modules, only *one* has = a description. This violates a MUST in RFC 6087. >>=20 >=20 > This is why reviews are important. Actually, ietf-routing is 6087-compliant, which leads to embarrassing = definitions like this: grouping address-family { description "This grouping provides a leaf identifying an address family."; leaf address-family { type identityref { base address-family; } mandatory "true"; description "Address family."; } } 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 Tue Jan 20 04:51:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D391B2A41 for ; Tue, 20 Jan 2015 04:51: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 ET73c9xdL0wh for ; Tue, 20 Jan 2015 04:51: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 0B9531B2A40 for ; Tue, 20 Jan 2015 04:51:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D2C451009; Tue, 20 Jan 2015 13:51:00 +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 xCogY_4qkCjp; Tue, 20 Jan 2015 13:50:51 +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, 20 Jan 2015 13:50:59 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C49F520036; Tue, 20 Jan 2015 13:50:59 +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 aXrwdAldMR4l; Tue, 20 Jan 2015 13:50:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D83A22002F; Tue, 20 Jan 2015 13:50:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8C04C30DE27A; Tue, 20 Jan 2015 13:50:57 +0100 (CET) Date: Tue, 20 Jan 2015 13:50:56 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20150120125055.GA30079@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , Kent Watsen , Netconf References: <20150119.215423.792155738142290669.mbj@tail-f.com> <20150120100641.GA29606@elstar.local> <20150120105644.GA29731@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: Netconf Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 12:51:07 -0000 On Tue, Jan 20, 2015 at 12:32:47PM +0100, Ladislav Lhotka wrote: > > > On 20 Jan 2015, at 11:56, Juergen Schoenwaelder wrote: > > > > On Tue, Jan 20, 2015 at 11:28:03AM +0100, Ladislav Lhotka wrote: > >> > >>> On 20 Jan 2015, at 11:06, Juergen Schoenwaelder wrote: > >>> > >>> On Tue, Jan 20, 2015 at 10:51:38AM +0100, Ladislav Lhotka wrote: > >>>> > >>>> I think enforcing descriptions via 2119 keywords is inappropriate and, > >>>> as in this case, counter-productive. It should be left to the module > >>>> author's judgement where to place descriptions. Some kind of general > >>>> advice and explanation why descriptions are useful would IMO be more > >>>> helpful. > >>>> > >>>> It is often the case that a grouping contains just a single data node, > >>>> and then it mostly doesn't make sense to have a description on the > >>>> grouping and then on the data node again. > >>>> > >>> > >>> SMIv2 mandated descriptions and while sometimes one could have done > >>> without, I believe the fact that they were simply required was overall > >>> a big win and helped to avoid endless debates. In this particular > >>> case, the description of the grouping should explain what the grouping > >>> is good for and when to use it and the description of the container > >>> should describe what the container is good for. The container and its > >>> description is there after expansion of the grouping, the description > >>> of the grouping goes away with the expansion. In other words, I like > >>> to get a description of the container that says what the container > >>> does without having to worry whether the container was coming from a > >>> grouping or not. So I think both descriptions do actually serve > >>> different purposes and both make sense to have. > >> > >> OK, so let’s take RFC 7407 as an example, of which you are an co-author: out of eight groupings defined in its modules, only *one* has a description. This violates a MUST in RFC 6087. > >> > > > > This is why reviews are important. > > Actually, ietf-routing is 6087-compliant, which leads to embarrassing definitions like this: > > grouping address-family { > description > "This grouping provides a leaf identifying an address > family."; > leaf address-family { > type identityref { > base address-family; > } > mandatory "true"; > description > "Address family."; > } > } > > Lada > The value of groupings with one leaf can be debated. But whatever example you will post here, it won't change my general position that it is better to require descriptions than relying on authors to provide them when really needed (because then you will then have to convince authors to write descriptions they do not want to write because for them everything is of course obvious). A shortcoming of groupings is that descriptions are kind of forced to be generic and the more semantically meaningful descriptions are then lacking. Perhaps I could compromise if a definition in a grouping without a description MUST have a description added in a refine statement of the uses statement, that is if there is uses address-family { refine address-family { description "The address family related to ABV and used to do XYZ."; } } Anyway, this is NETCONF writing a YANG 1.0 model using existing RFCs so this is off topic I think. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jan 20 07:39:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1481F1B2A66 for ; Mon, 19 Jan 2015 05:10:53 -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 2-twq90hXKkO for ; Mon, 19 Jan 2015 05:10:51 -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 69CD71B2A62 for ; Mon, 19 Jan 2015 05:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1844; q=dns/txt; s=iport; t=1421673053; x=1422882653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tdAh6xyN5p3MUGFIlNQxG+z1lXHKkL/3YeQitBCf6qQ=; b=IImrpfolXKjL0YUzukjQcHrLxSmOLC6DA8V7ZCxXZ3RnsvLAwmEFBMST t+PSC9vgH5z2l5XqYdji+EoXt+QHxlW9nEgoz/yiZLnnAA6qZMb/vBavy 1qMFdIaeJAK+/RC668BzPf7rL4jjodfQS5WCp8WbBm0yV532+Q8qyUsiL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYFALsBvVStJA2E/2dsb2JhbABbgwaBLoMCwRCIFgIcgQdDAQEBAQF9hAwBAQEEIxFFDAQCAQgOAwQBAQECAgYdAwICAjAUAQgIAQEEDgUIiCS6SpN1AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhjicxBwaCYi6BEwEEjlmbQSKDbm+BRX4BAQE X-IronPort-AV: E=Sophos;i="5.09,426,1418083200"; d="scan'208";a="114570807" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 19 Jan 2015 13:10:52 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t0JDAogR026550 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Jan 2015 13:10:50 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 19 Jan 2015 07:10:50 -0600 From: "Julius Milan -X (jumilan - Pantheon Technologies SRO at Cisco)" To: Martin Bjorklund Thread-Topic: [Netconf] message-id attribute value normalization Thread-Index: AdAxtS/196KFVEGPQJGaq2NUav0z1QAQ1GqAAHN/SxAAFRpOAAAMat7g Date: Mon, 19 Jan 2015 13:10:49 +0000 Message-ID: References: <20150119.140536.1899748863425317662.mbj@tail-f.com> In-Reply-To: <20150119.140536.1899748863425317662.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.107.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 20 Jan 2015 07:39:38 -0800 Cc: "Rastislav Szabo -X \(raszabo - Pantheon Technologies SRO at Cisco\)" , "Stefan Kobza -X \(skobza - Pantheon Technologies SRO at Cisco\)" , "Anna Medvedova -X \(amedvedo - Pantheon Technologies SRO at Cisco\)" , "netconf@ietf.org" Subject: Re: [Netconf] message-id attribute value normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 13:10:53 -0000 T2ssIHRoYW5rcyBhIGxvdC4NCg0KSnVsaXVzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86bWJqQHRhaWwtZi5jb21dIA0KU2VudDog TW9uZGF5LCBKYW51YXJ5IDE5LCAyMDE1IDI6MDYgUE0NClRvOiBKdWxpdXMgTWlsYW4gLVggKGp1 bWlsYW4gLSBQYW50aGVvbiBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKQ0KQ2M6IGFuZHlAeXVt YXdvcmtzLmNvbTsgUmFzdGlzbGF2IFN6YWJvIC1YIChyYXN6YWJvIC0gUGFudGhlb24gVGVjaG5v bG9naWVzIFNSTyBhdCBDaXNjbyk7IFN0ZWZhbiBLb2J6YSAtWCAoc2tvYnphIC0gUGFudGhlb24g VGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbyk7IG5ldGNvbmZAaWV0Zi5vcmc7IEFubmEgTWVkdmVk b3ZhIC1YIChhbWVkdmVkbyAtIFBhbnRoZW9uIFRlY2hub2xvZ2llcyBTUk8gYXQgQ2lzY28pDQpT dWJqZWN0OiBSZTogW05ldGNvbmZdIG1lc3NhZ2UtaWQgYXR0cmlidXRlIHZhbHVlIG5vcm1hbGl6 YXRpb24NCg0KIkp1bGl1cyBNaWxhbiAtWCAoanVtaWxhbiAtIFBhbnRoZW9uIFRlY2hub2xvZ2ll cyBTUk8gYXQgQ2lzY28pIiA8anVtaWxhbkBjaXNjby5jb20+IHdyb3RlOg0KPiBPaywNCj4gQnV0 IHN0aWxsIHJlbWFpbnMgZm9sbG93aW5nIGluY29uc2lzdGVuY3ksIHdoaWNoIGNvdWxkIGxpdHRs ZSBiaXQgDQo+IGNvbmZ1c2UgbmV0Y29uZiB1c2VyIG9yIGRldmVsb3BlcjoNCj4gDQo+IDEuKSDi gJxUaGUgc2VuZGVyIE1VU1QgZW5zdXJlIHRoYXQgdGhlICJtZXNzYWdlLWlkIiB2YWx1ZSBpcyBu b3JtYWxpemVkIA0KPiBhY2NvcmRpbmcgdG8g4oCmIGlmIHRoZSBzZW5kZXIgd2FudHMgdGhlIHN0 cmluZyB0byBiZSByZXR1cm5lZCANCj4gdW5tb2RpZmllZC7igJ0NCj4gDQo+IDIuKSBBbmQgdGhl IGZhY3QgdGhhdCBtZXNzYWdlLWlkIHNob3VsZCBub3QgYmUgbm9ybWFsaXplZCBhY2NvcmRpbmcg dG8gDQo+IHNjaGVtYSAobmV0Y29uZi54c2QpLg0KPiANCj4gSXQncyBqdXN0IGEgZGV0YWlsLCBi dXQgdGhlc2UgMiBmYWN0cyBhcmUgaW4gY29uZmxpY3QuDQoNCkkgZG9uJ3QgdGhpbmsgdGhlcmUn cyBhIGNvbmZsaWN0Lg0KDQpSZWdhcmRsZXNzIG9mIHRoZSBYU0QsIGFuIFhNTCBhdHRyaWJ1dGUg aXMgbm9ybWFsaXplZCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIG9mIFhNTC4NCg0KVGhlIHRleHQg YmFzaWNhbGx5IHNheXMgdGhhdCB0aGUgc2VuZGVyIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzLCB3 aGVuIGNyZWF0aW5nIHRoZSBtZXNzYWdlLWlkIHN0cmluZy4NCg0KTm8gWFNEIG5vcm1hbGl6YXRp b24gaXMgaW52b2x2ZWQgaGVyZS4NCg0KDQovbWFydGluDQo= From nobody Tue Jan 20 08:08:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF75C1B2A72 for ; Tue, 20 Jan 2015 08:08:37 -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 cdK77UcNYWPM for ; Tue, 20 Jan 2015 08:08:34 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793621B2AA6 for ; Tue, 20 Jan 2015 08:08:34 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so35146928lab.13 for ; Tue, 20 Jan 2015 08:08: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 :content-transfer-encoding; bh=mQ3v8HfCGiqk80irQLYsKOxqz6VE1wIWvnm52WJO96k=; b=AZZ1KJKw7Zt/60ymPkFn6g8tqOFDDVxLI5FKjy6DKGM+PHLDbFH5WbobkbKivovL1U MTsj5kSRPucLw7blsk9Unhs/ZoU+FATgNXsM0ZpJugGwmTczXFKI1sVpoCx7aXGwrPDC 23vo9VwsNhNASj8BX8h/KyaGHV+9YR5o2P9GGJQZSpNYKUvEEnbuLMe0md7dS0xYbozY J9odeyDHwRqe89c+LYyMJ728Z4jPbNTs1eGhj4vJa0yuh2DjKDCK0XoUTQwy5nPvVzeV 2F/QBWrx8pQFKnNB7hkTvmw2hIcB+H0lGR8fhXEqVtMqhjL5BQp/4/I7YDu+PiIv4SAV I+NA== X-Gm-Message-State: ALoCoQk8MHpmJKblZI+fTZlFfnYmwjSJfPKqP5yeK40ABDbAvXIJp3DmVgTOPtzMZyDidQ3ZuQLf MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr39862525laf.82.1421770112711; Tue, 20 Jan 2015 08:08:32 -0800 (PST) Received: by 10.112.160.41 with HTTP; Tue, 20 Jan 2015 08:08:32 -0800 (PST) In-Reply-To: References: <20150119.215423.792155738142290669.mbj@tail-f.com> <20150120100641.GA29606@elstar.local> <20150120105644.GA29731@elstar.local> Date: Tue, 20 Jan 2015 08:08:32 -0800 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Netconf Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 16:08:38 -0000 On Tue, Jan 20, 2015 at 3:32 AM, Ladislav Lhotka wrote: > >> On 20 Jan 2015, at 11:56, Juergen Schoenwaelder wrote: >> >> On Tue, Jan 20, 2015 at 11:28:03AM +0100, Ladislav Lhotka wrote: >>> >>>> On 20 Jan 2015, at 11:06, Juergen Schoenwaelder wrote: >>>> >>>> On Tue, Jan 20, 2015 at 10:51:38AM +0100, Ladislav Lhotka wrote: >>>>> >>>>> I think enforcing descriptions via 2119 keywords is inappropriate and= , >>>>> as in this case, counter-productive. It should be left to the module >>>>> author's judgement where to place descriptions. Some kind of general >>>>> advice and explanation why descriptions are useful would IMO be more >>>>> helpful. >>>>> >>>>> It is often the case that a grouping contains just a single data node= , >>>>> and then it mostly doesn't make sense to have a description on the >>>>> grouping and then on the data node again. >>>>> >>>> >>>> SMIv2 mandated descriptions and while sometimes one could have done >>>> without, I believe the fact that they were simply required was overall >>>> a big win and helped to avoid endless debates. In this particular >>>> case, the description of the grouping should explain what the grouping >>>> is good for and when to use it and the description of the container >>>> should describe what the container is good for. The container and its >>>> description is there after expansion of the grouping, the description >>>> of the grouping goes away with the expansion. In other words, I like >>>> to get a description of the container that says what the container >>>> does without having to worry whether the container was coming from a >>>> grouping or not. So I think both descriptions do actually serve >>>> different purposes and both make sense to have. >>> >>> OK, so let=E2=80=99s take RFC 7407 as an example, of which you are an c= o-author: out of eight groupings defined in its modules, only *one* has a d= escription. This violates a MUST in RFC 6087. >>> >> >> This is why reviews are important. > > Actually, ietf-routing is 6087-compliant, which leads to embarrassing def= initions like this: > > grouping address-family { > description > "This grouping provides a leaf identifying an address > family."; > leaf address-family { > type identityref { > base address-family; > } > mandatory "true"; > description > "Address family."; > } > } > This is a poor example of a description-stmt. Consider the possibility that tools can extract the descriptions and display them to users in a context-specific manner. They may not be read from a YANG file. Consider the possibility that the term "address family" is generic and not that helpful. IMO either a description-stmt or reference-stmt MUST be present in published YANG modules. > Lada > Andy >> >> /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 > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jan 20 08:46:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87C41B2AB9 for ; Tue, 20 Jan 2015 08:46:41 -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 nBOMK3BaJTmL for ; Tue, 20 Jan 2015 08:46:40 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E581B2A9A for ; Tue, 20 Jan 2015 08:46:39 -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.59.20; Tue, 20 Jan 2015 16:46:37 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.114]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.114]) with mapi id 15.01.0059.007; Tue, 20 Jan 2015 16:46:37 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Ladislav Lhotka" Thread-Topic: [Netconf] draft-ietf-netconf-server-model-05 Thread-Index: AQHQMfiDOOWWRch7+EWij4CRQEiXKpzH8EOAgADZKgCAAAQ1AIAAG+cA Date: Tue, 20 Jan 2015 16:46:37 +0000 Message-ID: References: <20150119.215423.792155738142290669.mbj@tail-f.com> <20150120100641.GA29606@elstar.local> In-Reply-To: <20150120100641.GA29606@elstar.local> 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.241.12] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(43784003)(189002)(199003)(24454002)(479174004)(377454003)(106116001)(76176999)(54356999)(50986999)(36756003)(106356001)(99286002)(230783001)(102836002)(77156002)(68736005)(105586002)(2950100001)(66066001)(93886004)(101416001)(2900100001)(87936001)(64706001)(46102003)(2656002)(97736003)(83506001)(86362001)(62966003)(122556002)(40100003)(92566002)(19580395003)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 20 Jan 2015 16:46:37.1863 (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: Netconf , "jshoenwaelder@jacobs-university.de" Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 16:46:42 -0000 On 1/20/15, 5:06 AM, "Juergen Schoenwaelder" wrote: >In this particular >case, the description of the grouping should explain what the grouping >is good for and when to use it and the description of the container >should describe what the container is good for. The container and its >description is there after expansion of the grouping, the description >of the grouping goes away with the expansion. In other words, I like >to get a description of the container that says what the container >does without having to worry whether the container was coming from a >grouping or not. So I think both descriptions do actually serve >different purposes and both make sense to have. Thank you Juergen - this makes good sense to me. I'll revise the description statements in the server-model accordingly. Thanks again, Kent From nobody Tue Jan 20 08:53:44 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39531B2ACB for ; Tue, 20 Jan 2015 08:53:42 -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 DB6tzt032mwx for ; Tue, 20 Jan 2015 08:53: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 EAB1E1B2AB9 for ; Tue, 20 Jan 2015 08:53:36 -0800 (PST) Received: from [195.113.220.110] (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 746B913F862; Tue, 20 Jan 2015 17:53:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1421772814; bh=7llykoIz1jx3tDsJYlGIsjly3/ehIXf2RrwL90BV3kY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=WUih7b1yVHro/RYZWXTqxPRvFq8lsp4tLARcmXuV4VMMgf1QiwLCyStgcR5oPRghq Nl10Vcs73uXbIUov6h0dDPMbhdCbv/39//txsxaqDGEznhbeG2FySIxwaN7y0d7Pfs ACRa7CBAyJBtR55D6W+kYLLkNVimya2PpjNo2ybU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 20 Jan 2015 17:53:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58B11696-3036-4E1E-B197-7DD3E38079EB@nic.cz> References: <20150119.215423.792155738142290669.mbj@tail-f.com> <20150120100641.GA29606@elstar.local> <20150120105644.GA29731@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1993) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 16:53:43 -0000 > On 20 Jan 2015, at 17:08, Andy Bierman wrote: >=20 > On Tue, Jan 20, 2015 at 3:32 AM, Ladislav Lhotka = wrote: >>=20 >>> On 20 Jan 2015, at 11:56, Juergen Schoenwaelder = wrote: >>>=20 >>> On Tue, Jan 20, 2015 at 11:28:03AM +0100, Ladislav Lhotka wrote: >>>>=20 >>>>> On 20 Jan 2015, at 11:06, Juergen Schoenwaelder = wrote: >>>>>=20 >>>>> On Tue, Jan 20, 2015 at 10:51:38AM +0100, Ladislav Lhotka wrote: >>>>>>=20 >>>>>> I think enforcing descriptions via 2119 keywords is inappropriate = and, >>>>>> as in this case, counter-productive. It should be left to the = module >>>>>> author's judgement where to place descriptions. Some kind of = general >>>>>> advice and explanation why descriptions are useful would IMO be = more >>>>>> helpful. >>>>>>=20 >>>>>> It is often the case that a grouping contains just a single data = node, >>>>>> and then it mostly doesn't make sense to have a description on = the >>>>>> grouping and then on the data node again. >>>>>>=20 >>>>>=20 >>>>> SMIv2 mandated descriptions and while sometimes one could have = done >>>>> without, I believe the fact that they were simply required was = overall >>>>> a big win and helped to avoid endless debates. In this particular >>>>> case, the description of the grouping should explain what the = grouping >>>>> is good for and when to use it and the description of the = container >>>>> should describe what the container is good for. The container and = its >>>>> description is there after expansion of the grouping, the = description >>>>> of the grouping goes away with the expansion. In other words, I = like >>>>> to get a description of the container that says what the container >>>>> does without having to worry whether the container was coming from = a >>>>> grouping or not. So I think both descriptions do actually serve >>>>> different purposes and both make sense to have. >>>>=20 >>>> OK, so let=E2=80=99s take RFC 7407 as an example, of which you are = an co-author: out of eight groupings defined in its modules, only *one* = has a description. This violates a MUST in RFC 6087. >>>>=20 >>>=20 >>> This is why reviews are important. >>=20 >> Actually, ietf-routing is 6087-compliant, which leads to embarrassing = definitions like this: >>=20 >> grouping address-family { >> description >> "This grouping provides a leaf identifying an address >> family."; >> leaf address-family { >> type identityref { >> base address-family; >> } >> mandatory "true"; >> description >> "Address family."; >> } >> } >>=20 >=20 > This is a poor example of a description-stmt. >=20 > Consider the possibility that tools can extract the descriptions > and display them to users in a context-specific manner. > They may not be read from a YANG file. >=20 > Consider the possibility that the term "address family" is > generic and not that helpful. That=E2=80=99s because the leaf is in a grouping, so it is in fact = generic - it is then used in different contexts. Actually it might make = more sense to add a description to each =E2=80=9Cuses=E2=80=9D = statement. For a human reader, repeating essentially the same information in = several places (grouping, data node, typedef) just adds clutter to the = module. Lada >=20 > IMO either a description-stmt or reference-stmt MUST be present > in published YANG modules. >=20 >=20 >=20 >> Lada >>=20 >=20 > Andy >=20 >=20 >>>=20 >>> /js >>>=20 >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 20 13:11:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFF41B2B6C for ; Tue, 20 Jan 2015 13:11:30 -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 B-aOzCZLx5Gw for ; Tue, 20 Jan 2015 13:11:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:762]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342491B2A0D for ; Tue, 20 Jan 2015 13:11:26 -0800 (PST) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB313.namprd05.prod.outlook.com (10.141.69.150) with Microsoft SMTP Server (TLS) id 15.1.59.20; Tue, 20 Jan 2015 21:11:03 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.59.20; Tue, 20 Jan 2015 21:11:01 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.114]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.114]) with mapi id 15.01.0059.007; Tue, 20 Jan 2015 21:11:01 +0000 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AQHQNPWXsmh1voQ5Sgudn5IwYOG+2Q== Date: Tue, 20 Jan 2015 21:11:00 +0000 Message-ID: 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.241.12] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:CO1PR05MB457; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(199003)(189002)(377454003)(53754006)(101416001)(19617315012)(107886001)(64706001)(86362001)(54356999)(19625215002)(66066001)(40100003)(97736003)(230783001)(106116001)(2501002)(106356001)(122556002)(105586002)(46102003)(99286002)(36756003)(16236675004)(19300405004)(92566002)(87936001)(2656002)(50986999)(83506001)(19580405001)(62966003)(102836002)(19580395003)(77156002)(15975445007)(2900100001)(68736005)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0E42A3A92519kwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2015 21:11:00.9479 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB313; X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 21:11:31 -0000 --_000_D0E42A3A92519kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In section 10 (IANA Considerations), should there be an RFC Editor instruct= ion to replace "XXXX" with the RFC number assigned to this draft? In section 12 (Contributor's Address) seems out of place to me. Apparently= this section was added in 2008, in draft-ietf-netconf-tls-05. This was b= efore my time here, but just looking at this doc, I don't understand why th= is section exists. Should this name be rolled into the Acknowledgements se= ction just before it? Is there a distinction between a contributor and t= hose being acknowledged? Otherwise, nothing else caught my eye. Thanks, Kent From: , "Mehmet (NSN - DE/Munich)" > Date: Sunday, January 18, 2015 at 11:04 AM To: "netconf@ietf.org" > Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Hi All, technically spoken, I support the publication of 5539bis draft. It is well-written and addresses the issues we discussed appropriately. There are two minor issues concerning outdated references. - there is a -08 version available for draft-ietf-uta-tls-bcp-07 - RFC4742 has been replaced by RFC6242 Cheers, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Sunday, January 18, 2015 4:51 PM To: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Dear NETCONF WG, we did not get any comments yet on rfc5539bis draft during the WGLC. Please review and provide your comments on the document and/or please indicate if you think the document is ready for publication. If we do not get any comments or support by the deadline (January 19, 2015 = EOB PT) the WGLC will be seen as unsuccessful. Regards, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Sunday, January 11, 2015 5:58 PM To: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 All, this is a friendly reminder on the WGLC we started on January 5th for draft= -ietf-netconf-rfc5539bis-07. Please review and send your comments to the WG mailing. If you have read the document but don't have any comments, please state whe= ther you support the publication. Thanks, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Monday, January 05, 2015 9:46 PM To: netconf@ietf.org Subject: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Dear NETCONF Members, we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. The document can be found at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 Please review and send your comments to the WG mailing list by January 19, = 2015 EOB PT. The document is planned to publish as a standard track document. As a minimum please state that you have read/reviewed and whether you suppo= rt the publication. Please indicate also if you plan to implement or have already implementatio= n experience with the rfc5539bis draft. Thank you. Mehmet and Mahesh --_000_D0E42A3A92519kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

In section 10 (IANA Considerations), should there be an RFC Editor instruct= ion to replace "XXXX" with the RFC number assigned to this draft?=

In section 12 (Contributor's Address) seems out of place to me.  Appar= ently this section was added in 2008, in draft-ietf-netconf-tls-05. &n= bsp; This was before my time here, but just looking at this doc, I don't un= derstand why this section exists.  Should this name be rolled into the Acknowledgements section just before it?   &n= bsp;Is there a distinction between a contributor and those being acknowledg= ed?

Otherwise, nothing else caught my eye.

Thanks,
Kent



From: <Ersue>, "Mehmet (= NSN - DE/Munich)" <mehmet.e= rsue@nsn.com>
Date: Sunday, January 18, 2015 at 1= 1:04 AM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] WG Last Call= for draft-ietf-netconf-rfc5539bis-07

= Hi All,

=  

= technically spoken, I support the publication of 5539bis dra= ft.

=  

= It is well-written and addresses the issues we discussed app= ropriately.

=  

= There are two minor issues concerning outdated references.

= - there is a -08 version available for draft-ietf-uta-tls-bc= p-07

= - RFC4742 has been replaced by RFC6242

=  

= Cheers,
Mehmet

=  

From:<= /span> Netconf [mailto:netconf-bounces@ietf.o= rg] On Behalf Of ext Ersue, Mehmet = (NSN - DE/Munich)
Sent: Sunday, January 18, 20= 15 4:51 PM
To: netconf@ietf.org
Subject: Re: [Netconf] WG La= st Call for draft-ietf-netconf-rfc5539bis-07

 

= Dear NETCONF WG,

=  

= we did not get any comments yet on rfc5539bis draft during t= he WGLC.

=  

Please review and provide your= comments on the document and/or

please indicate if you think t= he document is ready for publication.&= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; 

=  

= If we do not get any comments or support by the deadline (Ja= nuary 19, 2015 EOB PT) the WGLC will be seen as unsuccessful.

=  

= Regards,
Mehmet

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Ersue, Mehm= et (NSN - DE/Munich)
Sent: Sunday, January 11, 20= 15 5:58 PM
To: netconf@ietf.org
Subject: Re: [Netconf] WG La= st Call for draft-ietf-netconf-rfc5539bis-07

 

= All,

=  

= this is a friendly reminder on the WGLC we started on Januar= y 5th for draft-ietf-netconf-rfc5539bis-07.

=  

= Please review and send your comments to the WG mailing.

If you have read the document = but don’t have any comments, please state whether you support the publication.  

=  

= Thanks,
Mehmet

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Ersue, Mehm= et (NSN - DE/Munich)
Sent: Monday, January 05, 20= 15 9:46 PM
To: netconf@ietf.org
Subject: [Netconf] WG Last C= all for draft-ietf-netconf-rfc5539bis-07

 

= Dear NETCONF Members,<= o:p>

=  

= we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539= bis-07.

=  

= The document can be found at:

=     htt= p://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07<= font size=3D"1" face=3D"Verdana">

=  

= Please review and send your comments to the WG mailing list b= y January 19, 2015 EOB PT.<= span style=3D"font-size: 9pt; font-family: Verdana, sans-serif;">

=  

= The document is planned to publish as a standard track docume= nt.

= As a minimum please state that you have read/reviewed and whe= ther you support the publication.

=  

= Please indicate also if you plan to implement or have already= implementation experience with the rfc5539bis draft.

=  

= Thank you.<= /span>

= Mehmet and Mahesh=

 

 

--_000_D0E42A3A92519kwatsenjunipernet_-- From nobody Tue Jan 20 17:17:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FF01A00F6 for ; Tue, 20 Jan 2015 17:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eFUce4FzYMdh for ; Tue, 20 Jan 2015 17:17:48 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7938F1A00F5 for ; Tue, 20 Jan 2015 17:17:48 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.59.20; Wed, 21 Jan 2015 01:17:46 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.114]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.114]) with mapi id 15.01.0059.007; Wed, 21 Jan 2015 01:17:46 +0000 From: Kent Watsen To: Robert Wilton , "netconf@ietf.org" Thread-Topic: Mail regarding draft-ietf-netconf-restconf Thread-Index: AQHQMZOf3UFpSbYZFkeiqe6KQJQ1GZzCoUAAgABhPID//62MAIAEhLqAgAJEZoA= Date: Wed, 21 Jan 2015 01:17:46 +0000 Message-ID: References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> In-Reply-To: <54BCD10B.1070408@cisco.com> 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.241.12] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 04631F8F77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(54094003)(52314003)(52604005)(24454002)(51704005)(51914003)(199003)(164054003)(479174004)(189002)(377454003)(107886001)(106116001)(83506001)(76176999)(50986999)(93886004)(86362001)(99286002)(92566002)(106356001)(19580405001)(54356999)(19580395003)(105586002)(46102003)(62966003)(66066001)(77156002)(64706001)(122556002)(15975445007)(40100003)(102836002)(87936001)(2950100001)(2900100001)(68736005)(2501002)(2656002)(230783001)(101416001)(97736003)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 21 Jan 2015 01:17:46.0303 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 01:17:51 -0000 First off, for those wondering, I had sent Robert a pre-release version -04. Below I extracted just the "RW" comments from the file Robert attached: Thanks, Kent 1. RW: Check whether there are options to modify multiple resources. I don't understand this comment 2. RW: Is there a capability of bulking updates together? Yes, one could do a PUT or a PATCH on the top-level configuration node. 3. RW: "plain patch" is one patch type that is identified, what other ones are there, if any? The description of patch above (and where the PATCH operation is described implies that there will be more than one patch type.) See draft-ietf-netconf-yang-patch 4. RW: It might add clarity if "media type" was also defined. We could copy/paste the first paragraph from RFC7231, section 3.1.1.1: HTTP uses Internet media types [RFC2046] in the Content-Type and Accept header fields in order to provide open and extensible data typing and type negotiation. 5. RW: Is it worth clarifying that child resources included in an HTTP response could be a different datatype to media type identifier? Maybe. I believe the entire tree is application/yang.data, but the "collection" media-type (no longer in this draft) would've provided a secondary type (application/yang.collection) that would make you statement true... 6. RW: Unclear what the "play" operation is here. This is the server telling the client that it has an operation (i.e. RPC statement) called "play". That said, the client could've gotten it from the YANG module(s), so this whole section might be redundant... RW: The description of "3.3 API Resource" (below) implies that "data" is mandatory here, so I was wondering if it should have also been included in the response? Yes, the server MUST implement the {+restconf}/data resource, but in this example, the client is GET-ing {+restconf}/operations 7. RW: Perhaps clarify in some way here that the {+restconf}/data is the datastore resource. (But, it is explicitly described below, so it may be unnecessary.) Yes, something is off in this section. The previous sentence says "The datastore resource type is defined in Section 3.4," and it is, but I agree that all this could be made easier to read. 8. RW: The description below was slightly confusing as to whether it was refering to both datastore and data resources or just datastore. In particular, here it states that a server MUST maintain a last-modified timestamp for this resource, whereas this appears to be optional for data resources. The "this resource" regards the parent section, which is for {+restconf}/data (the top-level tree node), but there is no corresponding text for decedent nodes. I think a "SHOULD be supported for decedent resources" would fix it - yes? 9. RW: It is unclear to me what this Entity tag is meant to be? I had assumed that it would identify who last updated the resource so it was possible to determine if a resource had been updated between reading it and patching it, but then the comment that it has to be a new previously unused value, implies that each value has to be unique in somewhat and hence perhaps it is just a counter, or a session id? Entity tags are defined here: https://tools.ietf.org/html/rfc7232#section-2.3. Would adding "entity tag" to the Terminology section fix it? 10. RW: Perhaps indent list2 to make it clear that it is a child of list1? Yes, and add the missing closing bracket as well (fixed in my local copy) 11. RW: Will the client be able to know whether default values have been returned for the children nodes? Would it be better to force all defaults to be returned, otherwise the client may have to query for each and every node? No, the server's response MUST be in accordance with its reported default handling mode. That said, I think the text could say this a bit better... 12. RW: Is "204 No Content" only sent back on success? Presumably it could also return an error instead (e.g. not authorized, or perhaps some other error to indicate that the system cannot comply)? HTTP errors are indicated with 4xx and 5xx status codes (https://tools.ietf.org/html/rfc7231#section-6.5 and https://tools.ietf.org/html/rfc7231#section-6.6) 13. RW: What it mean by all media types here? Does this mean both JSON and XML or something else? It is trying to say that if GET, PUT, POST, or PATCH are supported, then they SHOULD be supported for both the +xml and +json variants of resource's media-type, per whatever the server supports (which apparently is undefined, except for restconf-state/streams) 12. RW: Presumably you are allowed to create a resource with child resources as well (e.g. to POST a full configuration)? Is that worth clarifying here?=20 Yes, it can be the full subtree. I suppose it could be stated more explicitly, though I'm not clear what other interpretation there can be... 13. RW: Perhaps indent the last line of the table by 2 spaces to make it more clear? ...or have a smaller URI - e.g., s/restconf-with-defaults/with-defaults/ ??? 14. RW: I wonder if implementations would rather choose to implement an easier syntax than full XPath, perhaps in future these is scope for a simple-filter. We plan more XPath 1.0 expressions for collections. It's suppose to be a simplified XPath 1.0 expression. 15: RW: I can understand how this works if XML data is being returned, but what is the equivalent on a XML attribute in JSON to tag a particular field as being default? Please see draft-lhotka-netmod-yang-metadata for how to encode attributes in JSON 16. RW: Where is it documented how multiple updates are possible with a single PATCH method? I've found it later - perhaps cross reference section 5.4 Please see draft-ietf-netconf-yang-patch 17. RW: Why is support for XML encoding mandatory? I thought that XML was quickly going out of fashion - shouldn't this be left to the implementation. This was an issue discussed by the WG (see https://github.com/netconf-wg/restconf/issues/7). Though the issue tracker didn't capture it, the very-narrow WG consensus was to have XML be mandatory to implement. Thanks, Kent On 1/19/15, 4:40 AM, "Robert Wilton" wrote: >[Adding netconf working group at Andy Bierman's request] > >Hi Kent, > >I've read though the attached draft (up to the point that the yang >modules were defined), and I've attached a draft with some inline >comments (marked with "RW:", 20 locations) where the intent of the text >wasn't completely clear to me. In some places I found that it was >clarified later in the doc, so may just need some forward references. > >Anyway, hopefully these are helpful and self explanatory, but let me >know if you need me to clarify any of my comments. > >Cheers, >Rob > > >On 16/01/2015 17:40, Kent Watsen wrote: >> No problem. >> >> Also, in case you are unaware, we're trying to put the final touches on >> the draft now in preparation for last-call. As it seems you are >>looking >> at it pretty carefully now, please report any other issues found. >> >> BTW, -03 is a bit outdated. The current, but not yet released, draft is >> attached. >> >> Cheers, >> Kent >> >> >> >> On 1/16/15, 12:35 PM, "Robert Wilton" wrote: >> >>> Thanks for the quick confirmation. >>> >>> Rob >>> >>> On 16/01/2015 16:47, Kent Watsen wrote: >>>> Yes, this appears to be a typo - the "genre" line should've been >>>> omitted. >>>> >>>> Thanks for reporting it! >>>> >>>> Kent >>>> >>>> >>>> >>>> On 1/16/15, 8:51 AM, "Robert Wilton" wrote: >>>> >>>>> Hi, >>>>> >>>>> I was just skimming over draft-ietf-netconf-restconf-03, for the >>>>> description of "3.6. PATCH" on page 29, and the example was slightly >>>>> confusing in that the description talks about just replacing the >>>>>"year" >>>>> field but the JSON patch includes both "genre" and "year". >>>>> >>>>> Is this just a typo? >>>>> >>>>> Thanks, >>>>> Rob >>>>> > > From nobody Wed Jan 21 07:49:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E701A1AE2 for ; Wed, 21 Jan 2015 07:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, 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 N986q2F6SeQf for ; Wed, 21 Jan 2015 07:49:10 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544871A1AE6 for ; Wed, 21 Jan 2015 07:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12057; q=dns/txt; s=iport; t=1421855351; x=1423064951; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=glWd7CMRMfbII8VXSMqe6UrKQEHTCwKg0cvwVw88Uls=; b=itTBYOTZe4mj/Bz0V/f9AGyDWWUjfj3enJcX+fwtBDAM2j6cR9k4yYnH 7TNM0SUqlGarBBV6ARHxxIf+mPy8s7UWAxEhXVwQb3/O6ONe6n6bVgEs2 1XXYrMWIy8WvLvmJ7mS1bI1GMpCAhqr9Fs/KwCmIuJrGZSsCDte1PXGGK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEANHJv1StJssW/2dsb2JhbABRCoNYWMYchXECgWgBAQEBAX2EDAEBAQMBOEARCw4KCRYPCQMCAQIBRQYBDAYCAQGIIAgN0nABAQEBAQEBAQEBAQEBAQEBAQEBARQEjx0LAQFWhCkBBJIgggiDSIEUgnyCHyGFLIYuIoNuPjEBgQuBNwEBAQ X-IronPort-AV: E=Sophos;i="5.09,442,1418083200"; d="scan'208";a="320602660" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 21 Jan 2015 15:49:07 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t0LFn5be004984; Wed, 21 Jan 2015 15:49:05 GMT Message-ID: <54BFCA70.3060909@cisco.com> Date: Wed, 21 Jan 2015 15:49:04 +0000 From: Robert Wilton 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 , "netconf@ietf.org" References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 15:49:33 -0000 Hi Kent, Please see some more comments inline ... On 21/01/2015 01:17, Kent Watsen wrote: > First off, for those wondering, I had sent Robert a pre-release version > -04. > > Below I extracted just the "RW" comments from the file Robert attached: > > Thanks, > Kent > > > > 1. RW: Check whether there are options to modify multiple resources. > > I don't understand this comment Please ignore this comment, it was a reminder to me to check. > > > 2. RW: Is there a capability of bulking updates together? > > > Yes, one could do a PUT or a PATCH on the top-level configuration node. > > > 3. RW: "plain patch" is one patch type that is identified, what other ones > are there, if any? The description of patch above (and where the PATCH > operation is described implies that there will be more than one patch > type.) > > See draft-ietf-netconf-yang-patch Would it be worth adding a cross reference to draft-ietf-netconf-yang-patch either in the description of the term patch, or in the description of the PATCH operation? > > > 4. RW: It might add clarity if "media type" was also defined. > > > > We could copy/paste the first paragraph from RFC7231, section 3.1.1.1: > > HTTP uses Internet media types [RFC2046] in the Content-Type > and Accept header fields in order to provide open and extensible > data typing and type negotiation. Yes, that makes sense. > > > > 5. RW: Is it worth clarifying that child resources included in an HTTP > response could be a different datatype to media type identifier? > > Maybe. I believe the entire tree is application/yang.data, but the > "collection" media-type (no longer in this draft) would've provided a > secondary type (application/yang.collection) that would make you statement > true... I thought that {+restconf}/data was of datatype yang.datastore and then all the children nodes were of yang.data. Hence I thinking that if you did a GET on {+restconf}/data then the media type returned would be yang.datastore even though all the nodes below would be yang.data. I'm sort of wondering whether it is actually necessary to have both yang.datastore and yang.data and whether you couldn't just use yang.data for both? > > 6. RW: Unclear what the "play" operation is here. > > This is the server telling the client that it has an operation (i.e. RPC > statement) called "play". That said, the client could've gotten it from > the YANG module(s), so this whole section might be redundant... I was thinking that perhaps the text above the example could be clarified slightly. E.g. maybe something like: For instance, using the "/restconf/operations" path discovered above, the client can now determine the operations supported by the the server; e.g. in this example a custom play operation is supported : > > > RW: The description of "3.3 API Resource" (below) implies that "data" is > mandatory here, so I was wondering if it should have also been included in > the response? > > Yes, the server MUST implement the {+restconf}/data resource, but in this > example, the client is GET-ing {+restconf}/operations Ah, yes. That makes sense. I had missed that the query was just for operations. > > > 7. RW: Perhaps clarify in some way here that the {+restconf}/data is the > datastore resource. (But, it is explicitly described below, so it may be > unnecessary.) > > Yes, something is off in this section. The previous sentence says "The > datastore resource type is defined in Section 3.4," and it is, but I agree > that all this could be made easier to read. > > > 8. RW: The description below was slightly confusing as to whether it was > refering to both datastore and data resources or just datastore. In > particular, here it states that a server MUST maintain a last-modified > timestamp for this resource, whereas this appears to be optional for data > resources. > > The "this resource" regards the parent section, which is for > {+restconf}/data (the top-level tree node), but there is no corresponding > text for decedent nodes. I think a "SHOULD be supported for decedent > resources" would fix it - yes? Yes. I wonder whether it wouldn't be more clear to have a separate "Edit Collision Detection"/Timestamp/Entity tag section under 3.5. Data Resource? Perhaps just saying that it is the as for the Datastore node, but optional (SHOULD) rather than MUST. > > 9. RW: It is unclear to me what this Entity tag is meant to be? I had > assumed that it would identify who last updated the resource so it was > possible to determine if a resource had been updated between reading it > and patching it, but then the comment that it has to be a new previously > unused value, implies that each value has to be unique in somewhat and > hence perhaps it is just a counter, or a session id? > > > Entity tags are defined here: > https://tools.ietf.org/html/rfc7232#section-2.3. Would adding "entity > tag" to the Terminology section fix it? Yes, I think so. It also made more sense by the time that I had got to the end of the spec and seen some of the examples. > > > 10. RW: Perhaps indent list2 to make it clear that it is a child of list1? > > Yes, and add the missing closing bracket as well (fixed in my local copy) > > > 11. RW: Will the client be able to know whether default values have been > returned for the children nodes? Would it be better to force all defaults > to be returned, otherwise the client may have to query for each and every > node? > > No, the server's response MUST be in accordance with its reported default > handling mode. That said, I think the text could say this a bit better... > > > 12. RW: Is "204 No Content" only sent back on success? Presumably it > could also return an error instead (e.g. not authorized, or perhaps some > other error to indicate that the system cannot comply)? > > HTTP errors are indicated with 4xx and 5xx status codes > (https://tools.ietf.org/html/rfc7231#section-6.5 and > https://tools.ietf.org/html/rfc7231#section-6.6) I was questioning the wording of: "Otherwise the server MUST NOT include a message-body in the response message, and MUST send a "204 No Content" Status-Line instead." I was wondering if it should clarified to indicate that it only returns "204 No Content" if the request was otherwise successful. I.e. of course it could return an error (rather than 204) if the RPC request failed. > > > 13. RW: What it mean by all media types here? Does this mean both JSON > and XML or something else? > > It is trying to say that if GET, PUT, POST, or PATCH are supported, then > they SHOULD be supported for both the +xml and +json variants of > resource's media-type, per whatever the server supports (which apparently > is undefined, except for restconf-state/streams) OK. Would it help if the text was? The OPTIONS method is sent by the client to discover which methods are supported by the server for a specific resource. If a method is supported, it SHOULD be implemented for all media types. > > 12. RW: Presumably you are allowed to create a resource with child > resources as well (e.g. to POST a full configuration)? Is that worth > clarifying here? > > Yes, it can be the full subtree. I suppose it could be stated more > explicitly, though I'm not clear what other interpretation there can be... :-) OK, you say that, but on my initial reading, I had thought that you could POST a full configuration, but only PATCH a single resource. ;-) This was based on reading the definition of "3. Resources (Page 13)" to mean that a resource refer to a single container or leaf, where a container may contain separate child resources, and also the definition of "4.6 PATCH (page 30) that says that it is used to create or update a child resource. Hence my thinking that you could only "patch" one level in the tree, and not recursively patch sub elements as well. So, I think that clarifying this in some way may be beneficial. Perhaps the description of PATCH/POST/PUT could be strengthened to indicate that it applies to a resource and any child resources? > > > 13. RW: Perhaps indent the last line of the table by 2 spaces to make it > more clear? > > > ...or have a smaller URI - e.g., s/restconf-with-defaults/with-defaults/ > ??? Yes. > > > 14. RW: I wonder if implementations would rather choose to implement an > easier syntax than full XPath, perhaps in future these is scope for a > simple-filter. > > We plan more XPath 1.0 expressions for collections. It's suppose to be a > simplified XPath 1.0 expression. OK. > > > 15: RW: I can understand how this works if XML data is being returned, but > what is the equivalent on a XML attribute in JSON to tag a particular > field as being default? > > Please see draft-lhotka-netmod-yang-metadata for how to encode attributes > in JSON > > > 16. RW: Where is it documented how multiple updates are possible with a > single PATCH method? I've found it later - perhaps cross reference > section 5.4 > > Please see draft-ietf-netconf-yang-patch > > > 17. RW: Why is support for XML encoding mandatory? I thought that XML was > quickly going out of fashion - shouldn't this be left to the > implementation. > > This was an issue discussed by the WG (see > https://github.com/netconf-wg/restconf/issues/7). Though the issue > tracker didn't capture it, the very-narrow WG consensus was to have XML be > mandatory to implement. Hum, OK. I could very easily be wrong, but my hunch is that this could problems for someone wanting to implement a greenfield yang based SDN controller. It would seem likely to me that at a minimum that would want to support JSON and possibly a more efficient binary representation, e.g. perhaps GPB and/or MsgPack. But, XML, I doubt that they would be so keen. Thanks, Rob > > > Thanks, > Kent > > > > On 1/19/15, 4:40 AM, "Robert Wilton" wrote: > >> [Adding netconf working group at Andy Bierman's request] >> >> Hi Kent, >> >> I've read though the attached draft (up to the point that the yang >> modules were defined), and I've attached a draft with some inline >> comments (marked with "RW:", 20 locations) where the intent of the text >> wasn't completely clear to me. In some places I found that it was >> clarified later in the doc, so may just need some forward references. >> >> Anyway, hopefully these are helpful and self explanatory, but let me >> know if you need me to clarify any of my comments. >> >> Cheers, >> Rob >> >> >> On 16/01/2015 17:40, Kent Watsen wrote: >>> No problem. >>> >>> Also, in case you are unaware, we're trying to put the final touches on >>> the draft now in preparation for last-call. As it seems you are >>> looking >>> at it pretty carefully now, please report any other issues found. >>> >>> BTW, -03 is a bit outdated. The current, but not yet released, draft is >>> attached. >>> >>> Cheers, >>> Kent >>> >>> >>> >>> On 1/16/15, 12:35 PM, "Robert Wilton" wrote: >>> >>>> Thanks for the quick confirmation. >>>> >>>> Rob >>>> >>>> On 16/01/2015 16:47, Kent Watsen wrote: >>>>> Yes, this appears to be a typo - the "genre" line should've been >>>>> omitted. >>>>> >>>>> Thanks for reporting it! >>>>> >>>>> Kent >>>>> >>>>> >>>>> >>>>> On 1/16/15, 8:51 AM, "Robert Wilton" wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I was just skimming over draft-ietf-netconf-restconf-03, for the >>>>>> description of "3.6. PATCH" on page 29, and the example was slightly >>>>>> confusing in that the description talks about just replacing the >>>>>> "year" >>>>>> field but the JSON patch includes both "genre" and "year". >>>>>> >>>>>> Is this just a typo? >>>>>> >>>>>> Thanks, >>>>>> Rob >>>>>> >> > . > From nobody Thu Jan 22 17:08:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68561A009B; Thu, 22 Jan 2015 17:08:26 -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 eRt1nGTeqGcH; Thu, 22 Jan 2015 17:08:25 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 270FB1B2AC0; Thu, 22 Jan 2015 17:08:25 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=156.39.127.195; From: "Susan Hares" To: "NETCONF" , , Date: Thu, 22 Jan 2015 20:08:21 -0500 Message-ID: <030b01d036a9$14f3cf80$3edb6e80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_030C_01D0367F.2C1EB1E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA2qMM51LzDU+5zTs6Y4GauOzob4g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Joel Jaeggli Subject: [Netconf] IDR Interim on 1/26/2015 10-11:00am ET - Topic BGP Yang Data Modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 01:08:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_030C_01D0367F.2C1EB1E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cross-posting of a Discussion of BGP Yang Data Modules to yang data modules. IDR Interim 2 (BGP Yang Modules) Monday, January 26, 2015 10-00 - 11:30 am | Eastern Standard Time (New York, GMT-05:00) | 1.5 hours Agenda: 1) Agenda Bashing (Sue Hares) - 5 minutes 2) OpenConfig BGP Yang Data Model (Anees Shaikh) - 25 minutes 3) Update on draft-zhdankin-netmod-bgp-cfg (TBD) - 10 minutes 4) Discussion of Two Yang Data Model - 20 minutes Documents or code to read for the meeting: https://github.com/YangModels/yang/tree/master/experimental/openconfig http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 Slides for the interim are at: http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceedings.html Sue Hares Webex info: https://ietf.webex.com/ietf/j.php?MTID=m0221956daac0639931955e8e6eef206d Meeting number: 645 690 989 Meeting password: yangisfun 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: 645 690 989 ------=_NextPart_000_030C_01D0367F.2C1EB1E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cross-postin= g of a Discussion of BGP Yang Data Modules to yang data modules. =

 

IDR Interim 2 (BGP Yang Modules) =

Monday, January 26, 2015 =

10-00 – 11:30 am  |  = Eastern Standard Time (New York, GMT-05:00)  | 1.5 hours =

 

Agenda:

1) = Agenda Bashing (Sue Hares) - 5 minutes

2) OpenConfig BGP Yang Data Model  (Anees Shaikh) = - 25 minutes

3) Update on = draft-zhdankin-netmod-bgp-cfg (TBD)  - 10 minutes

4) Discussion of Two Yang Data Model - 20 minutes =  

 

Documents or code to read for the = meeting:

 

https://github.com/YangModels/yang/tree/master/experimental/openco= nfig

http= ://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01

 

Slides for the interim are at: =   

 

http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceeding= s.html

 

Sue Hares =

 

Webex info:

https://ietf.webex.com/ietf/j.php?MTID=3Dm0221956daac063993195= 5e8e6eef206d

 

 

Meeting = number:            645 = 690 989

Meeting = password:         = yangisfun

 

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: = 645 690 989

 

 

------=_NextPart_000_030C_01D0367F.2C1EB1E0-- From nobody Fri Jan 23 00:21:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFF11A00D8; Fri, 23 Jan 2015 00:21:45 -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 1qF7afuvI6IR; Fri, 23 Jan 2015 00:21:43 -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 E45151A8912; Fri, 23 Jan 2015 00:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7176; q=dns/txt; s=iport; t=1422001303; x=1423210903; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Xc+cZodv1ZiPTmUXruUHb3YelM4MTNWmlNE59fdzxrg=; b=UBjipF43opEPpDe2k3AhBEAa0yPtFb2wsF0v6pOlsamRtdEJdU9I6Mot arrcGbf8OhDxwse3gxK3mCGv+AgXcHw+gaUD1bOja6x1G5E27CE8cNZkE EJAjJ9WlrkQs+OpgfA0l//sMAYtptVrNNfA7EF+aAK6xvMRGwU5u4Awem Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8EABoDwlStJssW/2dsb2JhbABAFwOCQ4EVWMZPhSVKAoFVAQEBAQF9hA0BAQQtORIBDgILDhMLBAcFCgkDAgECAQk7AQMDAQwBBwEBBYgjDTfDA48yAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSMRIJsNBAHEQeEEQWSMIVPgRQ2hGghhTOGLyKCD4ERTz0xAYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,453,1418083200"; d="scan'208,217";a="323509175" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 23 Jan 2015 08:21:42 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0N8Ld9f030462; Fri, 23 Jan 2015 08:21:40 GMT Message-ID: <54C20493.2060200@cisco.com> Date: Fri, 23 Jan 2015 09:21:39 +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: Susan Hares , NETCONF , netmod@ietf.org, Rtg-yang-coord@ietf.org References: <030b01d036a9$14f3cf80$3edb6e80$@ndzh.com> In-Reply-To: <030b01d036a9$14f3cf80$3edb6e80$@ndzh.com> Content-Type: multipart/alternative; boundary="------------020708000705080904030604" Archived-At: Cc: Joel Jaeggli Subject: Re: [Netconf] IDR Interim on 1/26/2015 10-11:00am ET - Topic BGP Yang Data Modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 08:21:45 -0000 This is a multi-part message in MIME format. --------------020708000705080904030604 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Sue, Thanks for forwarding. I will be in a plane at that time. Would you mind recording the meeting. Regards, Benoit > > *Cross-posting of a Discussion of BGP Yang Data Modules to yang data > modules. * > > *IDR Interim 2 (BGP Yang Modules) * > > Monday, January 26, 2015 > > 10-00 – 11:30 am | Eastern Standard Time (New York, GMT-05:00) | > 1.5 hours > > *Agenda: * > > 1) Agenda Bashing (Sue Hares) - 5 minutes > > 2) OpenConfig BGP Yang Data Model (Anees Shaikh) - 25 minutes > > 3) Update on draft-zhdankin-netmod-bgp-cfg (TBD) - 10 minutes > > 4) Discussion of Two Yang Data Model - 20 minutes > > *Documents or code to read for the meeting:* > > https://github.com/YangModels/yang/tree/master/experimental/openconfig > > http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01 > > *Slides for the interim are at: * > > http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceedings.html > > Sue Hares > > Webex info: > > https://ietf.webex.com/ietf/j.php?MTID=m0221956daac0639931955e8e6eef206d > > Meeting number: 645 690 989 > > Meeting password: yangisfun > > 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: 645 690 989 > --------------020708000705080904030604 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Sue,

Thanks for forwarding.
I will be in a plane at that time.
Would you mind recording the meeting.

Regards, Benoit

Cross-posting of a Discussion of BGP Yang Data Modules to yang data modules.

 

IDR Interim 2 (BGP Yang Modules)

Monday, January 26, 2015

10-00 – 11:30 am  |  Eastern Standard Time (New York, GMT-05:00)  | 1.5 hours

 

Agenda:

1) Agenda Bashing (Sue Hares) - 5 minutes

2) OpenConfig BGP Yang Data Model  (Anees Shaikh) - 25 minutes

3) Update on draft-zhdankin-netmod-bgp-cfg (TBD)  - 10 minutes

4) Discussion of Two Yang Data Model - 20 minutes  

 

Documents or code to read for the meeting:

 

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

http://tools.ietf.org/html/draft-zhdankin-netmod-bgp-cfg-01

 

Slides for the interim are at:   

 

http://www.ietf.org/proceedings/interim/2015/01/26/idr/proceedings.html

 

Sue Hares

 

Webex info:

https://ietf.webex.com/ietf/j.php?MTID=m0221956daac0639931955e8e6eef206d

 

 

Meeting number:            645 690 989

Meeting password:         yangisfun

 

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: 645 690 989

 

 


--------------020708000705080904030604-- From nobody Fri Jan 23 02:00:08 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1154B1A1B3E; Fri, 23 Jan 2015 02:00:06 -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 h7jtvwTGHdKq; Fri, 23 Jan 2015 02:00:04 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 78C331A0430; Fri, 23 Jan 2015 02:00:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 28B59187E26; Fri, 23 Jan 2015 01:59:39 -0800 (PST) To: ksekera@cisco.com, rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150123095939.28B59187E26@rfc-editor.org> Date: Fri, 23 Jan 2015 01:59:39 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Verified] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 10:00:06 -0000 The following errata report has been verified for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3980 -------------------------------------- Status: Verified Type: Technical Reported by: Klement Sekera Date Reported: 2014-05-05 Verified by: Benoit Claise (IESG) Section: 6.2.5 6.3 Original Text ------------- In section 6.3: OLD: The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. In section 6.2.5 OLD: o If any sibling nodes of the selection node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output. Corrected Text -------------- In section 6.3: NEW: The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. If any sibling nodes of a node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output. In section 6.2.5 NEW: Notes ----- The intent is to allow the server to always include the key node values and the wording accidentally does not cover this case. Here is the OLD/NEW in a more intuitive way: In section 6.3: OLD: The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. NEW: The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. If any sibling nodes of a node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output. Implicitly in section 6.2.5 to delete the moved text: OLD: If any sibling nodes of the selection node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output. NEW: -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Jan 23 04:11:10 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10051A90A2; Fri, 23 Jan 2015 04:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zEXcHZD9arJG; Fri, 23 Jan 2015 04:10:56 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 113911A90A3; Fri, 23 Jan 2015 04:10:55 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.173.248.22; Date: Fri, 23 Jan 2015 07:13:19 -0500 Message-ID: Importance: normal From: Sue Hares To: Benoit Claise , NETCONF , netmod@ietf.org, Rtg-yang-coord@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_679818315222450" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Joel Jaeggli Subject: Re: [Netconf] IDR Interim on 1/26/2015 10-11:00am ET - Topic BGP Yang Data Modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:11:03 -0000 ----_com.android.email_679818315222450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSB3aWxsIHJlY29yZCB0aGUgbWVldGluZy4gwqBTdWUKCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBH QUxBWFkgU8KuNCwgYW4gQVQmVCA0RyBMVEUgc21hcnRwaG9uZQoKPGRpdj4tLS0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBCZW5vaXQgQ2xhaXNlIDxiY2xh aXNlQGNpc2NvLmNvbT4gPC9kaXY+PGRpdj5EYXRlOjAxLzIzLzIwMTUgIDM6MjEgQU0gIChHTVQt MDU6MDApIDwvZGl2PjxkaXY+VG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+LE5FVENP TkYgPG5ldGNvbmZAaWV0Zi5vcmc+LG5ldG1vZEBpZXRmLm9yZyxSdGcteWFuZy1jb29yZEBpZXRm Lm9yZyA8L2Rpdj48ZGl2PkNjOiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4sSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPiA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBJRFIgSW50ZXJp bSBvbiAxLzI2LzIwMTUgMTAtMTE6MDBhbSBFVCAtIFRvcGljIEJHUCBZYW5nIERhdGEgTW9kdWxl cyA8L2Rpdj48ZGl2Pgo8L2Rpdj5IaSBTdWUsCgpUaGFua3MgZm9yIGZvcndhcmRpbmcuCkkgd2ls bCBiZSBpbiBhIHBsYW5lIGF0IHRoYXQgdGltZS4KV291bGQgeW91IG1pbmQgcmVjb3JkaW5nIHRo ZSBtZWV0aW5nLgoKUmVnYXJkcywgQmVub2l0CkNyb3NzLXBvc3Rpbmcgb2YgYSBEaXNjdXNzaW9u IG9mIEJHUCBZYW5nIERhdGEgTW9kdWxlcyB0byB5YW5nIGRhdGEgbW9kdWxlcy4KIApJRFIgSW50 ZXJpbSAyIChCR1AgWWFuZyBNb2R1bGVzKQpNb25kYXksIEphbnVhcnkgMjYsIDIwMTUKMTAtMDAg 4oCTIDExOjMwIGFtICB8ICBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZb3JrLCBHTVQtMDU6 MDApICB8IDEuNSBob3VycwogCkFnZW5kYToKMSkgQWdlbmRhIEJhc2hpbmcgKFN1ZSBIYXJlcykg LSA1IG1pbnV0ZXMKMikgT3BlbkNvbmZpZyBCR1AgWWFuZyBEYXRhIE1vZGVsICAoQW5lZXMgU2hh aWtoKSAtIDI1IG1pbnV0ZXMKMykgVXBkYXRlIG9uIGRyYWZ0LXpoZGFua2luLW5ldG1vZC1iZ3At Y2ZnIChUQkQpICAtIDEwIG1pbnV0ZXMKNCkgRGlzY3Vzc2lvbiBvZiBUd28gWWFuZyBEYXRhIE1v ZGVsIC0gMjAgbWludXRlcyAgCiAKRG9jdW1lbnRzIG9yIGNvZGUgdG8gcmVhZCBmb3IgdGhlIG1l ZXRpbmc6CiAKaHR0cHM6Ly9naXRodWIuY29tL1lhbmdNb2RlbHMveWFuZy90cmVlL21hc3Rlci9l eHBlcmltZW50YWwvb3BlbmNvbmZpZwpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGRhbmtpbi1uZXRtb2QtYmdwLWNmZy0wMQogClNsaWRlcyBmb3IgdGhlIGludGVyaW0gYXJlIGF0 OiAgIAogCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzAxLzI2 L2lkci9wcm9jZWVkaW5ncy5odG1sCiAKU3VlIEhhcmVzCiAKV2ViZXggaW5mbzoKaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTAyMjE5NTZkYWFjMDYzOTkzMTk1NWU4ZTZl ZWYyMDZkCiAKIApNZWV0aW5nIG51bWJlcjogICAgICAgICAgICA2NDUgNjkwIDk4OQpNZWV0aW5n IHBhc3N3b3JkOiAgICAgICAgIHlhbmdpc2Z1bgogCkpvaW4gYnkgcGhvbmUKMS04NzctNjY4LTQ0 OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpCjEtNjUwLTQ3OS0zMjA4IENh bGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKQWNjZXNzIGNvZGU6IDY0NSA2OTAgOTg5CiAK IAoK ----_com.android.email_679818315222450 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5JIHdpbGwgcmVjb3JkIHRo ZSBtZWV0aW5nLiAmbmJzcDtTdWU8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo5cHg7Y29sb3I6IzU3NTc1NyI+U2VudCB2aWEgdGhl IFNhbXN1bmcgR0FMQVhZIFPCrjQsIGFuIEFUJmFtcDtUIDRHIExURSBzbWFydHBob25lPC9kaXY+ PC9kaXY+PGJyPjxicj48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rp dj48ZGl2PkZyb206IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiA8L2Rpdj48ZGl2 PkRhdGU6MDEvMjMvMjAxNSAgMzoyMSBBTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5UbzogU3Vz YW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4sTkVUQ09ORiA8bmV0Y29uZkBpZXRmLm9yZz4sbmV0 bW9kQGlldGYub3JnLFJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIDwvZGl2PjxkaXY+Q2M6IFFpbiBX dSA8YmlsbC53dUBodWF3ZWkuY29tPixKb2VsIEphZWdnbGkgPGpvZWxqYUBib2d1cy5jb20+IDwv ZGl2PjxkaXY+U3ViamVjdDogUmU6IElEUiBJbnRlcmltIG9uIDEvMjYvMjAxNSAxMC0xMTowMGFt IEVUIC0gVG9waWMgQkdQIFlhbmcgRGF0YSBNb2R1bGVzIDwvZGl2PjxkaXY+PGJyPjwvZGl2Pgog ICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5IaSBTdWUsPGJyPgogICAgICA8YnI+CiAg ICAgIFRoYW5rcyBmb3IgZm9yd2FyZGluZy48YnI+CiAgICAgIEkgd2lsbCBiZSBpbiBhIHBsYW5l IGF0IHRoYXQgdGltZS48YnI+CiAgICAgIFdvdWxkIHlvdSBtaW5kIHJlY29yZGluZyB0aGUgbWVl dGluZy48YnI+CiAgICAgIDxicj4KICAgICAgUmVnYXJkcywgQmVub2l0PGJyPgogICAgPC9kaXY+ CiAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6MDMwYjAxZDAzNmE5JDE0ZjNjZjgwJDNlZGI2ZTgw JEBuZHpoLmNvbSIgdHlwZT0iY2l0ZSI+CiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQt VHlwZSIgY29udGVudD0idGV4dC9odG1sOwogICAgICAgIGNoYXJzZXQ9d2luZG93cy0xMjUyIj4K ICAgICAgPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAo ZmlsdGVyZWQKICAgICAgICBtZWRpdW0pIj4KICAgICAgPHN0eWxlPjwhLS0KLyogRm9udCBEZWZp bml0aW9ucyAqLwpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7CglwYW5v c2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OkNhbGli cmk7CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9CkBmb250LWZhY2UKCXtmb250LWZh bWlseTpUYWhvbWE7CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9Ci8qIFN0eWxlIERl ZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXtt YXJnaW46MGluOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsKCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6Ymx1ZTsKCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQKCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpwdXJwbGU7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30Kc3Bhbi5FbWFpbFN0eWxlMTcKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsKCWNvbG9yOndpbmRvd3RleHQ7 fQouTXNvQ2hwRGVmYXVsdAoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5OwoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9CkBwYWdlIFdvcmRTZWN0aW9uMQoJe3NpemU6OC41 aW4gMTEuMGluOwoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30KZGl2LldvcmRTZWN0 aW9uMQoJe3BhZ2U6V29yZFNlY3Rpb24xO30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4KICAgICAgPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4K ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Q3Jvc3MtcG9zdGluZwogICAgICAgICAgICAgIG9mIGEgRGlzY3Vzc2lvbiBvZiBCR1AgWWFu ZyBEYXRhIE1vZHVsZXMgdG8geWFuZyBkYXRhCiAgICAgICAgICAgICAgbW9kdWxlcy4gPG86cD48 L286cD48L3NwYW4+PC9iPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5JRFIgSW50ZXJp bSAyIChCR1AgWWFuZyBNb2R1bGVzKSA8bzpwPjwvbzpwPjwvYj48L3A+CiAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+TW9uZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDxvOnA+PC9vOnA+PC9wPgog ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjEwLTAwIOKAkyAxMTozMCBhbSZuYnNwOyB8Jm5i c3A7IEVhc3Rlcm4gU3RhbmRhcmQgVGltZQogICAgICAgICAgKE5ldyBZb3JrLCBHTVQtMDU6MDAp Jm5ic3A7IHwgMS41IGhvdXJzIDxvOnA+PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkFnZW5kYTogPG86cD48L286cD48L2I+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3Jt YWwiPjEpIEFnZW5kYSBCYXNoaW5nIChTdWUgSGFyZXMpIC0gNSBtaW51dGVzPG86cD48L286cD48 L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgT3BlbkNvbmZpZyBCR1AgWWFuZyBE YXRhIE1vZGVsICZuYnNwOyhBbmVlcwogICAgICAgICAgU2hhaWtoKSAtIDI1IG1pbnV0ZXM8bzpw PjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4zKSBVcGRhdGUgb24gZHJh ZnQtemhkYW5raW4tbmV0bW9kLWJncC1jZmcKICAgICAgICAgIChUQkQpICZuYnNwOy0gMTAgbWlu dXRlcyA8bzpwPjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj40KSBEaXNj dXNzaW9uIG9mIFR3byBZYW5nIERhdGEgTW9kZWwgLSAyMAogICAgICAgICAgbWludXRlcyAmbmJz cDs8bzpwPjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Eb2N1bWVudHMgb3Ig Y29kZSB0byByZWFkIGZvciB0aGUKICAgICAgICAgICAgbWVldGluZzo8bzpwPjwvbzpwPjwvYj48 L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vWWFuZ01vZGVscy95YW5nL3RyZWUvbWFzdGVyL2V4cGVyaW1l bnRhbC9vcGVuY29uZmlnIj5odHRwczovL2dpdGh1Yi5jb20vWWFuZ01vZGVscy95YW5nL3RyZWUv bWFzdGVyL2V4cGVyaW1lbnRhbC9vcGVuY29uZmlnPC9hPjxvOnA+PC9vOnA+PC9wPgogICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhkYW5raW4tbmV0bW9kLWJncC1jZmctMDEi Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoZGFua2luLW5ldG1vZC1iZ3AtY2Zn LTAxPC9hPjxvOnA+PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5TbGlkZXMgZm9yCiAgICAgICAgICAgICAgdGhlIGludGVyaW0g YXJlIGF0OiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPgogICAgICAgIDxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMDEvMjYvaWRyL3Byb2NlZWRp bmdzLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzAx LzI2L2lkci9wcm9jZWVkaW5ncy5odG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdWUgSGFyZXMgPG86cD48L286cD48L3NwYW4+PC9wPgog ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgogICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPldlYmV4IGluZm86IDxvOnA+PC9vOnA+PC9wPgogICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTAyMjE5NTZkYWFjMDYzOTkzMTk1 NWU4ZTZlZWYyMDZkIj5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMDIy MTk1NmRhYWMwNjM5OTMxOTU1ZThlNmVlZjIwNmQ8L2E+PG86cD48L286cD48L3A+CiAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+TWVldGluZyBudW1iZXI6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2NDUgNjkwIDk4OSA8bzpwPjwvbzpwPjwvcD4K ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5NZWV0aW5nIHBhc3N3b3JkOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB5YW5naXNmdW48bzpwPjwvbzpw PjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4K ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2luIGJ5IHBob25lPG86cD48L286cD48L3A+ CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xs IGZyZWUgbnVtYmVyCiAgICAgICAgICAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+PC9wPgogICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIK ICAgICAgICAgIChVUy9DYW5hZGEpPG86cD48L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+QWNjZXNzIGNvZGU6IDY0NSA2OTAgOTg5PG86cD48L286cD48L3A+CiAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgIDwvZGl2PgogICAgPC9i bG9ja3F1b3RlPgogICAgPGJyPgogIAoKPC9ib2R5Pg== ----_com.android.email_679818315222450-- From nobody Fri Jan 23 09:02:25 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DF41A1AD0 for ; Fri, 23 Jan 2015 09:02:24 -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 JvF-Ni3k6Y8p for ; Fri, 23 Jan 2015 09:02:22 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE921A1ADB for ; Fri, 23 Jan 2015 09:02:22 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 564E6879; Fri, 23 Jan 2015 18:02:21 +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 htTMDWvi_Hre; Fri, 23 Jan 2015 18:01:53 +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, 23 Jan 2015 18:02:20 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 728C920036; Fri, 23 Jan 2015 18:02:20 +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 qmPgz15roHWx; Fri, 23 Jan 2015 18:02:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0CAF20035; Fri, 23 Jan 2015 18:02:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 59A9230E5EB5; Fri, 23 Jan 2015 18:02:19 +0100 (CET) Date: Fri, 23 Jan 2015 18:02:19 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150123170219.GA41485@elstar.local> Mail-Followup-To: Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@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: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 17:02:24 -0000 On Tue, Jan 20, 2015 at 09:11:00PM +0000, Kent Watsen wrote: > > In section 10 (IANA Considerations), should there be an RFC Editor instruction to replace "XXXX" with the RFC number assigned to this draft? I added a comment. > In section 12 (Contributor's Address) seems out of place to me. Apparently this section was added in 2008, in draft-ietf-netconf-tls-05. This was before my time here, but just looking at this doc, I don't understand why this section exists. Should this name be rolled into the Acknowledgements section just before it? Is there a distinction between a contributor and those being acknowledged? > I am fine with moving the name to the list of people listed in the acknowledgments. /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 Jan 23 12:57:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9965E1A7028 for ; Fri, 23 Jan 2015 12:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, 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 LhsGAJybRdxO for ; Fri, 23 Jan 2015 12:57:24 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E321A1B40 for ; Fri, 23 Jan 2015 12:57:24 -0800 (PST) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB455.namprd05.prod.outlook.com (10.141.59.24) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 23 Jan 2015 20:57:00 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.166]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.166]) with mapi id 15.01.0059.007; Fri, 23 Jan 2015 20:57:00 +0000 From: Kent Watsen To: Robert Wilton , "netconf@ietf.org" Thread-Topic: Mail regarding draft-ietf-netconf-restconf Thread-Index: AQHQMZOf3UFpSbYZFkeiqe6KQJQ1GZzCoUAAgABhPID//62MAIAEhLqAgAJEZoCAAUdBAIADJuCA Date: Fri, 23 Jan 2015 20:57:00 +0000 Message-ID: References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> In-Reply-To: <54BFCA70.3060909@cisco.com> 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.241.11] authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR05MB455; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB455; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(76104003)(43784003)(51444003)(51704005)(92566002)(2501002)(83506001)(2656002)(230783001)(66066001)(19580395003)(93886004)(36756003)(107886001)(77156002)(62966003)(106116001)(40100003)(46102003)(122556002)(54356999)(2900100001)(2950100001)(15975445007)(87936001)(99286002)(86362001)(76176999)(50986999)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB455; H:BN1PR05MB456.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: 23 Jan 2015 20:57:00.0931 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB455 Archived-At: Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 20:57:27 -0000 >>2. RW: Is there a capability of bulking updates together? >> >> >> Yes, one could do a PUT or a PATCH on the top-level configuration node. >> >> >> 3. RW: "plain patch" is one patch type that is identified, what other >>ones >> are there, if any? The description of patch above (and where the PATCH >> operation is described implies that there will be more than one patch >> type.) >> >> See draft-ietf-netconf-yang-patch >Would it be worth adding a cross reference to >draft-ietf-netconf-yang-patch either in the description of the term >patch, or in the description of the PATCH operation? Yes, good suggestion [added] >> 4. RW: It might add clarity if "media type" was also defined. >> >> >> >> We could copy/paste the first paragraph from RFC7231, section 3.1.1.1: >> >> HTTP uses Internet media types [RFC2046] in the Content-Type >> and Accept header fields in order to provide open and extensible >> data typing and type negotiation. >Yes, that makes sense. Added. >> 5. RW: Is it worth clarifying that child resources included in an HTTP >> response could be a different datatype to media type identifier? >> >> Maybe. I believe the entire tree is application/yang.data, but the >> "collection" media-type (no longer in this draft) would've provided a >> secondary type (application/yang.collection) that would make you >>statement >> true... >I thought that {+restconf}/data was of datatype yang.datastore and then >all the children nodes were of yang.data. > >Hence I thinking that if you did a GET on {+restconf}/data then the >media type returned would be yang.datastore even though all the nodes >below would be yang.data. > >I'm sort of wondering whether it is actually necessary to have both >yang.datastore and yang.data and whether you couldn't just use yang.data >for both? Makes sense to me - Andy or Martin? >> 6. RW: Unclear what the "play" operation is here. >> >> This is the server telling the client that it has an operation (i.e. RPC >> statement) called "play". That said, the client could've gotten it from >> the YANG module(s), so this whole section might be redundant... >I was thinking that perhaps the text above the example could be >clarified slightly. E.g. maybe something like: >For instance, using the "/restconf/operations" path discovered above, >the client can now determine >the operations supported by the the server; e.g. in this example a >custom play operation is supported : Added - thanks for the text! >> 7. RW: Perhaps clarify in some way here that the {+restconf}/data is the >> datastore resource. (But, it is explicitly described below, so it may >>be >> unnecessary.) >> >> Yes, something is off in this section. The previous sentence says "The >> datastore resource type is defined in Section 3.4," and it is, but I >>agree >> that all this could be made easier to read. This is connected to the other issue above - Andy/Martin? >> 8. RW: The description below was slightly confusing as to whether it was >> refering to both datastore and data resources or just datastore. In >> particular, here it states that a server MUST maintain a last-modified >> timestamp for this resource, whereas this appears to be optional for >>data >> resources. >> >> The "this resource" regards the parent section, which is for >> {+restconf}/data (the top-level tree node), but there is no >>corresponding >> text for decedent nodes. I think a "SHOULD be supported for decedent >> resources" would fix it - yes? >Yes. I changed the text somewhat significantly. Is this clear? The server MUST maintain a last-modified timestamp for the top-level {+restconf}/data resource and SHOULD maintain last-modified timestamps for decendent resources. For all resources, the server MUST return the "Last-Modified" header when the resource is retrieved with the GET or HEAD methods. If the server does not maintain a timestamp for a resource, it MUST return the timestamp of the resource's ancestor, a process that may recurse up to the top-level {+restconf}/data resource. Only changes to configuration data resources within the datastore affect the timestamp. What do you think? Of course, parallel text was added in the ETag section below this Timestamp section. >I wonder whether it wouldn't be more clear to have a separate "Edit >Collision Detection"/Timestamp/Entity tag section under 3.5. Data >Resource? Perhaps just saying that it is the as for the Datastore node, >but optional (SHOULD) rather than MUST. Please see the above text - do you still think a separate section is needed? >> 9. RW: It is unclear to me what this Entity tag is meant to be? I had >> assumed that it would identify who last updated the resource so it was >> possible to determine if a resource had been updated between reading it >> and patching it, but then the comment that it has to be a new previously >> unused value, implies that each value has to be unique in somewhat and >> hence perhaps it is just a counter, or a session id? >> >> >> Entity tags are defined here: >> https://tools.ietf.org/html/rfc7232#section-2.3. Would adding "entity >> tag" to the Terminology section fix it? >Yes, I think so. It also made more sense by the time that I had got to >the end of the spec and seen some of the examples. Instead of adding to Terminology section, I put inline reference to RFC7232, section 2.3. I put a similar reference in the Timestamp section above, but to RFC7232, section 2.2 >>11. RW: Will the client be able to know whether default values have been >> returned for the children nodes? Would it be better to force all >>defaults >> to be returned, otherwise the client may have to query for each and >>every >> node? >> >> No, the server's response MUST be in accordance with its reported >>default >> handling mode. That said, I think the text could say this a bit >>better... OK, I fixed the flow on this paragraph. >> 12. RW: Is "204 No Content" only sent back on success? Presumably it >> could also return an error instead (e.g. not authorized, or perhaps some >> other error to indicate that the system cannot comply)? >> >> HTTP errors are indicated with 4xx and 5xx status codes >> (https://tools.ietf.org/html/rfc7231#section-6.5 and >> https://tools.ietf.org/html/rfc7231#section-6.6) >I was questioning the wording of: >"Otherwise the server MUST NOT include a message-body > in the response message, and MUST send a "204 No Content" Status-Line > instead." > >I was wondering if it should clarified to indicate that it only returns >"204 No Content" if the request was otherwise successful. I.e. of course >it could return an error (rather than 204) if the RPC request failed. I'm OK with the current text. I believe that it is generally understood that 204 is a successful response. >> 13. RW: What it mean by all media types here? Does this mean both JSON >> and XML or something else? >> >> It is trying to say that if GET, PUT, POST, or PATCH are supported, then >> they SHOULD be supported for both the +xml and +json variants of >> resource's media-type, per whatever the server supports (which >>apparently >> is undefined, except for restconf-state/streams) >OK. Would it help if the text was? > The OPTIONS method is sent by the client to discover which methods > are supported by the server for a specific resource. If a method is >supported, > it SHOULD be implemented for all media types. The last sentence is confusing - both the original and yours above. The issue is mostly that the sentence in unneeded at all. Which encodings (xml/json) are supported by a server is orthogonal to which HTTP methods a server supports for a resource. I removed the last sentence. > >> >> 12. RW: Presumably you are allowed to create a resource with child >> resources as well (e.g. to POST a full configuration)? Is that worth >> clarifying here? >> >> Yes, it can be the full subtree. I suppose it could be stated more >> explicitly, though I'm not clear what other interpretation there can >>be... >:-) I added "The data-model for the child tree is the subtree is defined by YANG for the child resource." >OK, you say that, but on my initial reading, I had thought that you >could POST a full configuration, but only PATCH a single resource. ;-) > >This was based on reading the definition of "3. Resources (Page 13)" to >mean that a resource refer to a single container or leaf, where a >container may contain separate child resources, and also the definition >of "4.6 PATCH (page 30) that says that it is used to create or update a >child resource. Hence my thinking that you could only "patch" one level >in the tree, and not recursively patch sub elements as well. > >So, I think that clarifying this in some way may be beneficial. Yup, see previously mentioned addition. >Perhaps the description of PATCH/POST/PUT could be strengthened to >indicate that it applies to a resource and any child resources? I don't want to add text to each of those sections. Actually, the text in "3. Resources (Page 13)" looks complete to me. Can you check this again? >> 13. RW: Perhaps indent the last line of the table by 2 spaces to make it >> more clear? >> >> >> ...or have a smaller URI - e.g., s/restconf-with-defaults/with-defaults/ >> ??? >Yes. So I applied to replacement above, but it did not fix the formatted issue. I'm leaving it for now. >> 17. RW: Why is support for XML encoding mandatory? I thought that XML >>was >> quickly going out of fashion - shouldn't this be left to the >> implementation. >> >> This was an issue discussed by the WG (see >> https://github.com/netconf-wg/restconf/issues/7). Though the issue >> tracker didn't capture it, the very-narrow WG consensus was to have XML >>be >> mandatory to implement. >Hum, OK. > >I could very easily be wrong, but my hunch is that this could problems >for someone wanting to implement a greenfield yang based SDN >controller. It would seem likely to me that at a minimum that would >want to support JSON and possibly a more efficient binary >representation, e.g. perhaps GPB and/or MsgPack. But, XML, I doubt that >they would be so keen. I agree with you and made similar statements to the affect before. This may yet come up again. PS: changes made in this patch: https://github.com/netconf-wg/restconf/commit/2b9821ee1d3cbc773e9b9b720de62 a5f947defed Thanks again, Kent From nobody Fri Jan 23 13:04:52 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BC81A7025 for ; Fri, 23 Jan 2015 13:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 maarwCUQMhhJ for ; Fri, 23 Jan 2015 13:04:37 -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 CFC221A7012 for ; Fri, 23 Jan 2015 13:04:36 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id s18so9475088lam.5 for ; Fri, 23 Jan 2015 13:04:35 -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=UP9k5OHeGflLDj4A+Zv9AcuJU0smCZSnCDIbbpwE2xY=; b=f0NMeR+dN1Y95sRNP8ytjP6/p5DM6KwqX1CQEpLexa0j6zam0gdDTPxvbw46LNvPI2 t0oSp1ZstZOn6cAp1kk9jv8KkI76hHhwJhy4vnFnEmD8dGX0pCXFAlj3HiKeiAkqqkpM Y+hn/kwR0UIy2hXOzguoTT7/kxBR9D6v6sqsKBd0Gixhr3GuKUxAzwKC37Ih4cV44dMt oJZmlL7ZQmJtTPAGiMNcazYgrB6Y2Gqnm99ZhKM9xGfg88YtVaDlk5BQ9MI6tbUApuzp 0VnWfeuDf07fWtdY2RUjx3JBK1XVRTajC07xmzzapOjH3H4hweolZyjzdEH9kwBjNmRX u2Ig== X-Gm-Message-State: ALoCoQnxh4eQvLM/peRWUerwTzkYi06wl0i1ATqK3b8EWT3h1MRWKQGYjpBxcbhgv2FQ987boErv MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr9476969lab.1.1422047075319; Fri, 23 Jan 2015 13:04:35 -0800 (PST) Received: by 10.112.160.41 with HTTP; Fri, 23 Jan 2015 13:04:35 -0800 (PST) In-Reply-To: References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> Date: Fri, 23 Jan 2015 13:04:35 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 21:04:40 -0000 On Fri, Jan 23, 2015 at 12:57 PM, Kent Watsen wrote: > > >>>2. RW: Is there a capability of bulking updates together? >>> >>> >>> Yes, one could do a PUT or a PATCH on the top-level configuration node. >>> >>> >>> 3. RW: "plain patch" is one patch type that is identified, what other >>>ones >>> are there, if any? The description of patch above (and where the PATCH >>> operation is described implies that there will be more than one patch >>> type.) >>> >>> See draft-ietf-netconf-yang-patch >>Would it be worth adding a cross reference to >>draft-ietf-netconf-yang-patch either in the description of the term >>patch, or in the description of the PATCH operation? > > Yes, good suggestion [added] > > Do not add a normative reference to YANG Patch in RESTCONF. The reverse already exists. > > >>> 4. RW: It might add clarity if "media type" was also defined. >>> >>> >>> >>> We could copy/paste the first paragraph from RFC7231, section 3.1.1.1: >>> >>> HTTP uses Internet media types [RFC2046] in the Content-Type >>> and Accept header fields in order to provide open and extensible >>> data typing and type negotiation. >>Yes, that makes sense. > > Added. > > > >>> 5. RW: Is it worth clarifying that child resources included in an HTTP >>> response could be a different datatype to media type identifier? >>> >>> Maybe. I believe the entire tree is application/yang.data, but the >>> "collection" media-type (no longer in this draft) would've provided a >>> secondary type (application/yang.collection) that would make you >>>statement >>> true... >>I thought that {+restconf}/data was of datatype yang.datastore and then >>all the children nodes were of yang.data. >> >>Hence I thinking that if you did a GET on {+restconf}/data then the >>media type returned would be yang.datastore even though all the nodes >>below would be yang.data. >> >>I'm sort of wondering whether it is actually necessary to have both >>yang.datastore and yang.data and whether you couldn't just use yang.data >>for both? > > Makes sense to me - Andy or Martin? > > The application/yang.datastore resource is just a conceptual parent for the YANG data nodes. There is no YANG data-def-stmt that can be associated with the datastore itself. I agree it is odd to do a GET and Accept: application/yang.datastore, just because the target resource references the document root instead of a data node. Why is it better to request data and get back datastore instead? > > >>> 6. RW: Unclear what the "play" operation is here. >>> >>> This is the server telling the client that it has an operation (i.e. RPC >>> statement) called "play". That said, the client could've gotten it from >>> the YANG module(s), so this whole section might be redundant... >>I was thinking that perhaps the text above the example could be >>clarified slightly. E.g. maybe something like: >>For instance, using the "/restconf/operations" path discovered above, >>the client can now determine >>the operations supported by the the server; e.g. in this example a >>custom play operation is supported : > > Added - thanks for the text! > > > > > >>> 7. RW: Perhaps clarify in some way here that the {+restconf}/data is the >>> datastore resource. (But, it is explicitly described below, so it may >>>be >>> unnecessary.) >>> >>> Yes, something is off in this section. The previous sentence says "The >>> datastore resource type is defined in Section 3.4," and it is, but I >>>agree >>> that all this could be made easier to read. > > This is connected to the other issue above - Andy/Martin? > I think the text says restconf/data is the datastore resource. > > > >>> 8. RW: The description below was slightly confusing as to whether it was >>> refering to both datastore and data resources or just datastore. In >>> particular, here it states that a server MUST maintain a last-modified >>> timestamp for this resource, whereas this appears to be optional for >>>data >>> resources. >>> >>> The "this resource" regards the parent section, which is for >>> {+restconf}/data (the top-level tree node), but there is no >>>corresponding >>> text for decedent nodes. I think a "SHOULD be supported for decedent >>> resources" would fix it - yes? >>Yes. > > > I changed the text somewhat significantly. Is this clear? > > The server MUST maintain a last-modified timestamp for the > top-level {+restconf}/data resource and SHOULD maintain > last-modified timestamps for decendent resources. For all > resources, the server MUST return the "Last-Modified" header > when the resource is retrieved with the GET or HEAD methods. > If the server does not maintain a timestamp for a resource, > it MUST return the timestamp of the resource's ancestor, a > process that may recurse up to the top-level {+restconf}/data > resource. Only changes to configuration data resources within > the datastore affect the timestamp. > > > What do you think? > > Of course, parallel text was added in the ETag section below this > Timestamp section. > > > >>I wonder whether it wouldn't be more clear to have a separate "Edit >>Collision Detection"/Timestamp/Entity tag section under 3.5. Data >>Resource? Perhaps just saying that it is the as for the Datastore node, >>but optional (SHOULD) rather than MUST. > > Please see the above text - do you still think a separate section is > needed? > > > > >>> 9. RW: It is unclear to me what this Entity tag is meant to be? I had >>> assumed that it would identify who last updated the resource so it was >>> possible to determine if a resource had been updated between reading it >>> and patching it, but then the comment that it has to be a new previously >>> unused value, implies that each value has to be unique in somewhat and >>> hence perhaps it is just a counter, or a session id? >>> >>> >>> Entity tags are defined here: >>> https://tools.ietf.org/html/rfc7232#section-2.3. Would adding "entity >>> tag" to the Terminology section fix it? >>Yes, I think so. It also made more sense by the time that I had got to >>the end of the spec and seen some of the examples. > > > Instead of adding to Terminology section, I put inline reference to > RFC7232, section 2.3. I put a similar reference in the Timestamp section > above, but to RFC7232, section 2.2 > > > >>>11. RW: Will the client be able to know whether default values have been >>> returned for the children nodes? Would it be better to force all >>>defaults >>> to be returned, otherwise the client may have to query for each and >>>every >>> node? >>> >>> No, the server's response MUST be in accordance with its reported >>>default >>> handling mode. That said, I think the text could say this a bit >>>better... > > OK, I fixed the flow on this paragraph. > > > > >>> 12. RW: Is "204 No Content" only sent back on success? Presumably it >>> could also return an error instead (e.g. not authorized, or perhaps some >>> other error to indicate that the system cannot comply)? >>> >>> HTTP errors are indicated with 4xx and 5xx status codes >>> (https://tools.ietf.org/html/rfc7231#section-6.5 and >>> https://tools.ietf.org/html/rfc7231#section-6.6) >>I was questioning the wording of: >>"Otherwise the server MUST NOT include a message-body >> in the response message, and MUST send a "204 No Content" Status-Line >> instead." >> >>I was wondering if it should clarified to indicate that it only returns >>"204 No Content" if the request was otherwise successful. I.e. of course >>it could return an error (rather than 204) if the RPC request failed. > > I'm OK with the current text. I believe that it is generally understood > that 204 is a successful response. > > > > >>> 13. RW: What it mean by all media types here? Does this mean both JSON >>> and XML or something else? >>> >>> It is trying to say that if GET, PUT, POST, or PATCH are supported, then >>> they SHOULD be supported for both the +xml and +json variants of >>> resource's media-type, per whatever the server supports (which >>>apparently >>> is undefined, except for restconf-state/streams) >>OK. Would it help if the text was? >> The OPTIONS method is sent by the client to discover which methods >> are supported by the server for a specific resource. If a method is >>supported, >> it SHOULD be implemented for all media types. > > The last sentence is confusing - both the original and yours above. The > issue is mostly that the sentence in unneeded at all. Which encodings > (xml/json) are supported by a server is orthogonal to which HTTP methods a > server supports for a resource. I removed the last sentence. > > >> >>> >>> 12. RW: Presumably you are allowed to create a resource with child >>> resources as well (e.g. to POST a full configuration)? Is that worth >>> clarifying here? >>> >>> Yes, it can be the full subtree. I suppose it could be stated more >>> explicitly, though I'm not clear what other interpretation there can >>>be... >>:-) > > > I added "The data-model for the child tree is the subtree is > defined by YANG for the child resource." > > > >>OK, you say that, but on my initial reading, I had thought that you >>could POST a full configuration, but only PATCH a single resource. ;-) >> >>This was based on reading the definition of "3. Resources (Page 13)" to >>mean that a resource refer to a single container or leaf, where a >>container may contain separate child resources, and also the definition >>of "4.6 PATCH (page 30) that says that it is used to create or update a >>child resource. Hence my thinking that you could only "patch" one level >>in the tree, and not recursively patch sub elements as well. >> >>So, I think that clarifying this in some way may be beneficial. > > Yup, see previously mentioned addition. > > >>Perhaps the description of PATCH/POST/PUT could be strengthened to >>indicate that it applies to a resource and any child resources? > > I don't want to add text to each of those sections. Actually, the text in > "3. Resources (Page 13)" looks complete to me. Can you check this again? > > > >>> 13. RW: Perhaps indent the last line of the table by 2 spaces to make it >>> more clear? >>> >>> >>> ...or have a smaller URI - e.g., s/restconf-with-defaults/with-defaults/ >>> ??? >>Yes. > > So I applied to replacement above, but it did not fix the formatted issue. > I'm leaving it for now. > > > > > > >>> 17. RW: Why is support for XML encoding mandatory? I thought that XML >>>was >>> quickly going out of fashion - shouldn't this be left to the >>> implementation. >>> >>> This was an issue discussed by the WG (see >>> https://github.com/netconf-wg/restconf/issues/7). Though the issue >>> tracker didn't capture it, the very-narrow WG consensus was to have XML >>>be >>> mandatory to implement. >>Hum, OK. >> >>I could very easily be wrong, but my hunch is that this could problems >>for someone wanting to implement a greenfield yang based SDN >>controller. It would seem likely to me that at a minimum that would >>want to support JSON and possibly a more efficient binary >>representation, e.g. perhaps GPB and/or MsgPack. But, XML, I doubt that >>they would be so keen. > > I agree with you and made similar statements to the affect before. This > may yet come up again. > > > PS: changes made in this patch: > https://github.com/netconf-wg/restconf/commit/2b9821ee1d3cbc773e9b9b720de62 > a5f947defed > > > Thanks again, > Kent > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Jan 23 13:41:15 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B171A87BD for ; Fri, 23 Jan 2015 13:40: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 vMF2W43yDsPe for ; Fri, 23 Jan 2015 13:40:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:794]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046DB1A87B3 for ; Fri, 23 Jan 2015 13:40:51 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.59.20; Fri, 23 Jan 2015 21:40:28 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Fri, 23 Jan 2015 21:40:28 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] Mail regarding draft-ietf-netconf-restconf Thread-Index: AQHQMZOf3UFpSbYZFkeiqe6KQJQ1GZzCoUAAgABhPID//62MAIAEhLqAgAJEZoCAAUdBAIADJuCAgABV8YD//7Y0gA== Date: Fri, 23 Jan 2015 21:40:27 +0000 Message-ID: References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [66.129.241.11] authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(92566002)(99286002)(102836002)(62966003)(2950100001)(36756003)(66066001)(86362001)(77156002)(50986999)(2900100001)(54356999)(76176999)(106116001)(46102003)(83506001)(40100003)(122556002)(93886004)(230783001)(87936001)(110136001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; 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: 23 Jan 2015 21:40:27.7305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 21:40:53 -0000 Hi Andy, >>>Would it be worth adding a cross reference to >>>draft-ietf-netconf-yang-patch either in the description of the term >>>patch, or in the description of the PATCH operation? >> >> Yes, good suggestion [added] >> >> > >Do not add a normative reference to YANG Patch in RESTCONF. >The reverse already exists. Correct. I added it only as an Informative reference. We can remove it if you don't like it. Thanks, Kent From nobody Fri Jan 23 14:32:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721D81A6EDB for ; Fri, 23 Jan 2015 14:32: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, 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 3BVx6GNoo6Ld for ; Fri, 23 Jan 2015 14:32:30 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338EF1A1B1C for ; Fri, 23 Jan 2015 14:32:29 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.65.19; Fri, 23 Jan 2015 22:32:06 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Fri, 23 Jan 2015 22:32:06 +0000 From: Kent Watsen To: "luchuk@snmp.com" , "netconf@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-call-home-03.txt Thread-Index: AQHQMdNqjeGCbrIRk0K/2wI+9zdOR5zDHsaAgASDHtKABl92AA== Date: Fri, 23 Jan 2015 22:32:05 +0000 Message-ID: References: <201501162128.t0GLSn2W060604@mainfs.snmp.com> <201501191612.t0JGCgKk010289@mainfs.snmp.com> In-Reply-To: <201501191612.t0JGCgKk010289@mainfs.snmp.com> 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.241.11] authentication-results: snmp.com; dkim=none (message not signed) header.d=none;snmp.com; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(43784003)(41574002)(107886001)(87936001)(99286002)(19580395003)(62966003)(77156002)(575784001)(86362001)(92566002)(40100003)(2656002)(106116001)(83506001)(122556002)(551544002)(230783001)(66066001)(2950100001)(2900100001)(36756003)(46102003)(50986999)(76176999)(54356999)(102836002)(2501002)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <77344CF87DB36845B9EEFF1ADFA9B73A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2015 22:32:05.3521 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [Netconf] draft-ietf-netconf-call-home-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 22:32:32 -0000 Hi Alan, Thanks again for your comments! >>>Section 3.2, third paragraph: >>>----------------------------- >>> >>>Would it be appropriate to change "credentials" to "identity"? This is >>>the=20 >>>only paragraph where the term "credentials" is used. >>> >>>When I saw "credentials", I thought of something like a password, host >>>key,=20 >>>or X.509 cert, rather than simply the server's identity. If changing >>>"credentials" to "identity" is not appropriate, then perhaps adding one >>>sentence that defines the term credentials. >> >>We could say "verify identity" as well. Think of the questions the >>client >>is asking: >> >> - who is trying to connect to me? (identity) >> - how do I know that it is really you? (verify identity) >> > >Thanks! This explanation makes very good sense. These were not obvious >to me upon a first read of the document. > >I think other new readers of the document would benefit if this >explanation >could be shoe-horned into the existing text, but I wouldn't delay the >document to add it. I opened issue #11 to track this change: https://github.com/netconf-wg/call-home/issues/11 I think this is a "minor" issue, needing WG review, but not needing a lot of discussion. Hence I went ahead and modified the text (see diff below) and moved the issue to the "Review" state. =20 https://github.com/netconf-wg/call-home/commit/cd4a5f674d7e57a06d7cd0dc8d1b 153d72a573a3 If no one disapproves of this change next week, I'll submit a -04 draft incorporating it then. Last-call is close! Thanks, Kent =20 From nobody Fri Jan 23 17:14:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1231AD35F for ; Fri, 23 Jan 2015 17:14: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 OEtXH8fRxLZL for ; Fri, 23 Jan 2015 17:14:43 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:780]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDAE1AD35D for ; Fri, 23 Jan 2015 17:14:39 -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.59.20; Sat, 24 Jan 2015 01:14:15 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Sat, 24 Jan 2015 01:14:15 +0000 From: Kent Watsen To: "luchuk@snmp.com" , "netconf@ietf.org" , "jshoenwaelder@jacobs-university.de" Thread-Topic: draft-ietf-netconf-server-model-05 Thread-Index: AQHQMfiDOOWWRch7+EWij4CRQEiXKpzH4j0qgAZMI4A= Date: Sat, 24 Jan 2015 01:14:14 +0000 Message-ID: References: <201501192003.t0JK3TR5012654@mainfs.snmp.com> In-Reply-To: <201501192003.t0JK3TR5012654@mainfs.snmp.com> 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.241.11] authentication-results: snmp.com; dkim=none (message not signed) header.d=none;snmp.com; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB460; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 0466CA5A45 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(43784003)(51704005)(76176999)(83506001)(50986999)(86362001)(46102003)(2656002)(87936001)(19580395003)(2501002)(2201001)(54356999)(106116001)(122556002)(66066001)(40100003)(107886001)(92566002)(62966003)(36756003)(2950100001)(230783001)(15975445007)(2900100001)(102836002)(99286002)(77156002); 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: 24 Jan 2015 01:14:14.1785 (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: Subject: Re: [Netconf] draft-ietf-netconf-server-model-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jan 2015 01:14:49 -0000 Hi Alan, >>>Page 14, Section 3.2, ietf-netconf-server.yang, nit >>>--------------------------------------------------- >>> >>> grouping session-options-container { >>> description >>> ""; >>> container session-options { >>> >>>I suggest removing the empty description. I think the reason/purpose of >>>the grouping is obvious enough that a description clause does not assist >>>the reader's understanding. >>> >>>Many of the grouping statements in the ietf-netconf-server.yang module >>>and the ietf-restconf-server.yang module have empty descriptions. >>>This >>>same comment applies to them also. >> >>The empty descriptions are an annoying artifact of the `pyang --ietf` >>option requiring descriptions on these nodes. But I agree that no >>description is needed and that it looks odd as is. I added description for the grouping statements per Juergen's suggestion. This issue was tracked here: https://github.com/netconf-wg/server-model/issues/29. The diff for the change is here: https://github.com/netconf-wg/server-model/commit/fe5186bc4fcfd7db84220bfc0 f8d725124e8435c FWIW, the above diff also address issue #30 (https://github.com/netconf-wg/server-model/issues/30), which adds a description for braces to the tree-diagram section, and other edits per your suggestions. >>>Page 23, Section 3.2, ietf-netconf-server.yang, question >>>-------------------------------------------------------- >>> >>> grouping certificates-container { >>> description >>> ""; >>> container certificates { >>> description >>> "Parent container for the list of certificates."; >>> leaf-list certificate { >>> type string; >>> min-elements 1; >>> description >>> "An unordered list of certificates the TLS server can pick >>> from when sending its Server Certificate message. The value >>> of the string is the unique identifier for a certificate >>> configured on the system. How valid values are discovered >>> is outside the scope of this module, but they are envisioned >>> to be the keys for a list of certificates provided >>> by another YANG module"; >>> reference >>> "RFC 5246: The TLS Protocol, Section 7.4.2"; >>> } >>> } >>> } >>> >>> >>>What happens if the min-elements is not satisfied? >> >>How is this possible? A TLS server must have a server-cert defined... > > >I'll have to study more about the usage of the YANG min-elements >statement. =20 >For this particular case, I'm not clear on what happens if a NETCONF >server=20 >is provisioned with NO certificates. In this case, the TLS components >can't=20 >work, but the min-elements constraint can't be satisfied for NETCONF >retrieval operations either (presumably exchanged over SSH). If the concern is for edit operations, isn't the answer that a server with no certificates would then exclude the "certificates" parent container? - note that it is not marked mandatory true... >>>These questions also apply to the certificates-container grouping in the >>>ietf-restconf-server.yang module. >> >> >>Understood, but no change planned yet. > > >OK. Not trying to beat a dead horse, but it still seems like the data >model=20 >would allow many (e.g., 12) certs to be provisioned on the NETCONF >server. =20 >Let's say that all of the certs use the same cryptographic cipher suites >and=20 >key strengths. The certs only differ in the keys (key pairs). It seems >like any of the certs would be equally good for sending in the Server >Certificate message. For this situation, I'm still not clear on how the >NETCONF server would choose one of the certs to send in a Server >Certificate=20 >message. I would probably write the code so that the server would always >send the first certificate in an ordered list of some kind, and ignore >all=20 >the subsequent certs. > >Have I missed documentation somewhere that describes how the server >chooses >the certificate to send? Per RFC 5246, the client sends cipher_suites in its ClientHello. Then the server selects one of the ciphers in its ServerHello (presumably the first one matching it has a suitable certificate for) and then, as you say, it sends its server certificate in its Certificate message. Your example says all the certs have the same cipher suite - in that case, I agree it makes no sense to configure more than one cert in the list. >>> >>>Page 38, Section 6, "Security Considerations", technical >>>-------------------------------------------------------- >>> >>>The same could be said of the call-home nodes, and probably other nodes. >> >> >>This issue is addressed here: >>https://github.com/netconf-wg/server-model/issues/24 >> >>This is a bit tricky. On one hand, the entire configuration has to be >>protected from unauthorized access and modification. But with NACM, the >>issue is notched up a level to cover what *authorized* users are allowed >>to access and/or modify. I'll look at this again when working on #24... > >OK. > >FWIW, my first quick thought about this is that unauthorized >configuration=20 >of any of the data nodes could have a negative effect on network >operations. >I'd probably protect write access to all data nodes in the data model. >Careful consideration of each node might show that some nodes are less >critical, but the cost/benefit of analyzing each node would be >insufficient=20 >to justify the analysis effort. > >Not sure about which nodes should be guarded against read access. I'd >probably guard all nodes against read access. But again, an analysis >would be a good, but possibly high-effort/low-benefit thing to do. You're probably right about this - I'll keep this in mind when working on issue #24 Thanks again, Kent From nobody Sun Jan 25 11:24:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A011A09C9 for ; Sun, 25 Jan 2015 11:24:46 -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 v8wmqLVLe5xV for ; Sun, 25 Jan 2015 11:24:45 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138AB1A079A for ; Sun, 25 Jan 2015 11:24:45 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gd6so4715437lab.4 for ; Sun, 25 Jan 2015 11:24: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:date:message-id:subject:from:to :content-type; bh=k4rDeTQ+IrRWQNMdB+xp7OhCSvH4REjjroz8utyh+7o=; b=R7Jz+I4Sf508dauJmcYarqNtQk4cVJnnESqvRxVZb3SMnSkbtFFwE7FX+8LyzAq+SI no5xqvT9VbnarS4QLoplddhZCbP5CFSxiI9rVHpzyKVf8rbWlRy8kxg1FrXTUOFVCELa 1Qemiivv1v5cJ/f7h1doYTNTJTk6IDqh0vmX3JmrPWqqc/XLHJwpVbcRu/sIJO24ZWMn 2ghC3Mx9eOfjXQ/B3gjh2yhyRaI7DP9balvWCEiK01ITxwOz9tfQb/tSIzfC2ag4iBXO nkJYUtmzXcOpeMGd1azwxRRtZwbZrb/0PesERy/IdPzzlIeylMOI/rhpvYaygZZoi9QX JEpg== X-Gm-Message-State: ALoCoQkmtfAwleC3WL5rjtEzfo1XvxOg5nybYkcSqip9tnzhXVfx21nzptlgfFbydcMxDfkAmVh3 MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr17443006lam.15.1422213883475; Sun, 25 Jan 2015 11:24:43 -0800 (PST) Received: by 10.112.160.41 with HTTP; Sun, 25 Jan 2015 11:24:43 -0800 (PST) Date: Sun, 25 Jan 2015 11:24:43 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] RESTCONF #13: move ietf-yang-library to new module X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 19:24:46 -0000 Hi, Several people have stated that the ietf-yang-library module should be in its own draft, because it is not RESTCONF-specific. Unless there are any objections by Friday, January 30th, a new draft will be created containing just the ietf-yang-library module. There will be a normative reference from RESTCONF to this new draft. Andy From nobody Sun Jan 25 11:30:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715A11A0A6A for ; Sun, 25 Jan 2015 11:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 EfJ6y76c7Aik for ; Sun, 25 Jan 2015 11:30:42 -0800 (PST) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B23A1A000B for ; Sun, 25 Jan 2015 11:30:42 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id f12so4341131qad.10 for ; Sun, 25 Jan 2015 11:30:41 -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 :message-id:references:to; bh=9UUKpTjeWm2TOdl7Kazg4mOE2SeG5aQXeO5/F6/LHUU=; b=jzbB8wH30ejhwv/d7YrWKAH47cOm6ldd1ah/rG6OeRiIOE2y2HiRNpjYDb0Phz/s7z XTO1izUt1SpsanLBrESvZGm9pOk8qfnv8vNem7yk9KmnvKeansU4LDI9WAcHFctGlA/c 7utXIU3GPpoLKcubaKJsQeD1DVvs5ZEkUyHIS3vuvPfIbFZIk8pV12iiwAAciijbFACa cukMhl2etXDiWWk+1L8QiL6OxEg5fTU0mPKjqyushWAPARAEPGkxFtsHNYgjeSlqzlmm g7Od546b44r6Gyem71ArVdUhADKqRqmaHWp9vaIUVoSG98XBrX9aGBxEc7FFVgUNGR+/ 9hGA== X-Received: by 10.140.108.134 with SMTP id j6mr19463150qgf.68.1422214241403; Sun, 25 Jan 2015 11:30:41 -0800 (PST) Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id t90sm7804635qgd.47.2015.01.25.11.30.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 Jan 2015 11:30:40 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_265CC31C-9DAE-4474-8D7E-365F7A927A57" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mahesh Jethanandani In-Reply-To: Date: Sun, 25 Jan 2015 11:30:39 -0800 Message-Id: References: To: "Ersue, Mehmet (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 19:30:44 -0000 --Apple-Mail=_265CC31C-9DAE-4474-8D7E-365F7A927A57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Chair hat off] I support the publication of this draft. The draft has been well written = and believe it is ready for LC. In addition to the two references that Mehmet mentioned, please = address/update the reference to draft-ietf-netmod-snmp-cfg to RFC 7407. [Chair hat on] Separately, and only because it is mentioned in this document, we need = to clean up the description around how the username is extracted from a = certificate. This can happen in the netconf-server draft. The three = documents talk about a algorithm to extract the username, but the only = option that is clear (at least to me) is when the username is = =E2=80=99specified=E2=80=99. Thanks. > On Jan 5, 2015, at 12:46 PM, Ersue, Mehmet (NSN - DE/Munich) = wrote: >=20 > Dear NETCONF Members, > =20 > we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. > =20 > The document can be found at: > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 = > =20 > Please review and send your comments to the WG mailing list by January = 19, 2015 EOB PT. > =20 > The document is planned to publish as a standard track document. > As a minimum please state that you have read/reviewed and whether you = support the publication. > =20 > Please indicate also if you plan to implement or have already = implementation experience with the rfc5539bis draft. > =20 > Thank you. > Mehmet and Mahesh Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_265CC31C-9DAE-4474-8D7E-365F7A927A57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Chair hat off]

I support the publication of this draft. The draft has been = well written and believe it is ready for LC.

In addition to the two references that = Mehmet mentioned, please address/update the reference to = draft-ietf-netmod-snmp-cfg to RFC 7407.

[Chair hat on]

Separately, and only because it is = mentioned in this document, we need to clean up the description around = how the username is extracted from a certificate. This can happen in the = netconf-server draft. The three documents talk about a algorithm to = extract the username, but the only option that is clear (at least to me) = is when the username is =E2=80=99specified=E2=80=99.

Thanks.

On Jan 5, 2015, at 12:46 PM, Ersue, Mehmet (NSN - DE/Munich) = <mehmet.ersue@nsn.com> wrote:

Dear = NETCONF Members,
 
we hereby issue a WG Last Call for = draft-ietf-netconf-rfc5539bis-07.
 
The document can be found = at:
    http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07
 
Please review and send = your comments to the WG mailing list by January 19, 2015 EOB = PT.
 
The document is planned to publish as a = standard track document.
As a minimum please state that you have = read/reviewed and whether you support the publication.
 
Please indicate also if you plan to = implement or have already implementation experience with the rfc5539bis = draft.
 
Thank you.
Mehmet and = Mahesh

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_265CC31C-9DAE-4474-8D7E-365F7A927A57-- From nobody Sun Jan 25 11:30:56 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49CC1A09C9 for ; Sun, 25 Jan 2015 11:30: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 ZUJmizcn9wlI for ; Sun, 25 Jan 2015 11:30:52 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14C11A1A00 for ; Sun, 25 Jan 2015 11:30:51 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ge10so4746539lab.10 for ; Sun, 25 Jan 2015 11:30:50 -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=jpSH5S81UbNX0hbPpysx8NwsGfAyHgsO5YyBTPFbWec=; b=hE+bAC6eWwc6lkc6Hza5oNMxQzluL17AFLxo0fSQ9htHm/9CIM23qmxqgenauKpf0C FSr+grOk2tEFTpVEEiRyMHkh3TIDnUed05jre/S1QJywiNDPS6A6P+yK309cxIfKMh6K wEjYT52/zuJybNb3RoqTcLV1OZwXe+p27RVLpE0yyM/DIyfkAAekW4yJLiVYD0H8bP+K 9vR3PyQ2ZuVs1mfBru7186TxW/6OJ7a//aoGskgrXnQyRRa5fIZY1BhTMalD5Ji47Xma nF9l2b65ptqsRK4LcVzNM5NQm8b6xVek3Aw+r8zYODDvPrin8XI5c3pk2PuYw/QRXHuW 31Tw== X-Gm-Message-State: ALoCoQlrg2B62DQky4pmF7aYwQj58VFEqIuhPIpfkNIHLWAlJrr5LiWAndr9oZR99DStcg0fP9BJ MIME-Version: 1.0 X-Received: by 10.152.204.40 with SMTP id kv8mr17372158lac.42.1422214249992; Sun, 25 Jan 2015 11:30:49 -0800 (PST) Received: by 10.112.160.41 with HTTP; Sun, 25 Jan 2015 11:30:49 -0800 (PST) Date: Sun, 25 Jan 2015 11:30:49 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] RESTCONF issues verfied X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 19:30:53 -0000 Hi, All RESTCONF and YANG Patch issues in the verify state are now considered verified. (i.e., all except #13). They will be changed to the 'edit' state and the solutions will appear in the next revision of each draft. Andy From nobody Mon Jan 26 00:44:38 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF941A8791 for ; Mon, 26 Jan 2015 00:44:35 -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 lVGi8Vov-s0F for ; Mon, 26 Jan 2015 00:44:33 -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 AB45C1A878E for ; Mon, 26 Jan 2015 00:44:33 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2EFE6AC8 for ; Mon, 26 Jan 2015 09:44:32 +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 f9zpYbFXQkeD for ; Mon, 26 Jan 2015 09:44:30 +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 ; Mon, 26 Jan 2015 09:44:31 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 826D520036 for ; Mon, 26 Jan 2015 09:44:31 +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 GyzUXPwVasup; Mon, 26 Jan 2015 09:36:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC59120035; Mon, 26 Jan 2015 09:44:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5A55830EE2DF; Mon, 26 Jan 2015 09:44:29 +0100 (CET) Date: Mon, 26 Jan 2015 09:44:28 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20150126084428.GA49022@elstar.local> Mail-Followup-To: netconf@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: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 08:44:36 -0000 Hi, I think we talked about this before - I like to have a simple version number or an 'etag' such that I can easily refer to a specific version of a configuration datastore (and I can easily check whether my cached copy of a datastore is still current). What about having a standard datastore version number or 'etag'? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 01:03:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F321A87E3 for ; Mon, 26 Jan 2015 01:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iOvaklHtnog9 for ; Mon, 26 Jan 2015 01:03: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 C64551A87D2 for ; Mon, 26 Jan 2015 01:03:34 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id BA64312801A6; Mon, 26 Jan 2015 10:03:33 +0100 (CET) Date: Mon, 26 Jan 2015 10:03:33 +0100 (CET) Message-Id: <20150126.100333.414626596789158232.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150126084428.GA49022@elstar.local> References: <20150126084428.GA49022@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: netconf@ietf.org Subject: Re: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 09:03:36 -0000 Juergen Schoenwaelder wrote: > Hi, > > I think we talked about this before - I like to have a simple version > number or an 'etag' such that I can easily refer to a specific version > of a configuration datastore (and I can easily check whether my cached > copy of a datastore is still current). What about having a standard > datastore version number or 'etag'? I am all for it! Many existing systems have something like this, but all proprietary solutions. This feature is extremely useful, and we have special code for several proprietary mechanisms; a standard solution would definitely help. Someone just have to write up a solution proposal ;-) A simple, straightforward solution, is to augment netconf-monitoring: augment /ncm:netconf-state/ncm:datastores/ncm:datastore { when "ncm:name = 'running'"; // can be debated leaf transaction-id { type string; description "An opaque string that uniquely identifies the last transaction towards the datastore. A client can use this to detect if the datastore is modified."; } } One drawback with this as the only solution is that it requires an additional round trip to retrieve it after a write operation. So an extension to this idea is to let the sender return a "transaction-id" attribute in the , if the operation modified running (edit-config, copy-config, commit, or some other). /martin From nobody Mon Jan 26 02:17:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2621A88A0 for ; Mon, 26 Jan 2015 02:17:36 -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 DQ72GdTiUvdV for ; Mon, 26 Jan 2015 02:17:34 -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 1FB641A8897 for ; Mon, 26 Jan 2015 02:17:33 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E4F83F6B; Mon, 26 Jan 2015 11:17:31 +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 PKQTX2bg_cmA; Mon, 26 Jan 2015 11:17: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; Mon, 26 Jan 2015 11:17:31 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCAA920035; Mon, 26 Jan 2015 11:17:30 +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 t6ZEQeNFrzxp; Mon, 26 Jan 2015 11:17:29 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA03A20036; Mon, 26 Jan 2015 11:17:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 856F430EE83B; Mon, 26 Jan 2015 11:17:27 +0100 (CET) Date: Mon, 26 Jan 2015 11:17:26 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150126101726.GA49320@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20150126084428.GA49022@elstar.local> <20150126.100333.414626596789158232.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150126.100333.414626596789158232.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 10:17:36 -0000 On Mon, Jan 26, 2015 at 10:03:33AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Hi, > > > > I think we talked about this before - I like to have a simple version > > number or an 'etag' such that I can easily refer to a specific version > > of a configuration datastore (and I can easily check whether my cached > > copy of a datastore is still current). What about having a standard > > datastore version number or 'etag'? > > I am all for it! Many existing systems have something like this, but > all proprietary solutions. This feature is extremely useful, and we > have special code for several proprietary mechanisms; a standard > solution would definitely help. > > Someone just have to write up a solution proposal ;-) > > A simple, straightforward solution, is to augment netconf-monitoring: > > augment /ncm:netconf-state/ncm:datastores/ncm:datastore { > when "ncm:name = 'running'"; // can be debated > > leaf transaction-id { > type string; > description > "An opaque string that uniquely identifies the last > transaction towards the datastore. > > A client can use this to detect if the datastore is > modified."; > } > } I am not sure about the name transaction-id. For me, this should primarily be an indicator when the datastore last changed. If this object is an opaque string, then it might hold something you call a transaction-id. It could also be a simple yang:date-and-time object, e.g. leaf last-modified { type yang:date-and-time; description "The time at which the configuration datastore was last modified."; } This is simple to implement and gives me an order - if I have multiple database snapshots, I can reason about their order. I do not see why this should be restricted to running. Would it not also be useful to track what is in #startup? Of course, a last-modified and a copy from #running to #startup does not make it easy to establish that both configs are the same. Perhaps we should have both, a last-modified timestamp plus a tag that stays the same as long as the datastore contents stays the same. > change drawback with this as the only solution is that it requires an > additional round trip to retrieve it after a write operation. So an > extension to this idea is to let the sender return a "transaction-id" > attribute in the , if the operation modified running > (edit-config, copy-config, commit, or some other). I think we should also augment the netconf-config-change notification. For edit-config, copy-config, commit (did I forget one?), it would indeed be nice to return the new value of this leaf. Unfortunately, these rpcs have no outputs to augment. (Perhaps a lesson to learn here, empty outputs can be useful for augmentation.) I do not think this should be something the should be concerned with. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 02:27:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0755B1A8897 for ; Mon, 26 Jan 2015 02:27:56 -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 xDs96nLRvK3J for ; Mon, 26 Jan 2015 02:27: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 BDD631A88A3 for ; Mon, 26 Jan 2015 02:27: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 917628FB; Mon, 26 Jan 2015 11:27: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 fOjV3-f1g3qU; Mon, 26 Jan 2015 11:27:51 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 Jan 2015 11:27:53 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAB6620037; Mon, 26 Jan 2015 11:27: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 hsOw_Zfxd2L6; Mon, 26 Jan 2015 11:27: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 B466F20036; Mon, 26 Jan 2015 11:27:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 06A5A30EE908; Mon, 26 Jan 2015 11:27:50 +0100 (CET) Date: Mon, 26 Jan 2015 11:27:50 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Message-ID: <20150126102748.GA49439@elstar.local> Mail-Followup-To: Mahesh Jethanandani , "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: 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: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 10:27:56 -0000 On Sun, Jan 25, 2015 at 11:30:39AM -0800, Mahesh Jethanandani wrote: > [Chair hat off] > > I support the publication of this draft. The draft has been well written and believe it is ready for LC. > > In addition to the two references that Mehmet mentioned, please address/update the reference to draft-ietf-netmod-snmp-cfg to RFC 7407. I am confused since draft-ietf-netconf-rfc5539bis-07 does not reference draft-ietf-netmod-snmp-cfg except in appendix B which is marked as "to be removed by RFC Editor before publication". > [Chair hat on] > > Separately, and only because it is mentioned in this document, we need to clean up the description around how the username is extracted from a certificate. This can happen in the netconf-server draft. The three documents talk about a algorithm to extract the username, but the only option that is clear (at least to me) is when the username is ’specified’. > If the text in rfc5539bis is not clear, we should try to improve it. Do you think the text in rfc5539bis is unclear or are you talking about the netconf-server document specifically? (Note that I will address Martin's comments regarding the algorithm, which however are minor changes.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 02:51:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D031A88C3 for ; Mon, 26 Jan 2015 02:51: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 XAlc2C-Na63W for ; Mon, 26 Jan 2015 02:51:03 -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 DBB011A88C2 for ; Mon, 26 Jan 2015 02:51:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A9D06762; Mon, 26 Jan 2015 11:51:01 +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 Gqbadph-Wnde; Mon, 26 Jan 2015 11:50:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 Jan 2015 11:51:00 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A88220036; Mon, 26 Jan 2015 11:51:00 +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 5j_E7ZH-EKiT; Mon, 26 Jan 2015 11:50:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 29E9E20035; Mon, 26 Jan 2015 11:50:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 187D530EEA3F; Mon, 26 Jan 2015 11:50:57 +0100 (CET) Date: Mon, 26 Jan 2015 11:50:57 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150126105054.GB49439@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20150119.214630.606397666971707472.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150119.214630.606397666971707472.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 10:51:05 -0000 On Mon, Jan 19, 2015 at 09:46:30PM +0100, Martin Bjorklund wrote: > Hi, > > I have reviewed draft-ietf-netconf-rfc5539bis-07 and have the > following mostly minor comments: > > o section 5 > > OLD: > > the integrity of the certificate presented by the peer. presented > > NEW: > > the integrity of the certificate presented by the peer. The > presented fixed > o section 6 > > This section is still confusing to me. > > In the second sentence, the text states that "the hostname check MAY > be omitted" - but the text hasn't mentioned any hostname checks so > it is not clear what this refers to. > > The second paragraph talks about how matching is performed - but > matching of what? > > Tom Petch suggested better text in an email from June 10, 2014, but > that text was never finished, I think. Perhaps all that needs to be done is change the order of the sentences in this section. Does this text resolve the issue? The NETCONF client MUST carefully examine the certificate presented by the NETCONF server to determine if it meets the client's expectations. In particular, the NETCONF client MUST check its understanding of the NETCONF server hostname against the server's identity as presented in the certificate presented by the server, in order to prevent man-in-the-middle attacks. If the NETCONF client has external information as to the expected identity of the NETCONF server, the hostname check MAY be omitted. > o section 7 > > The text says: > > The NETCONF protocol [RFC6241] requires that the transport protocol's > authentication process MUST result in an authenticated NETCONF client > identity whose permissions are known to the server. > > I think this is an odd usage of 2119 MUST, since it merely states > what NETCONF requires. I suggest: > > NEW: > > The NETCONF protocol [RFC6241] requires that the transport protocol's > authentication process results in an authenticated NETCONF client > identity whose permissions are known to the server. The MUST was coming straight out of RFC 6241 (section 2.2 page 12) but your proposal makes sense since people might wrongly read this MUST as being a NC over TLS MUST while is it really an RFC6241 MUST. > o section 7 > > OLD: > > The server maintains an ordered list of mappings of certificates > to names. The username is derived by considering each list entry > > NEW: > > The server maintains an ordered list of mappings of certificates > to NETCONF usernames. The username is derived by considering > each list entry fixed > o section 7 > > The textual description of the algorithm refers to node names from > the original YANG model, like 'map-type' and 'cert-to-name', without > further explanation. These node names should be removed, and the > intention explained instead. ack - I will reword those portions to avoid these references > o section 7 > > I think the last sentence is wrong. The way I read it is that first > we run the algorithm (matching certificates and extract a name), and > then we validate this resulting name to see if it is valid. If it > is not valid, we drop the session. > > I think that the idea is that for each list entry, we match the > certificate, extract a name, and then check its validity. If the > cert doesn't match, or if we cannot extract a name, or if the name > is invalid, we continue to the next list entry. > > (in any case, the behavior described here should be clarified also > in ietf-netconf-server-model) I checked RFC 6353 and indeed it treats a value that does not satisfy the tmSecurityName requirements as a soft-error and continue the search (description of snmpTlstmCertToTSNTable). So I will make the suggested change. > o nit > > s/base:1.1/:base:1.1/g (two occurences I believe - yes, this error > is also present in RFC 6242, and it is really minor, but it is easy > to fix here) fixed /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 03:33:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3631A88AD for ; Mon, 26 Jan 2015 03:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ws-zGOPqCfCm for ; Mon, 26 Jan 2015 03:33: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 959EC1A88F8 for ; Mon, 26 Jan 2015 03:33:51 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F9B11280056; Mon, 26 Jan 2015 12:33:50 +0100 (CET) Date: Mon, 26 Jan 2015 12:33:50 +0100 (CET) Message-Id: <20150126.123350.2208019492961984750.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150126101726.GA49320@elstar.local> References: <20150126084428.GA49022@elstar.local> <20150126.100333.414626596789158232.mbj@tail-f.com> <20150126101726.GA49320@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: netconf@ietf.org Subject: Re: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 11:33:53 -0000 Juergen Schoenwaelder wrote: > On Mon, Jan 26, 2015 at 10:03:33AM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > Hi, > > > > > > I think we talked about this before - I like to have a simple version > > > number or an 'etag' such that I can easily refer to a specific version > > > of a configuration datastore (and I can easily check whether my cached > > > copy of a datastore is still current). What about having a standard > > > datastore version number or 'etag'? > > > > I am all for it! Many existing systems have something like this, but > > all proprietary solutions. This feature is extremely useful, and we > > have special code for several proprietary mechanisms; a standard > > solution would definitely help. > > > > Someone just have to write up a solution proposal ;-) > > > > A simple, straightforward solution, is to augment netconf-monitoring: > > > > augment /ncm:netconf-state/ncm:datastores/ncm:datastore { > > when "ncm:name = 'running'"; // can be debated > > > > leaf transaction-id { > > type string; > > description > > "An opaque string that uniquely identifies the last > > transaction towards the datastore. > > > > A client can use this to detect if the datastore is > > modified."; > > } > > } > > I am not sure about the name transaction-id. For me, this should > primarily be an indicator when the datastore last changed. If this > object is an opaque string, then it might hold something you call a > transaction-id. It could also be a simple yang:date-and-time object, > e.g. > > leaf last-modified { > type yang:date-and-time; > description > "The time at which the configuration datastore > was last modified."; > } > > This is simple to implement and gives me an order - if I have multiple > database snapshots, I can reason about their order. Yes - as long as the clock is not modified... > I do not see why this should be restricted to running. Would it not > also be useful to track what is in #startup? Correct. > Of course, a > last-modified and a copy from #running to #startup does not make it > easy to establish that both configs are the same. Perhaps we should > have both, a last-modified timestamp plus a tag that stays the same as > long as the datastore contents stays the same. Ok, as long as we don't require the tag to be the same if the contents are the same. This would require some kind of checksum over the complete db, and that can be expensive. > > change drawback with this as the only solution is that it requires an > > additional round trip to retrieve it after a write operation. So an > > extension to this idea is to let the sender return a "transaction-id" > > attribute in the , if the operation modified running > > (edit-config, copy-config, commit, or some other). > > I think we should also augment the netconf-config-change notification. Yes. > For edit-config, copy-config, commit (did I forget one?), it would > indeed be nice to return the new value of this leaf. Unfortunately, > these rpcs have no outputs to augment. (Perhaps a lesson to learn > here, empty outputs can be useful for augmentation.) The reply to edit-config should be something like this: 20015-04-01... d4e01293a0 This should be fine. And this is perfectly legal YANG: augment "/nc:edit-config/nc:output { leaf last-modified { ... } leaf db-tag { ... } } However, the encoding text in 6020 is probably not quite correct: If the RPC operation invocation succeeded, and no output parameters are returned, the contains a single element defined in [RFC4741]. If output parameters are returned, they are encoded as child elements to the element defined in [RFC4741], in the same order as they are defined within the "output" statement. This text should say that if no output parameters are defined in the "output" statement, then is sent. Then augmented nodes are sent as usual. An issue for YANG 1.1 maybe? /martin From nobody Mon Jan 26 04:06:33 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA01A89A4 for ; Mon, 26 Jan 2015 04:06:32 -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 z0PGVCg0zvN6 for ; Mon, 26 Jan 2015 04:06:29 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031881A89A5 for ; Mon, 26 Jan 2015 04:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7237; q=dns/txt; s=iport; t=1422273989; x=1423483589; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1Q7fh47gvhJ4ZkZBVsXT8ZScYdZDVX/G9/FwQ11pL9A=; b=NNG9TOqhGBf1OwS1KWdknkwnsiDgNkCeXOJ+03dFGc3RmVgIWRUz3zfS zzjLgC/rMIjmgtYyI2AP1keKHhaKsOOo/LMqe+CLT8s9E2VLRu3+Tt3zT 1h814hQcLnJtFhoNTI8lXnd144bIQBeTH+UafrUecOVUIKgnygYeiZC3I U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8EAAQtxlStJssW/2dsb2JhbABag1hZxkCFcQKBVwEBAQEBfYQMAQEBAwE4QBELDgoJFg8JAwIBAgFFBgEMCAEBiCAIDdJ4AQEBAQEBAQEBAQEBAQEBAQEBARUEjycBAVaEKQEEkjmFVoEVgn+CIIVVgnaDPSKDbj4xAYEKgTcBAQE X-IronPort-AV: E=Sophos;i="5.09,468,1418083200"; d="scan'208";a="322879146" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 26 Jan 2015 12:06:26 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0QC6POk031409; Mon, 26 Jan 2015 12:06:26 GMT Message-ID: <54C62DC1.5000507@cisco.com> Date: Mon, 26 Jan 2015 12:06:25 +0000 From: Robert Wilton 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 , "netconf@ietf.org" References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 12:06:32 -0000 Hi Kent, Please see inline On 23/01/2015 20:57, Kent Watsen wrote: >>> 8. RW: The description below was slightly confusing as to whether it was >>> refering to both datastore and data resources or just datastore. In >>> particular, here it states that a server MUST maintain a last-modified >>> timestamp for this resource, whereas this appears to be optional for >>> data >>> resources. >>> >>> The "this resource" regards the parent section, which is for >>> {+restconf}/data (the top-level tree node), but there is no >>> corresponding >>> text for decedent nodes. I think a "SHOULD be supported for decedent >>> resources" would fix it - yes? >> Yes. > > I changed the text somewhat significantly. Is this clear? > > The server MUST maintain a last-modified timestamp for the > top-level {+restconf}/data resource and SHOULD maintain > last-modified timestamps for decendent resources. For all > resources, the server MUST return the "Last-Modified" header > when the resource is retrieved with the GET or HEAD methods. > If the server does not maintain a timestamp for a resource, > it MUST return the timestamp of the resource's ancestor, a > process that may recurse up to the top-level {+restconf}/data > resource. Only changes to configuration data resources within > the datastore affect the timestamp. > > > What do you think? Yes, this is much clearer. As your text indicates, I think that it is quite useful to allow implementations to potentially optimize how many timestamps/etags they use. E.g. I could easily imagine implementations where they would choose to hold a reference to the timestamp/etag at the container level, but not separately for every individual leaf node. BTW, do you think that a client will need to know whether the timestamp applies to the whole datastore, particular subtrees, or individual leaf nodes? And if so, does there need to be a mechanism to query this via RESTCONF? I was also wondering about what the timestamp behaviour would be if a node was deleted. Presumably if that node is deleted, then all parent containers up to the top of the tree would have their timestamp modified accordingly. But what about if a GET "with defaults" is performed on a leaf (that has a default value) that previously existed but had been deleted. In this case, would you expect the server to return a timestamp of when the explicitly configured value was deleted or just return the timestamp of the parent container instead? > > Of course, parallel text was added in the ETag section below this > Timestamp section. > > > >> I wonder whether it wouldn't be more clear to have a separate "Edit >> Collision Detection"/Timestamp/Entity tag section under 3.5. Data >> Resource? Perhaps just saying that it is the as for the Datastore node, >> but optional (SHOULD) rather than MUST. > Please see the above text - do you still think a separate section is > needed? No, I think that your text above is now sufficient/clear. >>> 12. RW: Is "204 No Content" only sent back on success? Presumably it >>> could also return an error instead (e.g. not authorized, or perhaps some >>> other error to indicate that the system cannot comply)? >>> >>> HTTP errors are indicated with 4xx and 5xx status codes >>> (https://tools.ietf.org/html/rfc7231#section-6.5 and >>> https://tools.ietf.org/html/rfc7231#section-6.6) >> I was questioning the wording of: >> "Otherwise the server MUST NOT include a message-body >> in the response message, and MUST send a "204 No Content" Status-Line >> instead." >> >> I was wondering if it should clarified to indicate that it only returns >> "204 No Content" if the request was otherwise successful. I.e. of course >> it could return an error (rather than 204) if the RPC request failed. > I'm OK with the current text. I believe that it is generally understood > that 204 is a successful response. That wasn't quite the point that I was attempting to make (or I didn't make it very well ;-). According to my reading of the existing text, if the rpc does not include an "output" section then it isn't allowed to return an error because it "MUST" send a "204 No Content" Status-line. Hence, I was wondering if it wouldn't help to add a "unless the operation failed" qualifier to the final sentence. E.g. something along the lines of: If the "rpc" statement has an "input" section, then a message-body MAY be sent by the client in the request, otherwise the request message MUST NOT include a message-body. If the "rpc" statement has an "output" section, then a message-body MAY be sent by the server in the response. Otherwise the server MUST NOT include a message-body in the response message, and unless the operation failed, MUST send a "204 No Content" Status-Line instead. But you may deem that returning an error is obvious beyond the point of needing to be explicitly clarified. >>> 12. RW: Presumably you are allowed to create a resource with child >>> resources as well (e.g. to POST a full configuration)? Is that worth >>> clarifying here? >>> >>> Yes, it can be the full subtree. I suppose it could be stated more >>> explicitly, though I'm not clear what other interpretation there can >>> be... >> :-) > > I added "The data-model for the child tree is the subtree is > defined by YANG for the child resource." > > > >> OK, you say that, but on my initial reading, I had thought that you >> could POST a full configuration, but only PATCH a single resource. ;-) >> >> This was based on reading the definition of "3. Resources (Page 13)" to >> mean that a resource refer to a single container or leaf, where a >> container may contain separate child resources, and also the definition >> of "4.6 PATCH (page 30) that says that it is used to create or update a >> child resource. Hence my thinking that you could only "patch" one level >> in the tree, and not recursively patch sub elements as well. >> >> So, I think that clarifying this in some way may be beneficial. > Yup, see previously mentioned addition. > > >> Perhaps the description of PATCH/POST/PUT could be strengthened to >> indicate that it applies to a resource and any child resources? > I don't want to add text to each of those sections. Actually, the text in > "3. Resources (Page 13)" looks complete to me. Can you check this again? It still feels slightly ambiguous to me. In particular, from the text I'm not sure whether it is obvious that a container resource includes any child containers as well. Nor does the definition of "data node" in the Yang spec really clarify. Perhaps this could be made more clear in the description of a resource, although I'm not sure that my description below is a good way to word this, perhaps: 3.5. Data Resource A data resource represents a YANG data node that is a descendant node of a datastore resource. Containers, leafs, list entries and anyxml nodes are data resources. A data resource also includes all descendent child nodes. Thanks, Rob From nobody Mon Jan 26 04:23:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF911A89FB for ; Mon, 26 Jan 2015 04:23:47 -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 onD28C2wiyPG for ; Mon, 26 Jan 2015 04:23: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 B108E1A8968 for ; Mon, 26 Jan 2015 04:23: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 83F2D10D6; Mon, 26 Jan 2015 13:23: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 aDL9R2f2HJsz; Mon, 26 Jan 2015 13:23: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; Mon, 26 Jan 2015 13:23:42 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A41BB20036; Mon, 26 Jan 2015 13:23: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 SRE51WMxM1Gt; Mon, 26 Jan 2015 13:23:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFC2920035; Mon, 26 Jan 2015 13:23:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CF2AD30EEE76; Mon, 26 Jan 2015 13:23:39 +0100 (CET) Date: Mon, 26 Jan 2015 13:23:38 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150126122336.GA49835@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20150126084428.GA49022@elstar.local> <20150126.100333.414626596789158232.mbj@tail-f.com> <20150126101726.GA49320@elstar.local> <20150126.123350.2208019492961984750.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150126.123350.2208019492961984750.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 12:23:47 -0000 On Mon, Jan 26, 2015 at 12:33:50PM +0100, Martin Bjorklund wrote: > > > Of course, a > > last-modified and a copy from #running to #startup does not make it > > easy to establish that both configs are the same. Perhaps we should > > have both, a last-modified timestamp plus a tag that stays the same as > > long as the datastore contents stays the same. > > Ok, as long as we don't require the tag to be the same if the contents > are the same. This would require some kind of checksum over the > complete db, and that can be expensive. > My idea was that operations like a copy-config from to would not lead to a new tag but a new date reflecting when was modified. Ideally, the tag should not change as long as content does not change. > > For edit-config, copy-config, commit (did I forget one?), it would > > indeed be nice to return the new value of this leaf. Unfortunately, > > these rpcs have no outputs to augment. (Perhaps a lesson to learn > > here, empty outputs can be useful for augmentation.) > > The reply to edit-config should be something like this: > > > > 20015-04-01... > d4e01293a0 > > > This should be fine. And this is perfectly legal YANG: > > augment "/nc:edit-config/nc:output { > leaf last-modified { ... } > leaf db-tag { ... } > } Isn't it a probem that "/nc:edit-config/nc:output" does not really exist? > However, the encoding text in 6020 is probably not quite correct: > > If the RPC operation invocation succeeded, and no output parameters > are returned, the contains a single element defined > in [RFC4741]. If output parameters are returned, they are encoded as > child elements to the element defined in [RFC4741], in > the same order as they are defined within the "output" statement. > > This text should say that if no output parameters are defined in the > "output" statement, then is sent. Then augmented nodes are sent > as usual. > > An issue for YANG 1.1 maybe? Maybe, but my concern was that the output path does not really exist. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 04:26:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE221A8A12 for ; Mon, 26 Jan 2015 04:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aoOgN-yYc0ya for ; Mon, 26 Jan 2015 04:26:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1548A1A8A11 for ; Mon, 26 Jan 2015 04:26:37 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 588C81280056; Mon, 26 Jan 2015 13:26:36 +0100 (CET) Date: Mon, 26 Jan 2015 13:26:36 +0100 (CET) Message-Id: <20150126.132636.1695945758174905214.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150126122336.GA49835@elstar.local> References: <20150126101726.GA49320@elstar.local> <20150126.123350.2208019492961984750.mbj@tail-f.com> <20150126122336.GA49835@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: netconf@ietf.org Subject: Re: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 12:26:39 -0000 Juergen Schoenwaelder wrote: > On Mon, Jan 26, 2015 at 12:33:50PM +0100, Martin Bjorklund wrote: > > > > > Of course, a > > > last-modified and a copy from #running to #startup does not make it > > > easy to establish that both configs are the same. Perhaps we should > > > have both, a last-modified timestamp plus a tag that stays the same as > > > long as the datastore contents stays the same. > > > > Ok, as long as we don't require the tag to be the same if the contents > > are the same. This would require some kind of checksum over the > > complete db, and that can be expensive. > > > > My idea was that operations like a copy-config from to > would not lead to a new tag but a new date reflecting when > was modified. Ideally, the tag should not change as long as > content does not change. This is ok. > > > For edit-config, copy-config, commit (did I forget one?), it would > > > indeed be nice to return the new value of this leaf. Unfortunately, > > > these rpcs have no outputs to augment. (Perhaps a lesson to learn > > > here, empty outputs can be useful for augmentation.) > > > > The reply to edit-config should be something like this: > > > > > > > > 20015-04-01... > > d4e01293a0 > > > > > > This should be fine. And this is perfectly legal YANG: > > > > augment "/nc:edit-config/nc:output { > > leaf last-modified { ... } > > leaf db-tag { ... } > > } > > Isn't it a probem that "/nc:edit-config/nc:output" does not really > exist? No, this is already covered in 6020: The "rpc" statement defines an rpc node in the schema tree. Under the rpc node, a schema node with the name "input", and a schema node with the name "output" are also defined. The nodes "input" and "output" are defined in the module's namespace. So the "input" and "output" nodes *always* exist. The reason for this is to handle this particular use case. /martin From nobody Mon Jan 26 07:18:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE971A903E for ; Mon, 26 Jan 2015 07:18: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 xV-kTlFp7kZn for ; Mon, 26 Jan 2015 07:18:25 -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 00DA71A903D for ; Mon, 26 Jan 2015 07:18:15 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id f15so8112068lbj.0 for ; Mon, 26 Jan 2015 07:18: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:content-type; bh=oztjAYhOw+YZAWyj/zZU+NAn53oqfEho9UWd39Ak2R4=; b=U7eN0+VwU8h+eD7BcYAlOFDbLB+6m1Wfm299gx7fy90m/X/tQe9HRd24sqHMMivWx/ HdpyBNRMwoPzoY4GrSQkNAium5HtowfgWzJ88V2RyQh4Z6iCmc1JFIR8ZAb5JJa9t4/g DVnXQWYjApJJSOYljWPxAN1qnWlz2NoLV8Yqj8xYHj2KQKROyxQNpvJDx3rxOhSKAqdd 19X4drDurcykY0fLdWXxoDmS/ki4jDXZQXvmdDBX3ACp+OvIe/mL21ggeWjSxYVLQnCD L6J+JGFao0CTklq5lqnxtAXf5XtOgH1aCHa5cQmjFOhYvoq3lHqTw5cNsUhPL6LhQjiT 7dBw== X-Gm-Message-State: ALoCoQkik3+Qi/PL+HEGPOsPa33C1GiXC7DRf0HuC+cLA95AI/XerxKDKiS9e3evXMm1r53TjTva MIME-Version: 1.0 X-Received: by 10.112.72.197 with SMTP id f5mr21300615lbv.21.1422285493504; Mon, 26 Jan 2015 07:18:13 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 26 Jan 2015 07:18:13 -0800 (PST) In-Reply-To: <20150126084428.GA49022@elstar.local> References: <20150126084428.GA49022@elstar.local> Date: Mon, 26 Jan 2015 07:18:13 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 15:18:27 -0000 On Mon, Jan 26, 2015 at 12:44 AM, Juergen Schoenwaelder wrote: > Hi, > > I think we talked about this before - I like to have a simple version > number or an 'etag' such that I can easily refer to a specific version > of a configuration datastore (and I can easily check whether my cached > copy of a datastore is still current). What about having a standard > datastore version number or 'etag'? > We have talked about this before (since Oct. 2013) The 'config-id' in section 2.1 of NETCONF-EX specifies this capability http://www.ietf.org/id/draft-bierman-netconf-efficiency-extensions-02.txt We also implement extensions to the netconf-config-change to return the new config-id. It is also sent in the to enable config caching as soon as the session starts. Why the interest now in making NETCONF more efficient? NETCONF is for big routers that do not care about wasting bandwidth. CoMI will use CBOR encoding and will be built for efficiency. > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jan 26 07:33:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9241A9064 for ; Mon, 26 Jan 2015 07:33:46 -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 OpppzSXVsmNN for ; Mon, 26 Jan 2015 07:33:44 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280641A902F for ; Mon, 26 Jan 2015 07:33:35 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id ge10so8267346lab.11 for ; Mon, 26 Jan 2015 07:33: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:content-type; bh=AJ9EIG7b0nuS0XhKsm8MJACTEx0t1gwhPpNFXODyC2E=; b=FXPwfgwIIxWwH1G0OPBEtNJlkkAkS8T1VsjqxuA9sqrQray4PnogAz4uVEJJ+lSM3m 93alSvOinyHZma9gA04PjmmSzF9vjfvqwm5XnaoOK4EbgmwE1a0iMX/tw6ikrNKCdTAo biByFjWGije93wDJ9p9GquZNohnI7o1NhnK3cdBjI7M1skQd1LqOIA+VXMAvbP6ArTVA yPrxJgnQdktsdq9fuBQUABH9lHVUxyPxk3QzuKZAW3+W0+Z5oGkVWlA7IwIjwnEKE1kS ptJTk550FaR4T9ByJrZZ6S9Z3zsc7d/jnK+C9SLjZtd1z5l+jsFqUey4td9Ey2ZxzKsC HJ/w== X-Gm-Message-State: ALoCoQnmZnNlwWrwnvDfzP6iZ7vK8aPRqf8Rp+GjgDTB4gPDDe8tOVn1wEXvEzuk6xXy9qgePz+A MIME-Version: 1.0 X-Received: by 10.112.148.34 with SMTP id tp2mr4116917lbb.94.1422286413572; Mon, 26 Jan 2015 07:33:33 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 26 Jan 2015 07:33:33 -0800 (PST) In-Reply-To: <20150126122336.GA49835@elstar.local> References: <20150126084428.GA49022@elstar.local> <20150126.100333.414626596789158232.mbj@tail-f.com> <20150126101726.GA49320@elstar.local> <20150126.123350.2208019492961984750.mbj@tail-f.com> <20150126122336.GA49835@elstar.local> Date: Mon, 26 Jan 2015 07:33:33 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 15:33:46 -0000 On Mon, Jan 26, 2015 at 4:23 AM, Juergen Schoenwaelder wrote: > On Mon, Jan 26, 2015 at 12:33:50PM +0100, Martin Bjorklund wrote: >> >> > Of course, a >> > last-modified and a copy from #running to #startup does not make it >> > easy to establish that both configs are the same. Perhaps we should >> > have both, a last-modified timestamp plus a tag that stays the same as >> > long as the datastore contents stays the same. >> >> Ok, as long as we don't require the tag to be the same if the contents >> are the same. This would require some kind of checksum over the >> complete db, and that can be expensive. >> > > My idea was that operations like a copy-config from to > would not lead to a new tag but a new date reflecting when > was modified. Ideally, the tag should not change as long as > content does not change. > Our code originally did this but I took it out because there are corner-cases where it causes problems for the config-id to go backwards. The running config-id is saved across reboots so it always increments to a previously unused uint64 when the config changes. The config-id should not increment if the server reboots with the same config it had during the previous run. >> > For edit-config, copy-config, commit (did I forget one?), it would >> > indeed be nice to return the new value of this leaf. Unfortunately, >> > these rpcs have no outputs to augment. (Perhaps a lesson to learn >> > here, empty outputs can be useful for augmentation.) >> >> The reply to edit-config should be something like this: >> >> >> >> 20015-04-01... >> d4e01293a0 >> >> >> This should be fine. And this is perfectly legal YANG: This is actually illegal according to the XSD Schema going back to RFC 4741. The server sends or data, but not both. is what it sends if there are no child nodes of /rpc/output defined and no errors occurred in the operation. We have been putting attributes like timestamps in the start-tag for years. RFC 6241 is clear that the server must return any attributes is gets in the . It is not clear about the server adding attributes in the . Clients seems to ignore them quite easily. >> >> augment "/nc:edit-config/nc:output { >> leaf last-modified { ... } >> leaf db-tag { ... } >> } > > Isn't it a probem that "/nc:edit-config/nc:output" does not really > exist? > >> However, the encoding text in 6020 is probably not quite correct: >> >> If the RPC operation invocation succeeded, and no output parameters >> are returned, the contains a single element defined >> in [RFC4741]. If output parameters are returned, they are encoded as >> child elements to the element defined in [RFC4741], in >> the same order as they are defined within the "output" statement. >> >> This text should say that if no output parameters are defined in the >> "output" statement, then is sent. Then augmented nodes are sent >> as usual. >> >> An issue for YANG 1.1 maybe? > > Maybe, but my concern was that the output path does not really exist. > > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jan 26 07:38:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1771A8A93 for ; Mon, 26 Jan 2015 07:38:03 -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 k9BEDXudsV-D for ; Mon, 26 Jan 2015 07:38:01 -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 7A1591A036F for ; Mon, 26 Jan 2015 07:38:01 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4B949F6B; Mon, 26 Jan 2015 16:38:00 +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 TK_gqW_4jeXG; Mon, 26 Jan 2015 16:37:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 Jan 2015 16:37:59 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80DF520035; Mon, 26 Jan 2015 16:37:59 +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 nPuKTj4XOias; Mon, 26 Jan 2015 16:30: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 4BCE020036; Mon, 26 Jan 2015 16:37:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 59EBB30EF674; Mon, 26 Jan 2015 16:37:55 +0100 (CET) Date: Mon, 26 Jan 2015 16:37:55 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150126153752.GB50403@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: <20150126084428.GA49022@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: Netconf Subject: Re: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 15:38:03 -0000 On Mon, Jan 26, 2015 at 07:18:13AM -0800, Andy Bierman wrote: > On Mon, Jan 26, 2015 at 12:44 AM, Juergen Schoenwaelder > wrote: > > Hi, > > > > I think we talked about this before - I like to have a simple version > > number or an 'etag' such that I can easily refer to a specific version > > of a configuration datastore (and I can easily check whether my cached > > copy of a datastore is still current). What about having a standard > > datastore version number or 'etag'? > > > > We have talked about this before (since Oct. 2013) > [...] > > Why the interest now in making NETCONF more efficient? > NETCONF is for big routers that do not care about wasting bandwidth. > CoMI will use CBOR encoding and will be built for efficiency. I am trying to address a requirement in LMAP. All I need is a reasonably efficient way to refer to a certain version of the configuration. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 07:50:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53CF1A90D7 for ; Mon, 26 Jan 2015 07:50:19 -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 fFbSGUkeVvCZ for ; Mon, 26 Jan 2015 07:50:18 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FBC1A90D4 for ; Mon, 26 Jan 2015 07:50:17 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id l4so8214689lbv.13 for ; Mon, 26 Jan 2015 07:50: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=SA/R3KhHH6rpakKtVHzxiKTfj3MpCJ2yV7YZ+dUJdJ4=; b=g/2FhrhLqCOqSv8hatn5q34o6F5J3h6wevp7HnbqBmeNUI5DC33UTqRDExCP121F/M XB0a1PGjv1VB5duTztKCWq52z4HBUMHiKEEnNuz4l9oTqod6p7S5jbGuCBkwbZ12HNdn E/xTJS9gLWVuGGUb7Vgax4SjpnQL4eaMtskO5smUVb+mWlm5N0j3a0tLniC2vVD+64BP QilmV2/ZJM70W9RFFU2jv1JnHqC3di6ZN2zPgkwQc8DAZU+h1oxNfRNBzNIkHZJUmiBZ cLtNROVSf9CzKwam/IUQPBcLO8WScrCkisSeNtNwwrbr0ZiRZKs930i2p6of12g9/iFx idFA== X-Gm-Message-State: ALoCoQn3JOs0yILk4BBYvs2iJNOEP2kFfKBovtEMI0T4FmXDP4/k0JFA3932cfcOg7cB44VRo1kd MIME-Version: 1.0 X-Received: by 10.152.44.193 with SMTP id g1mr21558590lam.15.1422287416330; Mon, 26 Jan 2015 07:50:16 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 26 Jan 2015 07:50:16 -0800 (PST) In-Reply-To: <20150126153752.GB50403@elstar.local> References: <20150126084428.GA49022@elstar.local> <20150126153752.GB50403@elstar.local> Date: Mon, 26 Jan 2015 07:50:16 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] configuration datastore version number or 'etag' X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 15:50:19 -0000 On Mon, Jan 26, 2015 at 7:37 AM, Juergen Schoenwaelder wrote: > On Mon, Jan 26, 2015 at 07:18:13AM -0800, Andy Bierman wrote: >> On Mon, Jan 26, 2015 at 12:44 AM, Juergen Schoenwaelder >> wrote: >> > Hi, >> > >> > I think we talked about this before - I like to have a simple version >> > number or an 'etag' such that I can easily refer to a specific version >> > of a configuration datastore (and I can easily check whether my cached >> > copy of a datastore is still current). What about having a standard >> > datastore version number or 'etag'? >> > >> >> We have talked about this before (since Oct. 2013) >> > > [...] > >> >> Why the interest now in making NETCONF more efficient? >> NETCONF is for big routers that do not care about wasting bandwidth. >> CoMI will use CBOR encoding and will be built for efficiency. > > I am trying to address a requirement in LMAP. All I need is a > reasonably efficient way to refer to a certain version of the > configuration. I suggest a uint64-based config-id. Timestamps cause problems because going backwards can cause false positives for cache hits via If-Modified-Since, If-Unmodified-Since. Daylight savings time causes the same problems. If a config-id goes backwards (which can happen in certain normal operations) then If-Match and If-None-Match will not cause false positives. > > /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 Jan 26 09:42:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDB31A1C05 for ; Mon, 26 Jan 2015 09:42: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, 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 PRGNfDwUiHJJ for ; Mon, 26 Jan 2015 09:42:25 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7BC1A6EE9 for ; Mon, 26 Jan 2015 09:42:25 -0800 (PST) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB393.namprd05.prod.outlook.com (10.141.75.24) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 26 Jan 2015 17:41:56 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 26 Jan 2015 17:41:53 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Mon, 26 Jan 2015 17:41:53 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AdApKKHQsmh1voQ5Sgudn5IwYOG+2QLAF6oAAUs9l4AAA9+GgA== Date: Mon, 26 Jan 2015 17:41:53 +0000 Message-ID: References: <20150119.214630.606397666971707472.mbj@tail-f.com> <20150126105054.GB49439@elstar.local> In-Reply-To: <20150126105054.GB49439@elstar.local> 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.241.12] authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:CO1PR05MB457; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0468FE4A2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(51704005)(99286002)(36756003)(77156002)(19580395003)(46102003)(66066001)(19580405001)(62966003)(83506001)(92566002)(87936001)(122556002)(2950100001)(2900100001)(54356999)(86362001)(40100003)(2656002)(102836002)(50986999)(76176999)(230783001)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; 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-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2015 17:41:53.5300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB393; X-OriginatorOrg: juniper.net Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 17:42:28 -0000 On 1/26/15, 5:50 AM, "Juergen Schoenwaelder" wrote: >On Mon, Jan 19, 2015 at 09:46:30PM +0100, Martin Bjorklund wrote: >>o section 6 >>=20 >> This section is still confusing to me. >>=20 >> In the second sentence, the text states that "the hostname check MAY >> be omitted" - but the text hasn't mentioned any hostname checks so >> it is not clear what this refers to. >>=20 >> The second paragraph talks about how matching is performed - but >> matching of what? >>=20 >> Tom Petch suggested better text in an email from June 10, 2014, but >> that text was never finished, I think. > >Perhaps all that needs to be done is change the order of the >sentences in this section. Does this text resolve the issue? > > The NETCONF client MUST carefully examine the certificate presented > by the NETCONF server to determine if it meets the client's > expectations. In particular, the NETCONF client MUST check its > understanding of the NETCONF server hostname against the server's > identity as presented in the certificate presented by the server, in > order to prevent man-in-the-middle attacks. If the NETCONF client > has external information as to the expected identity of the NETCONF > server, the hostname check MAY be omitted. Yes, this reordering helps the text flow better, but: 1) the term "hostname" may be outdated, RFC 6125 uses the term "reference identifier" =20 2) should this whole section be essentially just a reference RFC 6125, section 6? - is this RFC trying to add anything to or on top of the procedures defined there? PS: we've discussed the "hostname check may be omitted" text before: http://www.ietf.org/mail-archive/web/netconf/current/msg08810.html Kent From nobody Mon Jan 26 10:30:34 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A3E1A6FEF for ; Mon, 26 Jan 2015 10:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 gTlbv5bCfKLD for ; Mon, 26 Jan 2015 10:30:28 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE7E1A7007 for ; Mon, 26 Jan 2015 10:30:25 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id v63so8565806oia.7 for ; Mon, 26 Jan 2015 10:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=26HzLQU4ZeNa/Hd6j+X5L2OTjkc9HZcUuPKx64qU5DA=; b=tmHIYdC3cA936kONqShsKoWy/6jvjehlaX75CcDA8OAKVpHOWBp2Ct9J8qN0nExPHj wivu84Y1fagoGcW7ijCkh0y1syUlQNHxuuwHAeFr56ZF8fVgVZ3tnsEwPLWecC4x7tV+ EJBDHNOAEBqpLJCKKGkk0zL7mWY/c2TXuTi/1xvqz6wwF/vpA4Pd05v4k/pEzNN15zna OH6F2Ca/ddnjFjtSc2jfs2CUaYFqLWgpM24P+P7Cx5LcmB6PdZjac4bfW6pTUZMGkxxf E7oxmt7c+ykoz4pMnr7jxSHecBaly44ToMr6leBGUDQ9qROZEjqpGNujbwcYB+xgPXma MhFA== X-Received: by 10.182.81.195 with SMTP id c3mr13836595oby.60.1422297025117; Mon, 26 Jan 2015 10:30:25 -0800 (PST) MIME-Version: 1.0 References: <20150126102748.GA49439@elstar.local> From: Mahesh Jethanandani Date: Mon, 26 Jan 2015 18:30:24 +0000 Message-ID: To: Juergen Schoenwaelder , "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e47f8f28349050d9254d4 Archived-At: Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 18:30:30 -0000 --047d7b2e47f8f28349050d9254d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ignore both the comments. Apparently, I was looking at an older (-04) version of the draft. On Mon Jan 26 2015 at 2:27:54 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sun, Jan 25, 2015 at 11:30:39AM -0800, Mahesh Jethanandani wrote: > > [Chair hat off] > > > > I support the publication of this draft. The draft has been well writte= n > and believe it is ready for LC. > > > > In addition to the two references that Mehmet mentioned, please > address/update the reference to draft-ietf-netmod-snmp-cfg to RFC 7407. > > I am confused since draft-ietf-netconf-rfc5539bis-07 does not > reference draft-ietf-netmod-snmp-cfg except in appendix B which is > marked as "to be removed by RFC Editor before publication". > > > [Chair hat on] > > > > Separately, and only because it is mentioned in this document, we need > to clean up the description around how the username is extracted from a > certificate. This can happen in the netconf-server draft. The three > documents talk about a algorithm to extract the username, but the only > option that is clear (at least to me) is when the username is =E2=80=99sp= ecified=E2=80=99. > > > > If the text in rfc5539bis is not clear, we should try to improve > it. Do you think the text in rfc5539bis is unclear or are you talking > about the netconf-server document specifically? (Note that I will > address Martin's comments regarding the algorithm, which however are > minor changes.) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7b2e47f8f28349050d9254d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ignore both the comments. Apparently, I was looking at an older (-04) versi= on of the draft.

On Mon Jan 26 2015 at 2:= 27:54 AM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Jan 25, 2015 at 11:30:39AM -0800, Mahesh= Jethanandani wrote:
> [Chair hat off]
>
> I support the publication of this draft. The draft has been well writt= en and believe it is ready for LC.
>
> In addition to the two references that Mehmet mentioned, please addres= s/update the reference to draft-ietf-netmod-snmp-cfg to RFC 7407.

I am confused since draft-ietf-netconf-rfc5539bis-07 does not
reference draft-ietf-netmod-snmp-cfg except in appendix B which is
marked as "to be removed by RFC Editor before publication".

> [Chair hat on]
>
> Separately, and only because it is mentioned in this document, we need= to clean up the description around how the username is extracted from a ce= rtificate. This can happen in the netconf-server draft. The three documents= talk about a algorithm to extract the username, but the only option that i= s clear (at least to me) is when the username is =E2=80=99specified=E2=80= =99.
>

If the text in rfc5539bis is not clear, we should try to improve
it. Do you think the text in rfc5539bis is unclear or are you talking
about the netconf-server document specifically? (Note that I will
address Martin's comments regarding the algorithm, which however are minor changes.)

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus = Ring 1, 28759 Bremen, Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
--047d7b2e47f8f28349050d9254d4-- From nobody Mon Jan 26 13:14:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67411A9025 for ; Mon, 26 Jan 2015 13:14:47 -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 4NA-6K8jZmWC for ; Mon, 26 Jan 2015 13:14:41 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0110.outbound.protection.outlook.com [65.55.169.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A7B1A6F33 for ; Mon, 26 Jan 2015 13:14:41 -0800 (PST) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB265.namprd05.prod.outlook.com (10.141.71.13) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 26 Jan 2015 21:14:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 26 Jan 2015 21:14:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Mon, 26 Jan 2015 21:14:38 +0000 From: Kent Watsen To: Robert Wilton , Netconf Thread-Topic: Mail regarding draft-ietf-netconf-restconf Thread-Index: AQHQMZOf3UFpSbYZFkeiqe6KQJQ1GZzCoUAAgABhPID//62MAIAEhLqAgAJEZoCAAUdBAIADJuCAgAR2k4CAAEVXAA== Date: Mon, 26 Jan 2015 21:14:37 +0000 Message-ID: References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> <54C62DC1.5000507@cisco.com> In-Reply-To: <54C62DC1.5000507@cisco.com> 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.241.12] authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:CO1PR05MB457; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0468FE4A2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51444003)(51704005)(99286002)(93886004)(36756003)(77156002)(46102003)(66066001)(83506001)(62966003)(106116001)(107886001)(92566002)(87936001)(122556002)(2950100001)(2900100001)(54356999)(86362001)(2656002)(40100003)(102836002)(50986999)(76176999)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <0EBD05C3138B0C4DB43BF60250A8F0E0@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2015 21:14:37.7690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB265; X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 21:14:48 -0000 >BTW, do you think that a client will need to know whether the timestamp >applies to the whole datastore, particular subtrees, or individual leaf >nodes? And if so, does there need to be a mechanism to query this via >RESTCONF? Yes! - and this is supported by getting the value for the top-level {+restconf}/data resource, right? >I was also wondering about what the timestamp behaviour would be if a >node was deleted. Presumably if that node is deleted, then all parent >containers up to the top of the tree would have their timestamp modified >accordingly. Correct, is node's timestamp is updated anytime there is a change in its subtree, the top-level {+restconf}/data timestamp is updated for every change. >But what about if a GET "with defaults" is performed on a leaf (that has >a default value) that previously existed but had been deleted. In this >case, would you expect the server to return a timestamp of when the >explicitly configured value was deleted or just return the timestamp of >the parent container instead? Good question. I think that the server would maintain metadata for nodes dependent on its default-handling mode as follows: * report-all: maintain timestamp for leaf having a default always, even if deleted * trim: maintain timestamp for leaf having a default only when value differs from default * explicit: maintain timestamp for a leaf having a default only when its value has been explicitly configured, regardless if the value is the same as the default or not. For those wondering, the reason why 404 Not Found isn't returned is because the draft says this: If the target of a GET method is a data node that represents a leaf that has a default value, and the leaf has not been given a value yet, the server MUST return the default value that is in use by the server. >>That wasn't quite the point that I was attempting to make (or I didn't >make it very well ;-). > > > >But you may deem that returning an error is obvious beyond the point of >needing to be explicitly clarified. That is the case here, yes. I do really think that text is ostensibly about successful responses, and that the "Invoke Operation Mode" section covers what you're looking for. >>>Perhaps the description of PATCH/POST/PUT could be strengthened to >>> indicate that it applies to a resource and any child resources? >> I don't want to add text to each of those sections. Actually, the text >>in >> "3. Resources (Page 13)" looks complete to me. Can you check this >>again? >It still feels slightly ambiguous to me. In particular, from the text >I'm not sure whether it is obvious that a container resource includes >any child containers as well. Nor does the definition of "data node" in >the Yang spec really clarify. > >Perhaps this could be made more clear in the description of a resource, >although I'm not sure that my description below is a good way to word >this, perhaps: > >3.5. Data Resource > > A data resource represents a YANG data node that is a descendant node > of a datastore resource. Containers, leafs, list entries and anyxml > nodes are data resources. A data resource also includes all >descendent child nodes. How about this? A data resource represents a YANG data node that is a descendant node of a datastore resource. Each YANG-defined data node can be uniquely targeted by the request-line of an HTTP operation. Containers, leafs, list entries and anyxml nodes are data resources. =20 The representation maintained for each data resource is the YANG defined subtree for that node. Hence HTTP operations on a data resource simultaneously affect the targeted data node and all its decendents, if any. Thanks, Kent From nobody Mon Jan 26 13:20:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739BA1A6F07 for ; Mon, 26 Jan 2015 13:20:34 -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 5CQh5C7Tgk1A for ; Mon, 26 Jan 2015 13:20: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 5DED31A19F6 for ; Mon, 26 Jan 2015 13:20: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 EEE7010CD; Mon, 26 Jan 2015 22:20:27 +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 x3p22gXcOUkC; Mon, 26 Jan 2015 22:20:23 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 Jan 2015 22:20:27 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0625620036; Mon, 26 Jan 2015 22:20:27 +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 dR5D9C4BC_r0; Mon, 26 Jan 2015 22:12:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A576620035; Mon, 26 Jan 2015 22:20:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 48A0C30FCA59; Mon, 26 Jan 2015 22:20:23 +0100 (CET) Date: Mon, 26 Jan 2015 22:20:23 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150126212021.GA71794@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , Netconf References: <20150119.214630.606397666971707472.mbj@tail-f.com> <20150126105054.GB49439@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: Netconf Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 21:20:34 -0000 On Mon, Jan 26, 2015 at 05:41:53PM +0000, Kent Watsen wrote: > > > On 1/26/15, 5:50 AM, "Juergen Schoenwaelder" > wrote: > > >On Mon, Jan 19, 2015 at 09:46:30PM +0100, Martin Bjorklund wrote: > >>o section 6 > >> > >> This section is still confusing to me. > >> > >> In the second sentence, the text states that "the hostname check MAY > >> be omitted" - but the text hasn't mentioned any hostname checks so > >> it is not clear what this refers to. > >> > >> The second paragraph talks about how matching is performed - but > >> matching of what? > >> > >> Tom Petch suggested better text in an email from June 10, 2014, but > >> that text was never finished, I think. > > > >Perhaps all that needs to be done is change the order of the > >sentences in this section. Does this text resolve the issue? > > > > The NETCONF client MUST carefully examine the certificate presented > > by the NETCONF server to determine if it meets the client's > > expectations. In particular, the NETCONF client MUST check its > > understanding of the NETCONF server hostname against the server's > > identity as presented in the certificate presented by the server, in > > order to prevent man-in-the-middle attacks. If the NETCONF client > > has external information as to the expected identity of the NETCONF > > server, the hostname check MAY be omitted. > > > Yes, this reordering helps the text flow better, but: > > 1) the term "hostname" may be outdated, RFC 6125 uses the term "reference > identifier" Trying to translate this into RFC 6125 terminology leads to this: The NETCONF client MUST carefully examine the certificate presented by the NETCONF server to determine if it meets the client's expectations. In particular, the NETCONF client MUST check its understanding of the NETCONF server's reference identifier (e.g., its hostname) against the server's presented identity encoded in the certificate presented by the server, in order to prevent man-in-the- middle attacks [RFC6125]. If the NETCONF client has external information as to the expected presented identity of the NETCONF server, the check of the presented identity against the reference identity MAY be omitted. Matching is performed according to the rules and guidelines defined in [RFC6125]. If the match fails, the NETCONF client MUST either ask for explicit user confirmation or terminate the connection and indicate the NETCONF server's identity is suspect. Is this clearer now? > 2) should this whole section be essentially just a reference RFC 6125, > section 6? - is this RFC trying to add anything to or on top of the > procedures defined there? > Not really. The problem is that we are going in circles. Some people want the ID to say less, then other people want to say more, then again people want the text the proper terminology, then other people find the text too difficult to read/understand. A real short version of this section would be this: The NETCONF client MUST check the identity of the server according to RFC 6125. If the check fails, the NETCONF client MUST either ask for explicit user confirmation or terminate the connection and indicate the NETCONF server's identity is suspect. I personally like this short version most. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 13:38:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D9A1A1B11 for ; Mon, 26 Jan 2015 13:38: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 Bvd4ITjM8cCw for ; Mon, 26 Jan 2015 13:38:44 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0871A1ACA for ; Mon, 26 Jan 2015 13:38:44 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gd6so10047731lab.4 for ; Mon, 26 Jan 2015 13:38: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; bh=5PUWYC8QmvJjxAz+8F22oZHnwTweQaPD+1pBMOpQ55Q=; b=GrsQEot4Xfd0QMzlLIKnCEtnXCJo3V/GTbjZkl3WbR8sHT72/zwblewmUdsmkz2ql6 FYNP6UpciIYU1qAgRMoanhvfQpNxrqr3NOS9vj3WuDnSBHE4NR2O1FxyrtGCkmWCr7MB enpGT4HXLc1w2UTe8RrKC4uvJFZqCAMQVfRvrxepYMpTRjbj8ga5BLT02S8XiFBNiXW0 +ParpA3RKCASDQZgESUF4dhINzH0mLMq949Pqw0HxvKu4pxiS7n+Ktr2YeDh8QXdNN5F A5jec1PqA8U4Lm/hkofaiooIsn3DAX75eK9gUa+MzoZY85nU8OJPePrwQVKFoY2+F2/X YYQQ== X-Gm-Message-State: ALoCoQkLM87E6wEFn/CN7dncx09+Fx/c0G+72MOLyu5guI3IPhCPqxiMun6lFbVq6ld8vmJ8vr99 MIME-Version: 1.0 X-Received: by 10.152.9.170 with SMTP id a10mr471760lab.1.1422308322916; Mon, 26 Jan 2015 13:38:42 -0800 (PST) Received: by 10.112.78.3 with HTTP; Mon, 26 Jan 2015 13:38:42 -0800 (PST) In-Reply-To: References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> <54C62DC1.5000507@cisco.com> Date: Mon, 26 Jan 2015 13:38:42 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 21:38:49 -0000 On Mon, Jan 26, 2015 at 1:14 PM, Kent Watsen wrote: > >>BTW, do you think that a client will need to know whether the timestamp >>applies to the whole datastore, particular subtrees, or individual leaf >>nodes? And if so, does there need to be a mechanism to query this via >>RESTCONF? > > Yes! - and this is supported by getting the value for the top-level > {+restconf}/data resource, right? > > >>I was also wondering about what the timestamp behaviour would be if a >>node was deleted. Presumably if that node is deleted, then all parent >>containers up to the top of the tree would have their timestamp modified >>accordingly. > > Correct, is node's timestamp is updated anytime there is a change in its > subtree, the top-level {+restconf}/data timestamp is updated for every > change. > > >>But what about if a GET "with defaults" is performed on a leaf (that has >>a default value) that previously existed but had been deleted. In this >>case, would you expect the server to return a timestamp of when the >>explicitly configured value was deleted or just return the timestamp of >>the parent container instead? > > Good question. I think that the server would maintain metadata for nodes > dependent on its default-handling mode as follows: > > * report-all: maintain timestamp for leaf having a default always, even if > deleted > I don't think the server will maintain state for deleted nodes. The timestamp of the parent node will probably be used. Andy > * trim: maintain timestamp for leaf having a default only when value > differs from default > > * explicit: maintain timestamp for a leaf having a default only when its > value has been explicitly configured, regardless if the value is the same > as the default or not. > > > For those wondering, the reason why 404 Not Found isn't returned is > because the draft says this: > > If the target of a GET method is a data node > that represents a leaf that has a default value, > and the leaf has not been given a value yet, the > server MUST return the default value that is in > use by the server. > > > >>>That wasn't quite the point that I was attempting to make (or I didn't >>make it very well ;-). >> >> >> >>But you may deem that returning an error is obvious beyond the point of >>needing to be explicitly clarified. > > That is the case here, yes. I do really think that text is ostensibly > about successful responses, and that the "Invoke Operation Mode" section > covers what you're looking for. > > > > > >>>>Perhaps the description of PATCH/POST/PUT could be strengthened to >>>> indicate that it applies to a resource and any child resources? >>> I don't want to add text to each of those sections. Actually, the text >>>in >>> "3. Resources (Page 13)" looks complete to me. Can you check this >>>again? >>It still feels slightly ambiguous to me. In particular, from the text >>I'm not sure whether it is obvious that a container resource includes >>any child containers as well. Nor does the definition of "data node" in >>the Yang spec really clarify. >> >>Perhaps this could be made more clear in the description of a resource, >>although I'm not sure that my description below is a good way to word >>this, perhaps: >> >>3.5. Data Resource >> >> A data resource represents a YANG data node that is a descendant node >> of a datastore resource. Containers, leafs, list entries and anyxml >> nodes are data resources. A data resource also includes all >>descendent child nodes. > > How about this? > > A data resource represents a YANG data node that is a descendant > node of a datastore resource. Each YANG-defined data node can > be uniquely targeted by the request-line of an HTTP operation. > Containers, leafs, list entries and anyxml nodes are data resources. > > The representation maintained for each data resource is the YANG > defined subtree for that node. Hence HTTP operations on a data > resource simultaneously affect the targeted data node and all > its decendents, if any. > > > > > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Jan 26 13:48:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544341B2A7C for ; Mon, 26 Jan 2015 13:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9gnZGmKgTwVL for ; Mon, 26 Jan 2015 13:48: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 C7BFF1B29BB for ; Mon, 26 Jan 2015 13:48:31 -0800 (PST) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id B0F5612801A6; Mon, 26 Jan 2015 22:48:30 +0100 (CET) Date: Mon, 26 Jan 2015 22:50:48 +0100 (CET) Message-Id: <20150126.225048.1614476587178000647.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20150126212021.GA71794@elstar.local> References: <20150126105054.GB49439@elstar.local> <20150126212021.GA71794@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 21:48:38 -0000 Juergen Schoenwaelder wrote: > On Mon, Jan 26, 2015 at 05:41:53PM +0000, Kent Watsen wrote: > > > > > > On 1/26/15, 5:50 AM, "Juergen Schoenwaelder" > > wrote: > > > > >On Mon, Jan 19, 2015 at 09:46:30PM +0100, Martin Bjorklund wrote: > > >>o section 6 > > >> > > >> This section is still confusing to me. > > >> > > >> In the second sentence, the text states that "the hostname check MAY > > >> be omitted" - but the text hasn't mentioned any hostname checks so > > >> it is not clear what this refers to. > > >> > > >> The second paragraph talks about how matching is performed - but > > >> matching of what? > > >> > > >> Tom Petch suggested better text in an email from June 10, 2014, but > > >> that text was never finished, I think. > > > > > >Perhaps all that needs to be done is change the order of the > > >sentences in this section. Does this text resolve the issue? > > > > > > The NETCONF client MUST carefully examine the certificate presented > > > by the NETCONF server to determine if it meets the client's > > > expectations. In particular, the NETCONF client MUST check its > > > understanding of the NETCONF server hostname against the server's > > > identity as presented in the certificate presented by the server, in > > > order to prevent man-in-the-middle attacks. If the NETCONF client > > > has external information as to the expected identity of the NETCONF > > > server, the hostname check MAY be omitted. > > > > > > Yes, this reordering helps the text flow better, but: > > > > 1) the term "hostname" may be outdated, RFC 6125 uses the term "reference > > identifier" > > Trying to translate this into RFC 6125 terminology leads to this: > > The NETCONF client MUST carefully examine the certificate presented > by the NETCONF server to determine if it meets the client's > expectations. In particular, the NETCONF client MUST check its > understanding of the NETCONF server's reference identifier (e.g., its > hostname) against the server's presented identity encoded in the > certificate presented by the server, in order to prevent man-in-the- > middle attacks [RFC6125]. If the NETCONF client has external > information as to the expected presented identity of the NETCONF > server, the check of the presented identity against the reference > identity MAY be omitted. > > Matching is performed according to the rules and guidelines defined > in [RFC6125]. If the match fails, the NETCONF client MUST either ask > for explicit user confirmation or terminate the connection and > indicate the NETCONF server's identity is suspect. > > Is this clearer now? > > > 2) should this whole section be essentially just a reference RFC 6125, > > section 6? - is this RFC trying to add anything to or on top of the > > procedures defined there? > > > > Not really. The problem is that we are going in circles. Some people > want the ID to say less, then other people want to say more, then > again people want the text the proper terminology, then other people > find the text too difficult to read/understand. A real short version > of this section would be this: > > The NETCONF client MUST check the identity of the server according > to RFC 6125. If the check fails, the NETCONF client MUST either ask > for explicit user confirmation or terminate the connection and > indicate the NETCONF server's identity is suspect. Should we be even more explicit and refer to section 6? > I personally like this short version most. Me too. But I note that in case of match failure, your text says MUST [...] terminate the connection, whereas 6125 says SHOULD. This is either a reason for not trying to provide a shorter version of the authoritative text, or it should be pointed out explicitly. /martin From nobody Mon Jan 26 14:01:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660F41B2AA5 for ; Mon, 26 Jan 2015 14:01:44 -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 x17Mpe80r3gS for ; Mon, 26 Jan 2015 14:01:42 -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 3BA7F1B2AA3 for ; Mon, 26 Jan 2015 14:01:42 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B444EFCD; Mon, 26 Jan 2015 23:01:40 +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 Hv4oOSFYUZ9Q; Mon, 26 Jan 2015 23:01:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 Jan 2015 23:01:39 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7196E20036; Mon, 26 Jan 2015 23:01:39 +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 AjBW36Gj_blA; Mon, 26 Jan 2015 22:53: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 A74D320035; Mon, 26 Jan 2015 23:01:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0203930FCB58; Mon, 26 Jan 2015 23:01:36 +0100 (CET) Date: Mon, 26 Jan 2015 23:01:35 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20150126220134.GA71987@elstar.local> Mail-Followup-To: Martin Bjorklund , kwatsen@juniper.net, netconf@ietf.org References: <20150126105054.GB49439@elstar.local> <20150126212021.GA71794@elstar.local> <20150126.225048.1614476587178000647.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150126.225048.1614476587178000647.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 22:01:44 -0000 On Mon, Jan 26, 2015 at 10:50:48PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jan 26, 2015 at 05:41:53PM +0000, Kent Watsen wrote: > > > > > > > > > On 1/26/15, 5:50 AM, "Juergen Schoenwaelder" > > > wrote: > > > > > > >On Mon, Jan 19, 2015 at 09:46:30PM +0100, Martin Bjorklund wrote: > > > >>o section 6 > > > >> > > > >> This section is still confusing to me. > > > >> > > > >> In the second sentence, the text states that "the hostname check MAY > > > >> be omitted" - but the text hasn't mentioned any hostname checks so > > > >> it is not clear what this refers to. > > > >> > > > >> The second paragraph talks about how matching is performed - but > > > >> matching of what? > > > >> > > > >> Tom Petch suggested better text in an email from June 10, 2014, but > > > >> that text was never finished, I think. > > > > > > > >Perhaps all that needs to be done is change the order of the > > > >sentences in this section. Does this text resolve the issue? > > > > > > > > The NETCONF client MUST carefully examine the certificate presented > > > > by the NETCONF server to determine if it meets the client's > > > > expectations. In particular, the NETCONF client MUST check its > > > > understanding of the NETCONF server hostname against the server's > > > > identity as presented in the certificate presented by the server, in > > > > order to prevent man-in-the-middle attacks. If the NETCONF client > > > > has external information as to the expected identity of the NETCONF > > > > server, the hostname check MAY be omitted. > > > > > > > > > Yes, this reordering helps the text flow better, but: > > > > > > 1) the term "hostname" may be outdated, RFC 6125 uses the term "reference > > > identifier" > > > > Trying to translate this into RFC 6125 terminology leads to this: > > > > The NETCONF client MUST carefully examine the certificate presented > > by the NETCONF server to determine if it meets the client's > > expectations. In particular, the NETCONF client MUST check its > > understanding of the NETCONF server's reference identifier (e.g., its > > hostname) against the server's presented identity encoded in the > > certificate presented by the server, in order to prevent man-in-the- > > middle attacks [RFC6125]. If the NETCONF client has external > > information as to the expected presented identity of the NETCONF > > server, the check of the presented identity against the reference > > identity MAY be omitted. > > > > Matching is performed according to the rules and guidelines defined > > in [RFC6125]. If the match fails, the NETCONF client MUST either ask > > for explicit user confirmation or terminate the connection and > > indicate the NETCONF server's identity is suspect. > > > > Is this clearer now? > > > > > 2) should this whole section be essentially just a reference RFC 6125, > > > section 6? - is this RFC trying to add anything to or on top of the > > > procedures defined there? > > > > > > > Not really. The problem is that we are going in circles. Some people > > want the ID to say less, then other people want to say more, then > > again people want the text the proper terminology, then other people > > find the text too difficult to read/understand. A real short version > > of this section would be this: > > > > The NETCONF client MUST check the identity of the server according > > to RFC 6125. If the check fails, the NETCONF client MUST either ask > > for explicit user confirmation or terminate the connection and > > indicate the NETCONF server's identity is suspect. > > Should we be even more explicit and refer to section 6? > > > I personally like this short version most. > > Me too. But I note that in case of match failure, your text says MUST > [...] terminate the connection, whereas 6125 says SHOULD. This is > either a reason for not trying to provide a shorter version of the > authoritative text, or it should be pointed out explicitly. > OK. So here is an even shorter version: The NETCONF client MUST check the identity of the server according to Section 6 of RFC 6125. This is a slight change form RFC 5539 but then RFC 6125 did not exist back then and so it probably makes sense to align RFC 5539bis with RFC 6125. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 16:55:20 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579451B2B4C for ; Mon, 26 Jan 2015 16:55: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 cmOxd_Kjcs9x for ; Mon, 26 Jan 2015 16:55:15 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.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 205CE1B2B4F for ; Mon, 26 Jan 2015 16:54:47 -0800 (PST) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB474.namprd05.prod.outlook.com (10.141.72.12) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 00:54:45 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 00:54:43 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 00:54:43 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AdApKKHQsmh1voQ5Sgudn5IwYOG+2QLAF6oAAUs9l4AAA9+GgAASHA2AAAEP8gAAAGBpgP//3IwA Date: Tue, 27 Jan 2015 00:54:42 +0000 Message-ID: References: <20150126105054.GB49439@elstar.local> <20150126212021.GA71794@elstar.local> <20150126.225048.1614476587178000647.mbj@tail-f.com> <20150126220134.GA71987@elstar.local> In-Reply-To: <20150126220134.GA71987@elstar.local> 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.241.12] authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:CO1PR05MB457; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(2950100001)(2900100001)(54356999)(86362001)(122556002)(110136001)(92566002)(87936001)(50986999)(76176999)(230783001)(102836002)(40100003)(2656002)(93886004)(36756003)(99286002)(46102003)(66066001)(62966003)(83506001)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <7E2B81EB8F61A740A001E95634554D6D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 00:54:42.3461 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB474; X-OriginatorOrg: juniper.net Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 00:55:17 -0000 >OK. So here is an even shorter version: > > The NETCONF client MUST check the identity of the server according > to Section 6 of RFC 6125. That seems almost too short, but I agree that a short normative reference is better than copy/paste text. >This is a slight change form RFC 5539 but then RFC 6125 did not exist >back then and so it probably makes sense to align RFC 5539bis with RFC >6125. True. Question: the title and text refer to "X.509", but both RFC 5246 and RFC 5280 refer to "X.509v3" or "X.509 v3". Does it matter? Kent From nobody Mon Jan 26 23:12:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7201B2BA8 for ; Mon, 26 Jan 2015 23:12:22 -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 SZsa-XnfizHw for ; Mon, 26 Jan 2015 23:12: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 5F6481B2BA7 for ; Mon, 26 Jan 2015 23:12: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 050431733; Tue, 27 Jan 2015 08:12: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 3cuya54qWRQl; Tue, 27 Jan 2015 08:12:01 +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, 27 Jan 2015 08:12:08 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BFED20037; Tue, 27 Jan 2015 08:12:08 +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 UBXf4gUGrcSM; Tue, 27 Jan 2015 08:12:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3148420035; Tue, 27 Jan 2015 08:12:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4B31030FD037; Tue, 27 Jan 2015 08:12:05 +0100 (CET) Date: Tue, 27 Jan 2015 08:12:04 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20150127071203.GA76451@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20150126105054.GB49439@elstar.local> <20150126212021.GA71794@elstar.local> <20150126.225048.1614476587178000647.mbj@tail-f.com> <20150126220134.GA71987@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: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 07:12:22 -0000 On Tue, Jan 27, 2015 at 12:54:42AM +0000, Kent Watsen wrote: > > > >OK. So here is an even shorter version: > > > > The NETCONF client MUST check the identity of the server according > > to Section 6 of RFC 6125. > > That seems almost too short, but I agree that a short normative reference > is better than copy/paste text. Unless anything technically is missing, I prefer to keep the text short and not start another iteration in the editing loop. > >This is a slight change form RFC 5539 but then RFC 6125 did not exist > >back then and so it probably makes sense to align RFC 5539bis with RFC > >6125. > > True. > > > Question: the title and text refer to "X.509", but both RFC 5246 and RFC > 5280 refer to "X.509v3" or "X.509 v3". Does it matter? > RFC 5246 requires X.509v3, I do not think we need to repeat the X.509 certificate version number in the title. Does this fix a real problem? I would say it does not. Does it improve readability? I think not. Do other RFCs use X.509 in the title? I only found RFC 6187, that is 1/41 that have X.509 in the title. Issue closed. /js PS: This revision of RFC 5539 started in October 2011 (!) and the I-D has had an interesting journey (adding PSK, adding call home, adding a config data model, splitting off call home, splitting of the config data model, removing PSK) and I really want to get this RFC 5539 update off my table. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jan 26 23:20:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15CC1B2BA9; Mon, 26 Jan 2015 23:20:00 -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 F-2bN80brkFG; Mon, 26 Jan 2015 23:19:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE781A1BFF; Mon, 26 Jan 2015 23:19:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150127071958.6835.2457.idtracker@ietfa.amsl.com> Date: Mon, 26 Jan 2015 23:19:58 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 07:20:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication Authors : Mohamad Badra Alan Luchuk Juergen Schoenwaelder Filename : draft-ietf-netconf-rfc5539bis-08.txt Pages : 11 Date : 2015-01-26 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-08 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 Mon Jan 26 23:23:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66A31B2BAC for ; Mon, 26 Jan 2015 23:23: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 Pv1vc-52sP68 for ; Mon, 26 Jan 2015 23:23:47 -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 687811B2BA9 for ; Mon, 26 Jan 2015 23:23: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 3AE4BFCD; Tue, 27 Jan 2015 08:23: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 a76NFOcw0-Uh; Tue, 27 Jan 2015 08:23: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; Tue, 27 Jan 2015 08:23:45 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8417E20036; Tue, 27 Jan 2015 08:23:45 +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 SUiDcbBlrTwz; Tue, 27 Jan 2015 08:15:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95A9920035; Tue, 27 Jan 2015 08:23:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 945FE30FD113; Tue, 27 Jan 2015 08:23:43 +0100 (CET) Date: Tue, 27 Jan 2015 08:23:41 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20150127072339.GA76577@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@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: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 07:23:48 -0000 On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF Members, > > we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. > > The document can be found at: > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 > > Please review and send your comments to the WG mailing list by January 19, 2015 EOB PT. > Mehmet and Mahesh, I have posted draft-ietf-netconf-rfc5539bis-08 which I believe addresses the WG last call comments. Please check and if you agree, please produce a document writeup and move the I-D over to the IESG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jan 27 10:14:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F111A1EF4 for ; Tue, 27 Jan 2015 10:13:57 -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 228uSYWn2Ml2 for ; Tue, 27 Jan 2015 10:13:51 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48BA01A88F6 for ; Tue, 27 Jan 2015 10:13:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5198; q=dns/txt; s=iport; t=1422382431; x=1423592031; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jFfGwNC6SVJ/WXIqcMwCixFmFlWtGATGV0I/sZSlrOQ=; b=LwDIXn6Z4qt6LO361QOdwq1gWawsMGIyt/shTowy1Xi0chVnr+VTKyta r6kT6YcpW3GgQpUrBkKxTdy96kk44k7RYKXMu3MnPy5mnOJwkwmaZHBTT Va5pUKVQaL4Tam4RcSfFcVbhz3cBfZIdY2wK2XIPYO8/ACG9syrFOsDeh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnBAAI1cdU/xbLJq1ag1jKWIJPAoFqAQEBAQF9hA0BAQQ4QAEQCw4KCRYPCQMCAQIBRQYNAQcBAYgo1T4BAQEBAQEBAQEBAQEBAQEBAQEBGY8nAQFPB4QpAQSYD4Y0jAgig24+gTyBNwEBAQ X-IronPort-AV: E=Sophos;i="5.09,476,1418083200"; d="scan'208";a="328679951" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 27 Jan 2015 18:13:49 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0RIDmtK014325; Tue, 27 Jan 2015 18:13:49 GMT Message-ID: <54C7D55C.8060503@cisco.com> Date: Tue, 27 Jan 2015 18:13:48 +0000 From: Robert Wilton 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 References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> <54C62DC1.5000507@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2015 18:13:57 -0000 Hi Kent, On 26/01/2015 21:14, Kent Watsen wrote: >> BTW, do you think that a client will need to know whether the timestamp >> applies to the whole datastore, particular subtrees, or individual leaf >> nodes? And if so, does there need to be a mechanism to query this via >> RESTCONF? > Yes! - and this is supported by getting the value for the top-level > {+restconf}/data resource, right? Considering a container with 2 leaves (e.g. an interface with a MTU leaf and admin state leaf). The server is only tracking timestamps at the container and top-level resource, but the client doesn't know this. When a client queries the MTU leaf node, the server would return a timestamp along with the data, but the client wouldn't know whether that timestamp is (i) when that leaf was last changed, or (ii) when any child configuration of the containing interface node had changed, or (iii) when any configuration has changed. I.e. because in this case the timestamp that would be returned with the MTU leaf node would be changed even when only the admin state leaf was changed. Is this an issue - I'm not sure? Unless a client knows what the behaviour of the server is concerning timestamps, then the only information they know for sure is (i) the top-level timestamp associated with the datastore must be correct, (ii) that the timestamp associated with a particular node reports the last possible time that node was updated. > > >> I was also wondering about what the timestamp behaviour would be if a >> node was deleted. Presumably if that node is deleted, then all parent >> containers up to the top of the tree would have their timestamp modified >> accordingly. > Correct, is node's timestamp is updated anytime there is a change in its > subtree, the top-level {+restconf}/data timestamp is updated for every > change. > > >> But what about if a GET "with defaults" is performed on a leaf (that has >> a default value) that previously existed but had been deleted. In this >> case, would you expect the server to return a timestamp of when the >> explicitly configured value was deleted or just return the timestamp of >> the parent container instead? > Good question. I think that the server would maintain metadata for nodes > dependent on its default-handling mode as follows: > > * report-all: maintain timestamp for leaf having a default always, even if > deleted > > * trim: maintain timestamp for leaf having a default only when value > differs from default > > * explicit: maintain timestamp for a leaf having a default only when its > value has been explicitly configured, regardless if the value is the same > as the default or not. > > > For those wondering, the reason why 404 Not Found isn't returned is > because the draft says this: > > If the target of a GET method is a data node > that represents a leaf that has a default value, > and the leaf has not been given a value yet, the > server MUST return the default value that is in > use by the server. > > > >>> That wasn't quite the point that I was attempting to make (or I didn't >> make it very well ;-). >> >> >> >> But you may deem that returning an error is obvious beyond the point of >> needing to be explicitly clarified. > That is the case here, yes. I do really think that text is ostensibly > about successful responses, and that the "Invoke Operation Mode" section > covers what you're looking for. OK. >>>> Perhaps the description of PATCH/POST/PUT could be strengthened to >>>> indicate that it applies to a resource and any child resources? >>> I don't want to add text to each of those sections. Actually, the text >>> in >>> "3. Resources (Page 13)" looks complete to me. Can you check this >>> again? >> It still feels slightly ambiguous to me. In particular, from the text >> I'm not sure whether it is obvious that a container resource includes >> any child containers as well. Nor does the definition of "data node" in >> the Yang spec really clarify. >> >> Perhaps this could be made more clear in the description of a resource, >> although I'm not sure that my description below is a good way to word >> this, perhaps: >> >> 3.5. Data Resource >> >> A data resource represents a YANG data node that is a descendant node >> of a datastore resource. Containers, leafs, list entries and anyxml >> nodes are data resources. A data resource also includes all >> descendent child nodes. > How about this? > > A data resource represents a YANG data node that is a descendant > node of a datastore resource. Each YANG-defined data node can > be uniquely targeted by the request-line of an HTTP operation. > Containers, leafs, list entries and anyxml nodes are data resources. > > The representation maintained for each data resource is the YANG > defined subtree for that node. Hence HTTP operations on a data > resource simultaneously affect the targeted data node and all > its decendents, if any. Yes, that looks good. Thanks, Rob > > > > > > Thanks, > Kent > > > . > From nobody Tue Jan 27 18:10:48 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC89A1ACAD8 for ; Tue, 27 Jan 2015 18:10: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, 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 7emTECmSNDvc for ; Tue, 27 Jan 2015 18:10:40 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060611A9175 for ; Tue, 27 Jan 2015 18:10:39 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.65.19; Wed, 28 Jan 2015 02:10:17 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Wed, 28 Jan 2015 02:09:56 +0000 From: Kent Watsen To: Robert Wilton Thread-Topic: Mail regarding draft-ietf-netconf-restconf Thread-Index: AQHQMZOf3UFpSbYZFkeiqe6KQJQ1GZzCoUAAgABhPID//62MAIAEhLqAgAJEZoCAAUdBAIADJuCAgAR2k4CAAEVXAIABs6MAgAAxN4A= Date: Wed, 28 Jan 2015 02:09:55 +0000 Message-ID: References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> <54C62DC1.5000507@cisco.com> <54C7D55C.8060503@cisco.com> In-Reply-To: <54C7D55C.8060503@cisco.com> 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.241.12] authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB458; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-forefront-prvs: 047001DADA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(377454003)(479174004)(106116001)(2656002)(102836002)(86362001)(99286002)(92566002)(87936001)(230783001)(110136001)(2950100001)(83506001)(2900100001)(19580405001)(19580395003)(93886004)(77156002)(46102003)(66066001)(36756003)(62966003)(122556002)(54356999)(50986999)(76176999)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; 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: 28 Jan 2015 02:09:55.9481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Cc: Netconf Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 02:10:44 -0000 On 1/27/15, 1:13 PM, "Robert Wilton" wrote: >Hi Kent, > >On 26/01/2015 21:14, Kent Watsen wrote: >>> BTW, do you think that a client will need to know whether the timestamp >>> applies to the whole datastore, particular subtrees, or individual leaf >>> nodes? And if so, does there need to be a mechanism to query this via >>> RESTCONF? >> Yes! - and this is supported by getting the value for the top-level >> {+restconf}/data resource, right? >Considering a container with 2 leaves (e.g. an interface with a MTU leaf >and admin state leaf). The server is only tracking timestamps at the >container and top-level resource, but the client doesn't know this. > >When a client queries the MTU leaf node, the server would return a >timestamp along with the data, but the client wouldn't know whether that >timestamp is (i) when that leaf was last changed, or (ii) when any child >configuration of the containing interface node had changed, or (iii) >when any configuration has changed. I.e. because in this case the >timestamp that would be returned with the MTU leaf node would be changed >even when only the admin state leaf was changed. No, the draft says that only config changes affect the timestamp. The admin state leaf (config false) wouldn't affect the timestamp. >Is this an issue - I'm not sure? Unless a client knows what the >behaviour of the server is concerning timestamps, then the only >information they know for sure is (i) the top-level timestamp associated >with the datastore must be correct, (ii) that the timestamp associated >with a particular node reports the last possible time that node was >updated. I'm not sure I see an issue. Can you provide a concrete example? The expectation is that the client will use the timestamps thusly: Request: GET /restconf/data/example:foo/bar Host: example.com Content-Type: application/yang.data+json Response: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:49:30 GMT Server: example-server Content-Type: application/yang.data+json Last-Modified: Mon, 23 Apr 2012 17:49:30 GMT { // some document here } And then to: Request: PATCH /restconf/data/example:foo/bar Host: example.com If-Unmodified-Since Mon, 23 Apr 2012 17:49:30 GMT <---- SAME TIMESTAMP Content-Type: application/yang.data+json { // some new document here } The granularity of the timestamps will matter more the longer the delay between the two interactions. If they're back-to-back, it would matter very little. If separated by minutes or hours, there is a much higher chance of a false-negative when using coarser timestamps, which will lead to the client maybe needing to redo the action, but that's fairly innocuous in the scheme of things. Naturally, this is a tradeoff implementations can play with. Too many timestamps may be expensive, too few may cause unacceptable thrashing. For some devices, a sweet spot may be data-model specific. Thanks, Kent From nobody Wed Jan 28 08:12:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA47D1A008C for ; Wed, 28 Jan 2015 08:12:21 -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 1Teu2iYs78QQ for ; Wed, 28 Jan 2015 08:12:16 -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 D94091A1A59 for ; Wed, 28 Jan 2015 08:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4536; q=dns/txt; s=iport; t=1422461535; x=1423671135; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KcIPfsYjPnk8Ttnd9rz9nyRKy3AwS13AU+ZN3+1LpPE=; b=F03kvcHd56yE/Q1F/26HgtYlUrq4mtePZitupfaCyDcUCfYd5cS9VZ2I nY6iNPFRUzdX5MQJ0Dg8qYBpLPg3XOCmbeyn/8MOGONhb1VPk7mONmwAO T3/2mrJalgKuBGbA7uPz7il0/zkpOGTSL4zDrnpPjo88XeVtT9BygaiVq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DfBAAyCclU/xbLJq1ag1hZxE+FeQKBXQEBAQEBfYQMAQEBAwE4QAEFCwsOBgQJFg8JAwIBAgFFBg0BBQIBAYggCNYKAQEBAQEBAQEBAQEBAQEBAQEBARmPCxwBAU8HhCkBBJI5hVaBFTaEaSGIKoM9IoNuPjGBC4E3AQEB X-IronPort-AV: E=Sophos;i="5.09,481,1418083200"; d="scan'208";a="325832349" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 28 Jan 2015 16:12:12 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0SGCCKV014095; Wed, 28 Jan 2015 16:12:12 GMT Message-ID: <54C90A5C.1080801@cisco.com> Date: Wed, 28 Jan 2015 16:12:12 +0000 From: Robert Wilton 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 References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> <54C62DC1.5000507@cisco.com> <54C7D55C.8060503@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 16:12:21 -0000 Hi Kent, On 28/01/2015 02:09, Kent Watsen wrote: > > On 1/27/15, 1:13 PM, "Robert Wilton" wrote: > >> Hi Kent, >> >> On 26/01/2015 21:14, Kent Watsen wrote: >>>> BTW, do you think that a client will need to know whether the timestamp >>>> applies to the whole datastore, particular subtrees, or individual leaf >>>> nodes? And if so, does there need to be a mechanism to query this via >>>> RESTCONF? >>> Yes! - and this is supported by getting the value for the top-level >>> {+restconf}/data resource, right? >> Considering a container with 2 leaves (e.g. an interface with a MTU leaf >> and admin state leaf). The server is only tracking timestamps at the >> container and top-level resource, but the client doesn't know this. >> >> When a client queries the MTU leaf node, the server would return a >> timestamp along with the data, but the client wouldn't know whether that >> timestamp is (i) when that leaf was last changed, or (ii) when any child >> configuration of the containing interface node had changed, or (iii) >> when any configuration has changed. I.e. because in this case the >> timestamp that would be returned with the MTU leaf node would be changed >> even when only the admin state leaf was changed. > No, the draft says that only config changes affect the timestamp. The > admin state leaf (config false) wouldn't affect the timestamp. Sorry, I hadn't realized that admin state was an oper leaf. If you read my comment substituting "admin state" leaf with interfaces/interface/enabled leaf" then that may clarify what I was trying to indicate. >> Is this an issue - I'm not sure? Unless a client knows what the >> behaviour of the server is concerning timestamps, then the only >> information they know for sure is (i) the top-level timestamp associated >> with the datastore must be correct, (ii) that the timestamp associated >> with a particular node reports the last possible time that node was >> updated. > I'm not sure I see an issue. Can you provide a concrete example? The I think that for your example below, the timestamps make complete sense. I guess that I was thinking of a timestamp outside the context of this particular use case, i.e. basically just some meta data associated with an item of configuration that could potentially be useful for other reasons such as system triage/monitoring. Although given that you only get a timestamp for the top resource node that is returned it may not be so useful anyway. Would it be worth explicitly stating that the timestamp associated with a non root response returns the timestamp of when that node *may* have been last modified, and not necessarily the time when it *was* last modified? Otherwise clients may incorrectly infer that the timestamp returned is when it was last modified due to field name in the HTTP response. I.e. to prevent clients from trying to use this timestamp for a purpose that it isn't necessarily appropriate for. Thanks, Rob > expectation is that the client will use the timestamps thusly: > > Request: > GET /restconf/data/example:foo/bar > Host: example.com > Content-Type: application/yang.data+json > > > Response: > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:49:30 GMT > Server: example-server > Content-Type: application/yang.data+json > > Last-Modified: Mon, 23 Apr 2012 17:49:30 GMT > { > // some document here > } > > > And then to: > > Request: > PATCH /restconf/data/example:foo/bar > Host: example.com > If-Unmodified-Since Mon, 23 Apr 2012 17:49:30 GMT <---- SAME > TIMESTAMP > Content-Type: application/yang.data+json > > { > // some new document here > } > > > > > > The granularity of the timestamps will matter more the longer the delay > between the two interactions. If they're back-to-back, it would matter > very little. If separated by minutes or hours, there is a much higher > chance of a false-negative when using coarser timestamps, which will lead > to the client maybe needing to redo the action, but that's fairly > innocuous in the scheme of things. > > Naturally, this is a tradeoff implementations can play with. Too many > timestamps may be expensive, too few may cause unacceptable thrashing. > For some devices, a sweet spot may be data-model specific. > > Thanks, > Kent > > > . > From nobody Wed Jan 28 13:45:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8C11A012D for ; Wed, 28 Jan 2015 13:45:08 -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 hu6qZLzGUDb0 for ; Wed, 28 Jan 2015 13:45:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::701]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B7B1A0385 for ; Wed, 28 Jan 2015 13:45:05 -0800 (PST) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB523.namprd05.prod.outlook.com (10.141.72.18) with Microsoft SMTP Server (TLS) id 15.1.65.19; Wed, 28 Jan 2015 21:44:43 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.65.19; Wed, 28 Jan 2015 21:44:41 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Wed, 28 Jan 2015 21:44:41 +0000 From: Kent Watsen To: Robert Wilton Thread-Topic: Mail regarding draft-ietf-netconf-restconf Thread-Index: AQHQMZOf3UFpSbYZFkeiqe6KQJQ1GZzCoUAAgABhPID//62MAIAEhLqAgAJEZoCAAUdBAIADJuCAgAR2k4CAAEVXAIABs6MAgAAxN4CAAT8kAIAACRIA Date: Wed, 28 Jan 2015 21:44:41 +0000 Message-ID: References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> <54C62DC1.5000507@cisco.com> <54C7D55C.8060503@cisco.com> <54C90A5C.1080801@cisco.com> In-Reply-To: <54C90A5C.1080801@cisco.com> 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.241.17] authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:CO1PR05MB457; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 047001DADA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(76104003)(230783001)(93886004)(46102003)(106116001)(92566002)(110136001)(36756003)(87936001)(86362001)(122556002)(54356999)(50986999)(99286002)(2656002)(40100003)(76176999)(83506001)(102836002)(77156002)(62966003)(66066001)(2900100001)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <738826BC00A448439AB55085003CEE5C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2015 21:44:41.3581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB523; X-OriginatorOrg: juniper.net Archived-At: Cc: Netconf Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 21:45:08 -0000 Hi Robert, >Would it be worth explicitly stating that the timestamp associated with >a non root response returns the timestamp of when that node *may* have >been last modified, and not necessarily the time when it *was* last >modified? Otherwise clients may incorrectly infer that the timestamp >returned is when it was last modified due to field name in the HTTP >response. I.e. to prevent clients from trying to use this timestamp for >a purpose that it isn't necessarily appropriate for. The current text essentially says this already, at least I don't think it can be interpreted any other way. For what it's worth, I prefer the draft specify server-behavior more than perceived client behavior. I also reread RFC 7232 section 2.2 and am comfortable that we're not misusing the Last-Modified field in any way. It seems that what you're looking for might be better handled in the server's API documentation, which could identify the specific nodes for which it maintains timestamps. Perhaps RESTCONF could define a special header (e.g., X-Last-Modified-Degrees[-Of-Separation], 0=3D=3Dexact, 1=3D=3Dparent, 2=3Dgrandparent, etc.) but, as an API-consumer, I'd rather h= ave a doc tell me where the timestamps are maintained rather than have to iterate over the API to map it out. What do you think? Thanks, Kent From nobody Wed Jan 28 15:11:33 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48D91A1BFC for ; Wed, 28 Jan 2015 15:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 wtnP_WJH_dzE for ; Wed, 28 Jan 2015 15:11:03 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB711A1C05 for ; Wed, 28 Jan 2015 15:10:34 -0800 (PST) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.1.65.19; Wed, 28 Jan 2015 23:10:32 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Wed, 28 Jan 2015 23:10:32 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: server-model #27 Thread-Index: AQHQO0+d3ZBZI0NNW0e+iPkj8smMmA== Date: Wed, 28 Jan 2015 23:10:31 +0000 Message-ID: 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.241.12] authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO1PR05MB459; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 047001DADA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(107886001)(46102003)(110136001)(99286002)(66066001)(36756003)(92566002)(2351001)(19580395003)(229853001)(558084003)(102836002)(16236675004)(106116001)(86362001)(77156002)(83506001)(87936001)(2656002)(62966003)(15975445007)(450100001)(2501002)(40100003)(2900100001)(122556002)(50986999)(54356999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0EED697937F3kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2015 23:10:31.9909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB459 Archived-At: Subject: [Netconf] server-model #27 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 23:11:09 -0000 --_000_D0EED697937F3kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This issue is now considered verified and has moved to the EDIT state. Link: https://github.com/netconf-wg/server-model/issues/27 --_000_D0EED697937F3kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

This issue is now considered verified and has moved to the EDIT state.

Link: https://github.com/netconf-wg/= server-model/issues/27



--_000_D0EED697937F3kwatsenjunipernet_-- From nobody Wed Jan 28 17:44:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1771A8ABD for ; Wed, 28 Jan 2015 17:44:56 -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 Akl5Ee0c-MhQ for ; Wed, 28 Jan 2015 17:44:54 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115B51A8ABB for ; Wed, 28 Jan 2015 17:44:53 -0800 (PST) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB537.namprd05.prod.outlook.com (10.141.73.16) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 01:44:31 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.1.65.19; Thu, 29 Jan 2015 01:44:30 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.107]) with mapi id 15.01.0065.013; Thu, 29 Jan 2015 01:44:30 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] server-model #27 Thread-Index: AQHQO2Ufi7gpF7qmMkWgumnhO2deTw== Date: Thu, 29 Jan 2015 01:44:29 +0000 Message-ID: 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.241.12] authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:CO1PR05MB457; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB457; x-forefront-prvs: 0471B73328 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(107886001)(2351001)(46102003)(106116001)(92566002)(110136001)(36756003)(86362001)(87936001)(122556002)(575784001)(50986999)(54356999)(2501002)(99286002)(83506001)(40100003)(2656002)(19617315012)(102836002)(15975445007)(16236675004)(450100001)(77156002)(62966003)(19580405001)(19580395003)(2900100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D0EEDCB5937FAkwatsenjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2015 01:44:29.5687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB457 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB537; X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [Netconf] server-model #27 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 01:44:56 -0000 --_000_D0EEDCB5937FAkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The edit for this issue is checked in. The diff is here: https://github.com/netconf-wg/server-model/commit/fb0f020ceaed467fa51a00bfd= f1a9cc4ff57c023 The issue has hence moved to the REVIEW state, pending the next version of = the draft (-06) being posted and reviewed. Thanks, Kent From: Kent Watsen > Date: Wednesday, January 28, 2015 at 6:10 PM To: "netconf@ietf.org" > Subject: [Netconf] server-model #27 This issue is now considered verified and has moved to the EDIT state. Link: https://github.com/netconf-wg/server-model/issues/27 --_000_D0EEDCB5937FAkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

The edit for this issue is checked in.  The diff is here:


The issue has hence moved to = the REVIEW state, pending the next version of the draft (-06) being posted = and reviewed.

Thanks,
Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Wednesday, January 28, 2015 a= t 6:10 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] server-model #27=


This issue is now considered verified and has moved to the EDIT state.



--_000_D0EEDCB5937FAkwatsenjunipernet_-- From nobody Thu Jan 29 07:54:04 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8911A1A87 for ; Thu, 29 Jan 2015 07:54: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 pSdTPyqTEida for ; Thu, 29 Jan 2015 07:54:02 -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 EC99D1A1A0F for ; Thu, 29 Jan 2015 07:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2288; q=dns/txt; s=iport; t=1422546842; x=1423756442; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OWUOpBdi36N1kC4txFw8IEtnSgVlkZimPBlO0CAfSOA=; b=SiwMP0HNM3exnFZ0io+y9DkooU0iLBMOnwsTWU9WFtkDu2n91PfgTVwB 8aJ/w+5NMHWTUec06DboBQ9f6xoal6Np0XG4lcB+Jot7Yx7Yo5ddomN6F 0fqzuN3npjShpvvqbJ1KtkQ4jJntUYmNs3u2rK1tx+erG3zn6srL8uVfX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CoBABQV8pU/xbLJq1QCoNYyFeCTwKBZAEBAQEBfYQMAQEBAwE4PAQBEAsOCgkWDwkDAgECAUUGDQEHAQGIIAjXVwEBAQEBAQEBAQEBAQEBAQEBARqPHAsBAU8HhCkBBJgWgReFISGIMIM9IoNuPoE8gTcBAQE X-IronPort-AV: E=Sophos;i="5.09,486,1418083200"; d="scan'208";a="331841262" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 29 Jan 2015 15:54:00 +0000 Received: from [10.63.23.119] (dhcp-ensft1-uk-vla370-10-63-23-119.cisco.com [10.63.23.119]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0TFs0MS010901; Thu, 29 Jan 2015 15:54:00 GMT Message-ID: <54CA5797.5070009@cisco.com> Date: Thu, 29 Jan 2015 15:53:59 +0000 From: Robert Wilton 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 References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> <54C62DC1.5000507@cisco.com> <54C7D55C.8060503@cisco.com> <54C90A5C.1080801@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 15:54:04 -0000 Hi Kent, On 28/01/2015 21:44, Kent Watsen wrote: > Hi Robert, > >> Would it be worth explicitly stating that the timestamp associated with >> a non root response returns the timestamp of when that node *may* have >> been last modified, and not necessarily the time when it *was* last >> modified? Otherwise clients may incorrectly infer that the timestamp >> returned is when it was last modified due to field name in the HTTP >> response. I.e. to prevent clients from trying to use this timestamp for >> a purpose that it isn't necessarily appropriate for. > The current text essentially says this already, at least I don't think it > can be interpreted any other way. For what it's worth, I prefer the draft > specify server-behavior more than perceived client behavior. I also > reread RFC 7232 section 2.2 and am comfortable that we're not misusing the > Last-Modified field in any way. Yes, having read the text for RFC 7232 I agree. > > It seems that what you're looking for might be better handled in the > server's API documentation, which could identify the specific nodes for > which it maintains timestamps. Perhaps RESTCONF could define a special > header (e.g., X-Last-Modified-Degrees[-Of-Separation], 0==exact, > 1==parent, 2=grandparent, etc.) but, as an API-consumer, I'd rather have a > doc tell me where the timestamps are maintained rather than have to > iterate over the API to map it out. > > What do you think? I think that in the cases where the client knows exactly which server implementations you are interacting with then you are right, this could easily be covered by server API documentation. But in the case that you have a general client that doesn't have the foreknowledge of which server implementations it will be expected to interact with then it can only rely on what is in the specification. However, I agree with you that defining an extra header would seem to be overkill at this stage, and that could easily be added as an extension to the specification in future if there was a specific requirement for it. On that note, I think that concludes my comments/feedback! Thanks for your patience on clarifying particular points. Thanks, Rob > > Thanks, > Kent > > > > > > From nobody Thu Jan 29 08:25:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F141A8ACC for ; Thu, 29 Jan 2015 08:25: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 EPbFt_IWU8im for ; Thu, 29 Jan 2015 08:25:32 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4167B1A896B for ; Thu, 29 Jan 2015 08:25:32 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id l4so29888988lbv.13 for ; Thu, 29 Jan 2015 08:25: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=xV7GIgd9RE0PY0+gMDiOM+raDxPZ2C3XRgY+4qLWuxI=; b=E4ePa7J7k3Z43j70/Fki156/xKp30KvEV3Oa7lBoiTWIRZAaDBOSACAQ/Hi7BV1+Gq nHlFctu3nphZAiyBPd4zYkHoLeYGR/mi49zCfG72D3YkM+F29fnacbvQ6GrK9St3Ke5L 0LKJC7tetFRUBMTMDFzT4fOB/Qfo54l4AO9rlt3mKcJNsDEFYxzHpA7OvV6+NKP7Tmsl foHc6n9qBW17HMg6Ba6e1xSMd8EFB31By1wh8hZL5ocLZNi+hALm0b1wpN2IKTmFF3l2 44H3QJ0tnCBYcHG9nbZ8eIdmhpHJ003AUmw23E1dryCxChY9Lvc58JeHsfYT4hDaG/NN Nz6w== X-Gm-Message-State: ALoCoQmYWNfYGTv3No83sOsvUWap3Fjzn+CReL3Tr1b0fTQAZxAg3UJI52DQFMFDGDdB7wUOM99f MIME-Version: 1.0 X-Received: by 10.152.22.67 with SMTP id b3mr1878597laf.82.1422548730531; Thu, 29 Jan 2015 08:25:30 -0800 (PST) Received: by 10.112.78.3 with HTTP; Thu, 29 Jan 2015 08:25:30 -0800 (PST) In-Reply-To: <54CA5797.5070009@cisco.com> References: <54B9177A.30503@cisco.com> <54B94BE1.6000103@cisco.com> <54BCD10B.1070408@cisco.com> <54BFCA70.3060909@cisco.com> <54C62DC1.5000507@cisco.com> <54C7D55C.8060503@cisco.com> <54C90A5C.1080801@cisco.com> <54CA5797.5070009@cisco.com> Date: Thu, 29 Jan 2015 08:25:30 -0800 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] Mail regarding draft-ietf-netconf-restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 16:25:34 -0000 On Thu, Jan 29, 2015 at 7:53 AM, Robert Wilton wrote: > Hi Kent, > > On 28/01/2015 21:44, Kent Watsen wrote: >> >> Hi Robert, >> >>> Would it be worth explicitly stating that the timestamp associated with >>> a non root response returns the timestamp of when that node *may* have >>> been last modified, and not necessarily the time when it *was* last >>> modified? Otherwise clients may incorrectly infer that the timestamp >>> returned is when it was last modified due to field name in the HTTP >>> response. I.e. to prevent clients from trying to use this timestamp for >>> a purpose that it isn't necessarily appropriate for. >> >> The current text essentially says this already, at least I don't think it >> can be interpreted any other way. For what it's worth, I prefer the draft >> specify server-behavior more than perceived client behavior. I also >> reread RFC 7232 section 2.2 and am comfortable that we're not misusing the >> Last-Modified field in any way. > > Yes, having read the text for RFC 7232 I agree. > >> >> It seems that what you're looking for might be better handled in the >> server's API documentation, which could identify the specific nodes for >> which it maintains timestamps. Perhaps RESTCONF could define a special >> header (e.g., X-Last-Modified-Degrees[-Of-Separation], 0==exact, >> 1==parent, 2=grandparent, etc.) but, as an API-consumer, I'd rather have a >> doc tell me where the timestamps are maintained rather than have to >> iterate over the API to map it out. >> >> What do you think? > > I think that in the cases where the client knows exactly which server > implementations you are interacting with then you are right, this could > easily be covered by server API documentation. > > But in the case that you have a general client that doesn't have the > foreknowledge of which server implementations it will be expected to > interact with then it can only rely on what is in the specification. > > However, I agree with you that defining an extra header would seem to be > overkill at this stage, and that could easily be added as an extension to > the specification in future if there was a specific requirement for it. > I proposed a mechanism in NETCONF-EX called that supports an identityref-based registry of metadata, and a way for the client to ask for specific data to be returned. The server would only add 'last-modified' attributes to those nodes where they are actually kept, so the client could discover exactly what the server supported. RESTCONF can have query parameters defined at any time, so a 'with-metadata=foo,bar,baz' type of parameter could be defined for GET in the future. > On that note, I think that concludes my comments/feedback! Thanks for your > patience on clarifying particular points. > > Thanks, > Rob > Andy > >> >> Thanks, >> Kent >> >> >> >> >> >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Jan 29 09:41:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C14B1A1B1E; Thu, 29 Jan 2015 09:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a4EoLRRHn123; Thu, 29 Jan 2015 09:41:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A21A1B2D; Thu, 29 Jan 2015 09:41:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129174151.7839.56754.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 09:41:51 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] NETCONF WG Virtual Interim Meetings CANCELED X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 17:41:52 -0000 Please note that the previously-announced Network Configuration (netconf) Working Group virtual interim meeting scheduled for February 2, February 16, March 2, and March 16 have been canceled. A new meeting series with a new cycle may be established at a later date. On Dec 1, 2014, at 1:05 PM, IESG Secretary wrote: > The NETCONF WG will hold a series of virtual interim meetings > beginning Monday, December 15, 2014. > > Meeting day: Mondays > Time: 1800 CET > Duration: 2 hours > > Dates: December 15, 2014 1-time > and starting with: January 5, 2015 bi-weekly > End date: March 16, 2015 > > WebEx information: From nobody Fri Jan 30 06:17:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C501A89E0 for ; Fri, 30 Jan 2015 06:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.501 X-Spam-Level: X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, 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 YJzVhmp_0Y-A for ; Fri, 30 Jan 2015 06:17:47 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 DD8511A03AA for ; Fri, 30 Jan 2015 06:17:46 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.4/8.14.4) with ESMTP id t0UEHi0D019503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Jan 2015 14:17:45 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0UEHirY013877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 30 Jan 2015 15:17:44 +0100 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 30 Jan 2015 15:17:44 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.134]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 15:17:43 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 Thread-Index: AQHQOgIs3ej42u9JdUuSCY7KpfRWpJzV+FfQgAKyeJCAAA8WgA== Date: Fri, 30 Jan 2015 14:17:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1748 X-purgate-ID: 151667::1422627465-000067C4-6E1AA0E6/0/0 Archived-At: Subject: [Netconf] FW: WG Last Call for draft-ietf-netconf-rfc5539bis-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 14:17:49 -0000 Dear NETCONF WG, we think the WGLC of the draft-ietf-netconf-rfc5539bis was successful=20 with useful comments and discussion. Based on the WGLC result Juergen=20 provided draft-ietf-netconf-rfc5539bis-08. See http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-08=20 http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-08.txt=20 Please look at v08 of the draft and let the co-chairs know by February 4,=20 2015 EOB PT, whether you have any objections to starting the publications=20 process and asking our AD Benoit Claise to do his review. Best Regards, Mehmet and Mahesh -----Original Message----- From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d= e]=20 Sent: Tuesday, January 27, 2015 8:24 AM To: Ersue, Mehmet (NSN - DE/Munich) Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call for draft-ietf-netconf-rfc5539bis-07 On Mon, Jan 05, 2015 at 08:46:09PM +0000, Ersue, Mehmet (NSN - DE/Munich) w= rote: > Dear NETCONF Members, >=20 > we hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-07. >=20 > The document can be found at: > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-07 >=20 > Please review and send your comments to the WG mailing list by January 19= , 2015 EOB PT. > Mehmet and Mahesh, I have posted draft-ietf-netconf-rfc5539bis-08 which I believe addresses the WG last call comments. Please check and if you agree, please produce a document writeup and move the I-D over to the IESG. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Jan 30 10:56:16 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33C61A1A76 for ; Fri, 30 Jan 2015 10:56:14 -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 UoPqbuVeDCwq for ; Fri, 30 Jan 2015 10:56:13 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF2D1A1A68 for ; Fri, 30 Jan 2015 10:56:12 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id 10so37868565lbg.6 for ; Fri, 30 Jan 2015 10:56: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:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=/+tnq8j6xtY+gKbMGyFreXZEMppaH27JnQywSpfqHLI=; b=coa4EjJY3ugH16vEu3QSHNRfzj6e72qeqUHgXIUkdsOfSo26i5WW6tXjRpFm7UYsJy oiuI7v5BPBmnj4yrzzfiFxwIXE6MoDiS823vqe4ozf4Dp7baTe1a86psnXW5XYapbh9x 1S93pm737lVaT3vI0g+sVS6xTnjHc2+NItzTJVSCTmvqgJqO1HWBnX3NlCtYdBr7W1DM J4PcOlhE7oT2obufiHtl9PCu4jrJINqHRE9+OF/4dBZjCshIZ1Ltxe4ec1466wdZSfEQ 7UfXVhMCF8zThPcQns0eg/fOu/Ye+syvyZSrN1tWOUbtojodk0Ly33O8S3sTilDZC5N4 0AsQ== X-Gm-Message-State: ALoCoQlB2ELW/1Q+2ArQI5DVfSzJTK1BGqd20p5GVoKGJFOLbZSgLHHLeHCNBmBpV4B3MdnDZ9Sl MIME-Version: 1.0 X-Received: by 10.152.204.40 with SMTP id kv8mr8236800lac.42.1422644171116; Fri, 30 Jan 2015 10:56:11 -0800 (PST) Received: by 10.112.78.3 with HTTP; Fri, 30 Jan 2015 10:56:11 -0800 (PST) In-Reply-To: References: Date: Fri, 30 Jan 2015 10:56:11 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Netconf] RESTCONF #13: move ietf-yang-library to new module X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 18:56:15 -0000 No comments or objections have been posted on this issue so it is considered "verified" and is now in the "edit" state. Andy On Sun, Jan 25, 2015 at 11:24 AM, Andy Bierman wrote: > Hi, > > Several people have stated that the ietf-yang-library module > should be in its own draft, because it is not RESTCONF-specific. > > Unless there are any objections by Friday, January 30th, > a new draft will be created containing just the ietf-yang-library > module. There will be a normative reference from RESTCONF > to this new draft. > > > Andy From nobody Fri Jan 30 17:29:32 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EB31A87F1; Fri, 30 Jan 2015 17:29: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 mGboDRU2Ua4a; Fri, 30 Jan 2015 17:29:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 794581A87F2; Fri, 30 Jan 2015 17:29:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150131012925.349.22103.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 17:29:25 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 01:29:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-04.txt Pages : 100 Date : 2015-01-30 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-04 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 Jan 30 17:32:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F251A882E; Fri, 30 Jan 2015 17:32: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 q_0wZ4evV0x7; Fri, 30 Jan 2015 17:32:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2337E1A8830; Fri, 30 Jan 2015 17:32:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150131013221.349.22369.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 17:32:21 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 01:32:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-patch-03.txt Pages : 29 Date : 2015-01-30 Abstract: This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-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 Fri Jan 30 20:33:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A251C1A8879; Fri, 30 Jan 2015 20:33:20 -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 tiW916w2XNly; Fri, 30 Jan 2015 20:33:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E241A8868; Fri, 30 Jan 2015 20:33:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150131043319.21445.85982.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 20:33:19 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-collection-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 04:33:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : RESTCONF Collection Resource Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-collection-00.txt Pages : 17 Date : 2015-01-30 Abstract: This document describes a collection resource for the RESTCONF protocol to provide enhanced filtering features for the retrieval of data nodes with the GET method. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-collection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-collection-00 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 Jan 30 20:33:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043C71A8876; Fri, 30 Jan 2015 20:33:56 -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 l11hf4rue8Us; Fri, 30 Jan 2015 20:33:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A641A8881; Fri, 30 Jan 2015 20:33:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150131043354.17295.24489.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 20:33:54 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-library-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 04:33:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Module Library Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-library-00.txt Pages : 10 Date : 2015-01-30 Abstract: This document describes a YANG library, which provides information about all the YANG modules used by a device to represent management and protocol information. A YANG library can be shared by multiple protocols within the same device. Simple caching mechanisms are needed to allow clients to minimize retrieval of this information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-library/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-yang-library-00 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 Sat Jan 31 07:05:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5131A038D for ; Sat, 31 Jan 2015 07:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Vzs-4FyNxbhx for ; Sat, 31 Jan 2015 07:05:29 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 8AF551A0389 for ; Sat, 31 Jan 2015 07:05:28 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.4/8.14.4) with ESMTP id t0VF5P9s001352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 31 Jan 2015 15:05:26 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t0VF5NXi003095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 31 Jan 2015 16:05:25 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 31 Jan 2015 16:05:23 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0224.002; Sat, 31 Jan 2015 16:05:23 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Restconf-04 and YANG-Patch-03 drafts available Thread-Index: AdA9Z1V9LrIizW9/SFC3DbYz1F9geA== Date: Sat, 31 Jan 2015 15:05:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.114] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819604E8FDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3114 X-purgate-ID: 151667::1422716726-000067C4-608E3BFA/0/0 Archived-At: Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 15:05:35 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819604E8FDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, 1 YANG patch and 9 Restconf issues have been solved and provided in the dra= fts below. These issues have been set to the status Review (https://github.com/netconf= -wg/restconf/issues). Please check and comment on the drafts below before we go to WGLC soon: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F819604E8FDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
1 YANG patch and 9 Restconf issues have been solved and provided in th= e drafts below.
These issues have been set to the status Review (https://github= .com/netconf-wg/restconf/issues).
 
Please check and comment on the drafts below before we go to WGLC soon= :
 
Regards,
Mehmet
 
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F819604E8FDEMUMBX005nsnin_--