From nobody Thu May 1 03:05:11 2014 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 1DB961A076B for ; Thu, 1 May 2014 03:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLIzdeCNOq8t for ; Thu, 1 May 2014 03:04:37 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE7E1A07C9 for ; Thu, 1 May 2014 03:04:36 -0700 (PDT) Received: from AMXPRD0111HT004.eurprd01.prod.exchangelabs.com (157.56.250.117) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.934.12; Thu, 1 May 2014 10:04:33 +0000 Message-ID: <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> From: t.petch To: t.petch , "Bert Wijnen (IETF)" , Kent Watsen References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> Date: Thu, 1 May 2014 10:58:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: AM3PR07CA0030.eurprd07.prod.outlook.com (10.141.45.158) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Forefront-PRVS: 01986AE76B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(479174003)(377454003)(199002)(189002)(13464003)(43784003)(51444003)(35774003)(51704005)(24454002)(53474002)(41574002)(44716002)(92566001)(62236002)(92726001)(86362001)(79102001)(93916002)(20776003)(47776003)(50226001)(44736004)(1941001)(74502001)(50466002)(31966008)(74662001)(84392001)(19580395003)(15975445006)(83322001)(19580405001)(88136002)(87286001)(87976001)(80976001)(81816999)(89996001)(81686999)(50986999)(76176999)(85852003)(83072002)(101416001)(99396002)(77156001)(61296002)(66066001)(23756003)(46102001)(33646001)(14496001)(62966002)(4396001)(77982001)(76482001)(81342001)(42186004)(81542001)(80022001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB052; H:AMXPRD0111HT004.eurprd01.prod.exchangelabs.com; FPR:; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6VGo3apvQTmgubqhEjIE5lxEkDw Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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, 01 May 2014 10:04:40 -0000 Kent I commented earlier that I was uncertain about s.5 of reverse-ssh. I think that it has not got public key use (SSH host key) quite right. If I were asked to describe the use of public keys, then I would identify three steps. 1) get hold of a public key 2) verify that the key is tied to the identity of the other party 3) get the other party to demonstrate possession of the private key At that level, it is irrelevant where the key comes from, X.509 certificate, pre-configuration, Trust On First Use, etc. What varies is step 2). I can see no difference between the use of certificates with ssh and with TLS. And I think that certificates are naturally associated with TLS, and so the place to describe that is in 5539bis. In which case, I would omit any description of it from the ssh I-D and just put in a reference to 5539bis I-D. Currently, reverse-ssh does have some suggestions that are not in 5539bis but then they seem to me equally appropriate to the use of certificates with TLS and so I think that they should be in 5539bis. By contrast, other ways of verifying the key are more associated with ssh, in which case, they belong in reverse-ssh and 5539bis may then want to reference this I-D. I would be willing to expand this into replacement text if this suggestion meets with approval. Tom Petch ----- Original Message ----- From: "t.petch" To: "Bert Wijnen (IETF)" ; "Kent Watsen" Cc: Sent: Tuesday, April 08, 2014 2:44 PM Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt > I do not think that this is ready to advance. I had not intended to > comment but having started on netconf-server, and found I had to read > 5539bis to understand where it was going, I then found that reverse-ssh > was another piece of the jigsaw. > > In particular, I think that this I-D is more or less updating RFC4742 in > its considerations of security. And I think it may be confused about > public keys and certificates and their role in authentication. > > Taken together, and I do not think they can be considered separately, I > do not think that the three I-Ds give a coherent view of how to secure a > NETCONF session. > > I would point to the queries raised by Tadek and Bajpai which, to me on > the one hand seem spot on and on the other, seem to regard the subject > material of these three I-Ds as of a one - which I obviously agree with. > > I think that netconf-server is the one in most need of progress and see > it as a Normative, not Informative, prerequisite. > > Tom Petch > > > ----- Original Message ----- > From: "Bert Wijnen (IETF)" > To: "Kent Watsen" > Cc: > Sent: Thursday, April 03, 2014 12:36 PM > > > WGLC period ended last Tuesday (April 1st). > > > > Kent, where are we with this one? > > > > Do you expect to post a rev 04 that addresses all comments we have > received? > > Either WGLC comments or other comments? Once that is done, I would > like to ask: > > - Kent to post which comments have not been addressed and why (if any) > > - If possible, Kent to post a summary of changes (although that may > already be > > in the document, and that is fine too). > > - All those that made comments to check if they are OK with the way > that > > they have been addressed or responded to. > > > > Bert > > > > On 27/03/14 17:02, Kent Watsen wrote: > > > > > > Hi Alan, > > > > > > > > > Awesome comments - thanks! > > > > > > > > > I applied all fixes mentioned below to my working copy of what will > be > > > -04, so you'll have to wait until then to see the diff. The reason > I'm > > > not posting -04 now is because I'm still trying to work out an issue > with > > > Applicability Statement and with the port's name. > > > > > > Below are my detailed responses. > > > > > > Cheers, > > > Kent > > > > > > > > > > > > > > > > > > > > > > > >> Typos > > >> ----- > > >> > > > > > > I fixed all the issues you found. > > > > > > > > > > > > > > > > > > > > >> Section 2.1, Page 3, Second Paragraph: (wording) > > >> ------------------------------------------------- > > >> > > >> The second paragraph seems vague. Would something along the lines > of > > >> the following text be clearer and/or more specific? > > > > > > I forwarded this comment to Steve Hanna, who wrote the Applicability > > > Statement. At first I was just going to ask if he was OK with the > > > proposed text, but then I started thinking that I didn't agree with > it. > > > That is, I think that the SSH protocol does require mutual > authentication > > > and that NETCONF's requirement that it be possible to derive a > "username" > > > from the transport doesn't change that. I'm still OK limiting > Reverse SSH > > > to just NETCONF, but I want the reason to be accurate. I'm now > waiting > > > for a response from Steve on this. > > > > > > > > > > > > > > > > > > > > > > > >> Section 4, Page 4: (wording) > > >> ----------------------------- > > >> > > >> The current text reads: > > >> > > >> o The NETCONF server initiates a TCP connection to the NETCONF > > >> client on the IANA-assigned Reverse SSH port YYYY. > > >> > > >> o The TCP connection is accepted and a TCP session is > established. > > > > > > > > > I'm not sure about this change since these bullet-points are > preceded by > > > the line "From the NETCONF server's perspective:". The intent is to > only > > > explain the NETCONF-server's perspective, and to let the next > section > > > provide the client's perspective. Currently, neither section > references > > > the remote peer, so that its text remains squarely focused on its > side of > > > the connection. What do you think? > > > > > > > > > > > > > > > > > > > > > > > >> Section 5, Page 5, First Paragraph: (wording) > > >> ---------------------------------------------- > > >> > > >> The current text reads: > > >> > > >> "When the management system accepts a new incoming connection, > it > > >> needs to authenticate the remote peer. Ultimately, this > entails > > >> identifying the peer and verifying its SSH host key. > > >> > > >> Due to Reverse SSH having the network element initiate the TCP > > >> connection," > > > > > > > > > I changed the wording to be more clear, but did it another way, > please let > > > me know if you think it's OK! > > > > > > > > > > > > > > > > > > > > > > > > > > >> Section 5, Page 6, First Paragraph: (clarification) > > >> ---------------------------------------------------- > > >> > > >> The current text reads: > > >> > > >> "However, configuring distinct host keys on the management > system > > >> doesn't scale well, which is an important consideration to a > network > > >> management system. A more scalable strategy is to have the > network > > >> element's host key signed by a common trusted key, such as a > > >> certificate authority. Thus, the mangement system only needs to > > >> trust a single public key, which vouches for the authenticity of > the > > >> various network element public keys." > > >> > > >> Please help me understand this. The way this paragraph is written, > it > > >> is not clear to me why "signing each network element's host key > with a > > >> common trusted key" scales better than "configuring distinct host > keys > > >> on the management system". > > >> > > >> In either of these two situations, it seems like an administrator > must > > >> do work for each network element. In one case, it is configuring > host > > >> keys, in another, it is signing each network element's host key. > If > > >> anything, it seems like signing a host key for each network element > > >> requires _more_ work for each network element, so it seems like > this > > >> would scale less well. > > >> > > >> What am I missing here? > > > > > > > > > Very good question. Of course it comes down to how the device's > "entity > > > certificates", as they are called, is distributed. In the best > case, as > > > described in the zero-touch draft, the device would ship from > factory with > > > a built-in entity-certificate, signed by a trust-chain to its > vendor's > > > well-known trust anchor. In this case, there is no additional > effort > > > needed, the management system only needs to trust the vendor's > certificate > > > for its well-known trust anchor. For cases where the device doesn't > ship > > > from factory with an entity-certificate, introducing PKI is still > > > advantageous as it decouples the management-system from direct > > > involvement, such that it could be outsourced to some 3rd-party. > Makes > > > sense? What update would you like to see in the draft? > > > > > > > > > > > > > > > > > > > > > > > > > > >> Section 7, Page 7, Third Paragraph: (wording) > > >> ---------------------------------------------- > > >> > > >> In a few places in the third paragraph, and possibly in other > places > > >> in the document, would changing "needs to" to lowercase "must", or > > >> lowercase "should", make the document a little more concise? > Example: > > >> > > >> "Note that since the SSH server would have to be configured to > know > > >> which IP address it needs to connect to," > > >> ^^^^^^^^ > > > > > > > > > I changed "needs to" to "is to" for this cited location and another > I > > > found. > > > > > > > > > > > > > > > > > > Thanks again, > > > Kent > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue May 6 00:32:02 2014 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 5A0821A02EF for ; Mon, 5 May 2014 08:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-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 mY7zYZSv8J4j for ; Mon, 5 May 2014 08:21:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B0D531A00B8 for ; Mon, 5 May 2014 08:21:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0327618000D; Mon, 5 May 2014 08:21:17 -0700 (PDT) To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140505152117.0327618000D@rfc-editor.org> Date: Mon, 5 May 2014 08:21:17 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WeEhxLCdnUZGt9O84uj1i1IB1rY X-Mailman-Approved-At: Tue, 06 May 2014 00:32:01 -0700 Cc: rfc-editor@rfc-editor.org, ksekera@cisco.com, netconf@ietf.org Subject: [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: Mon, 05 May 2014 15:21:50 -0000 The following errata report has been submitted 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 -------------------------------------- Type: Technical Reported by: Klement Sekera Section: 6.2.5 Original Text ------------- 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 -------------- o 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. Notes ----- The intent is to allow the server to always include the key node values and the wording accidentally does not cover this case. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- 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 Tue May 6 04:11:50 2014 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 48DD61A07B2 for ; Tue, 6 May 2014 04:11:49 -0700 (PDT) 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_15=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 qaxAqa2l5XYn for ; Tue, 6 May 2014 04:11:46 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id A7C301A02A8 for ; Tue, 6 May 2014 04:11:46 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1WhdHa-00020G-Ul; Tue, 06 May 2014 13:11:42 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest210.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WhdHa-0005gq-SK; Tue, 06 May 2014 13:11:34 +0200 Message-ID: <5368C366.8070509@bwijnen.net> Date: Tue, 06 May 2014 13:11:34 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "t.petch" , Kent Watsen References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> In-Reply-To: <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41173e6d6acc8e3d451bc3c923c7842cf Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/IaXa05ZXY80tsqfABChCgg7lxyQ Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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: Tue, 06 May 2014 11:11:49 -0000 om, is this still an issue with rev 5 of the reverse-ssh document? Bert On 01/05/14 11:58, t.petch wrote: > Kent > > I commented earlier that I was uncertain about s.5 of reverse-ssh. I > think that it has not got public key use (SSH host key) quite right. > > If I were asked to describe the use of public keys, then I would > identify three steps. > > 1) get hold of a public key > 2) verify that the key is tied to the identity of the other party > 3) get the other party to demonstrate possession of the private key > > At that level, it is irrelevant where the key comes from, X.509 > certificate, pre-configuration, Trust On First Use, etc. What varies is > step 2). > > I can see no difference between the use of certificates with ssh and > with TLS. And I think that certificates are naturally associated with > TLS, and so the place to describe that is in 5539bis. In which case, I > would omit any description of it from the ssh I-D and just put in a > reference to 5539bis I-D. Currently, reverse-ssh does have some > suggestions that are not in 5539bis but then they seem to me equally > appropriate to the use of certificates with TLS and so I think that they > should be in 5539bis. > > By contrast, other ways of verifying the key are more associated with > ssh, in which case, they belong in reverse-ssh and 5539bis may then want > to reference this I-D. > > I would be willing to expand this into replacement text if this > suggestion meets with approval. > > Tom Petch > > ----- Original Message ----- > From: "t.petch" > To: "Bert Wijnen (IETF)" ; "Kent Watsen" > > Cc: > Sent: Tuesday, April 08, 2014 2:44 PM > Subject: Re: [Netconf] WG Last Call Comments > ondraft-ietf-netconf-reverse-ssh-03.txt > > >> I do not think that this is ready to advance. I had not intended to >> comment but having started on netconf-server, and found I had to read >> 5539bis to understand where it was going, I then found that > reverse-ssh >> was another piece of the jigsaw. >> >> In particular, I think that this I-D is more or less updating RFC4742 > in >> its considerations of security. And I think it may be confused about >> public keys and certificates and their role in authentication. >> >> Taken together, and I do not think they can be considered separately, > I >> do not think that the three I-Ds give a coherent view of how to secure > a >> NETCONF session. >> >> I would point to the queries raised by Tadek and Bajpai which, to me > on >> the one hand seem spot on and on the other, seem to regard the subject >> material of these three I-Ds as of a one - which I obviously agree > with. >> >> I think that netconf-server is the one in most need of progress and > see >> it as a Normative, not Informative, prerequisite. >> >> Tom Petch >> >> >> ----- Original Message ----- >> From: "Bert Wijnen (IETF)" >> To: "Kent Watsen" >> Cc: >> Sent: Thursday, April 03, 2014 12:36 PM >> >>> WGLC period ended last Tuesday (April 1st). >>> >>> Kent, where are we with this one? >>> >>> Do you expect to post a rev 04 that addresses all comments we have >> received? >>> Either WGLC comments or other comments? Once that is done, I would >> like to ask: >>> - Kent to post which comments have not been addressed and why (if > any) >>> - If possible, Kent to post a summary of changes (although that may >> already be >>> in the document, and that is fine too). >>> - All those that made comments to check if they are OK with the way >> that >>> they have been addressed or responded to. >>> >>> Bert >>> >>> On 27/03/14 17:02, Kent Watsen wrote: >>>> >>>> Hi Alan, >>>> >>>> >>>> Awesome comments - thanks! >>>> >>>> >>>> I applied all fixes mentioned below to my working copy of what > will >> be >>>> -04, so you'll have to wait until then to see the diff. The > reason >> I'm >>>> not posting -04 now is because I'm still trying to work out an > issue >> with >>>> Applicability Statement and with the port's name. >>>> >>>> Below are my detailed responses. >>>> >>>> Cheers, >>>> Kent >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Typos >>>>> ----- >>>>> >>>> >>>> I fixed all the issues you found. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Section 2.1, Page 3, Second Paragraph: (wording) >>>>> ------------------------------------------------- >>>>> >>>>> The second paragraph seems vague. Would something along the > lines >> of >>>>> the following text be clearer and/or more specific? >>>> >>>> I forwarded this comment to Steve Hanna, who wrote the > Applicability >>>> Statement. At first I was just going to ask if he was OK with the >>>> proposed text, but then I started thinking that I didn't agree > with >> it. >>>> That is, I think that the SSH protocol does require mutual >> authentication >>>> and that NETCONF's requirement that it be possible to derive a >> "username" >>>> from the transport doesn't change that. I'm still OK limiting >> Reverse SSH >>>> to just NETCONF, but I want the reason to be accurate. I'm now >> waiting >>>> for a response from Steve on this. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Section 4, Page 4: (wording) >>>>> ----------------------------- >>>>> >>>>> The current text reads: >>>>> >>>>> o The NETCONF server initiates a TCP connection to the > NETCONF >>>>> client on the IANA-assigned Reverse SSH port YYYY. >>>>> >>>>> o The TCP connection is accepted and a TCP session is >> established. >>>> >>>> >>>> I'm not sure about this change since these bullet-points are >> preceded by >>>> the line "From the NETCONF server's perspective:". The intent is > to >> only >>>> explain the NETCONF-server's perspective, and to let the next >> section >>>> provide the client's perspective. Currently, neither section >> references >>>> the remote peer, so that its text remains squarely focused on its >> side of >>>> the connection. What do you think? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Section 5, Page 5, First Paragraph: (wording) >>>>> ---------------------------------------------- >>>>> >>>>> The current text reads: >>>>> >>>>> "When the management system accepts a new incoming connection, >> it >>>>> needs to authenticate the remote peer. Ultimately, this >> entails >>>>> identifying the peer and verifying its SSH host key. >>>>> >>>>> Due to Reverse SSH having the network element initiate the > TCP >>>>> connection," >>>> >>>> >>>> I changed the wording to be more clear, but did it another way, >> please let >>>> me know if you think it's OK! >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Section 5, Page 6, First Paragraph: (clarification) >>>>> ---------------------------------------------------- >>>>> >>>>> The current text reads: >>>>> >>>>> "However, configuring distinct host keys on the management >> system >>>>> doesn't scale well, which is an important consideration to a >> network >>>>> management system. A more scalable strategy is to have the >> network >>>>> element's host key signed by a common trusted key, such as a >>>>> certificate authority. Thus, the mangement system only needs > to >>>>> trust a single public key, which vouches for the authenticity > of >> the >>>>> various network element public keys." >>>>> >>>>> Please help me understand this. The way this paragraph is > written, >> it >>>>> is not clear to me why "signing each network element's host key >> with a >>>>> common trusted key" scales better than "configuring distinct host >> keys >>>>> on the management system". >>>>> >>>>> In either of these two situations, it seems like an administrator >> must >>>>> do work for each network element. In one case, it is configuring >> host >>>>> keys, in another, it is signing each network element's host key. >> If >>>>> anything, it seems like signing a host key for each network > element >>>>> requires _more_ work for each network element, so it seems like >> this >>>>> would scale less well. >>>>> >>>>> What am I missing here? >>>> >>>> >>>> Very good question. Of course it comes down to how the device's >> "entity >>>> certificates", as they are called, is distributed. In the best >> case, as >>>> described in the zero-touch draft, the device would ship from >> factory with >>>> a built-in entity-certificate, signed by a trust-chain to its >> vendor's >>>> well-known trust anchor. In this case, there is no additional >> effort >>>> needed, the management system only needs to trust the vendor's >> certificate >>>> for its well-known trust anchor. For cases where the device > doesn't >> ship >>>> from factory with an entity-certificate, introducing PKI is still >>>> advantageous as it decouples the management-system from direct >>>> involvement, such that it could be outsourced to some 3rd-party. >> Makes >>>> sense? What update would you like to see in the draft? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Section 7, Page 7, Third Paragraph: (wording) >>>>> ---------------------------------------------- >>>>> >>>>> In a few places in the third paragraph, and possibly in other >> places >>>>> in the document, would changing "needs to" to lowercase "must", > or >>>>> lowercase "should", make the document a little more concise? >> Example: >>>>> >>>>> "Note that since the SSH server would have to be configured to >> know >>>>> which IP address it needs to connect to," >>>>> ^^^^^^^^ >>>> >>>> >>>> I changed "needs to" to "is to" for this cited location and > another >> I >>>> found. >>>> >>>> >>>> >>>> >>>> >>>> Thanks again, >>>> Kent >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > From nobody Tue May 6 04:16:56 2014 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 8E2921A01D4 for ; Tue, 6 May 2014 04:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlisPJ2xIDZ4 for ; Tue, 6 May 2014 04:16:54 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9091A01C7 for ; Tue, 6 May 2014 04:16:54 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1WhdMe-0002SL-Fc for netconf@ietf.org; Tue, 06 May 2014 13:16:50 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest210.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WhdMe-0003YJ-D6 for netconf@ietf.org; Tue, 06 May 2014 13:16:48 +0200 Message-ID: <5368C4A0.7040301@bwijnen.net> Date: Tue, 06 May 2014 13:16:48 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Netconf References: <5368C3D4.2060608@bwijnen.net> In-Reply-To: <5368C3D4.2060608@bwijnen.net> X-Forwarded-Message-Id: <5368C3D4.2060608@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47524d495b366258d778e2e1e8c215a6a Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/s98MZ3lzYThjSKHTJACmTNFkbuw Subject: [Netconf] Action: Pls check if your WGLC comment has been addressed : draft-ietf-netconf-reverse-ssh-05.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: Tue, 06 May 2014 11:16:55 -0000 Does this revision address all WG LC comments that were posted? Those who did post any WGLC comments and feel that their concerns have not yet been addressed, pls speak up asap. Bert On 18/04/14 23:38, Kent Watsen wrote: > > This version has two updates: > > - Removed ³vagueness² in second paragraph of the Applicability Statement > reported by Alan Luchuk. This is achieved by adding RFC references > > for key assertions made there. > > - Changed "Reverse SSH" to "Call Home², per the XML Tom Petch sent out. > I made a couple minor tweaks on top of what Tom had. > > In terms of last-call, there only remains the issue of if this draft's > reference to the netconf-server-model draft needs to be normative (not > informative). I donıt think so, but am OK either way. If we think the > reference needs to be normative, then I guess we delay last-call on this > draft (and 5539-bis) until netconf-server-model is also ready - right? > > Thanks, > Kent > > > > > > > > On 4/18/14, 5:18 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 over SSH Call Home >> Author : Kent Watsen >> Filename : draft-ietf-netconf-reverse-ssh-05.txt >> Pages : 10 >> Date : 2014-04-18 >> >> Abstract: >> This document presents a technique for a NETCONF server to initiate a >> SSH connection to a NETCONF client. This is accomplished by the >> NETCONF client listening on IANA-assigned TCP port YYYY and starting >> the SSH client protocol immediately after accepting a TCP connection >> on it. This role-reversal is necessary as the NETCONF server must >> also be the SSH server, in order for the NETCONF client to open the >> IANA-assigned SSH subsystem "netconf". >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-05 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-reverse-ssh-05 >> >> >> 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 >> >> > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue May 6 08:03:17 2014 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 0D8321A035A for ; Tue, 6 May 2014 08:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 yToy4B6No4ZG for ; Tue, 6 May 2014 08:03:13 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 89B221A035B for ; Tue, 6 May 2014 08:03:13 -0700 (PDT) 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 LAA27777; Tue, 6 May 2014 11:03:01 -0400 (EDT) Received: from mainfs.snmp.com (localhost [127.0.0.1]) by mainfs.snmp.com (8.14.5/8.14.5) with ESMTP id s46K6gY1001683; Tue, 6 May 2014 16:06:42 -0400 (EDT) (envelope-from luchuk@mainfs.snmp.com) Received: (from luchuk@localhost) by mainfs.snmp.com (8.14.5/8.14.5/Submit) id s46K6f6t001682; Tue, 6 May 2014 16:06:41 -0400 (EDT) (envelope-from luchuk) Date: Tue, 6 May 2014 16:06:41 -0400 (EDT) From: Alan Luchuk Message-Id: <201405062006.s46K6f6t001682@mainfs.snmp.com> To: bertietf@bwijnen.net, netconf@ietf.org In-Reply-To: <5368C4A0.7040301@bwijnen.net> Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8d-0GvHxHZCAzDhwcQbpOeX-H90 Subject: Re: [Netconf] Action: Pls check if your WGLC comment has been addressed : draft-ietf-netconf-reverse-ssh-05.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: Tue, 06 May 2014 15:03:16 -0000 Hello, >Does this revision address all WG LC comments that were posted? >Those who did post any WGLC comments and feel that their concerns >have not yet been addressed, pls speak up asap. I have read draft-ietf-netconf-reverse-ssh-05.txt, and am satisfied that the issues I noted in draft -04 have been addressed in this latest draft. Regards, --Alan From nobody Wed May 7 02:23:35 2014 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 8E7961A027E for ; Wed, 7 May 2014 02:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 ST2MN_Tg3bzy for ; Wed, 7 May 2014 02:23:29 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0080.outbound.protection.outlook.com [213.199.154.80]) by ietfa.amsl.com (Postfix) with ESMTP id 405571A0278 for ; Wed, 7 May 2014 02:23:29 -0700 (PDT) Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 7 May 2014 09:23:23 +0000 Message-ID: <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> From: t.petch To: "Bert Wijnen (IETF)" , Kent Watsen References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> Date: Wed, 7 May 2014 10:20:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: DBXPR07CA016.eurprd07.prod.outlook.com (10.141.8.174) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) X-Forefront-PRVS: 0204F0BDE2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(43784003)(51444003)(41574002)(24454002)(53474002)(189002)(199002)(51704005)(479174003)(377454003)(35774003)(13464003)(77982001)(92726001)(23756003)(89996001)(19580405001)(61296002)(83322001)(19580395003)(88136002)(42186004)(62966002)(81342001)(81816999)(85852003)(83072002)(76482001)(81686999)(87976001)(86362001)(76176999)(46102001)(93916002)(99396002)(101416001)(87286001)(92566001)(50986999)(50226001)(4396001)(79102001)(84392001)(77156001)(74502001)(74662001)(31966008)(62236002)(20776003)(47776003)(44716002)(80022001)(66066001)(64706001)(50466002)(81542001)(15975445006)(44736004)(14496001)(33646001)(21056001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB053; H:AMXPRD0310HT004.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/DrZg0a74iTnQ26_t3I_sG5Lr0r8 Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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, 07 May 2014 09:23:33 -0000 ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "t.petch" ; "Kent Watsen" Cc: Sent: Tuesday, May 06, 2014 12:11 PM > om, is this still an issue with rev 5 of the reverse-ssh document? Yes The changes I made for -05 were only the one change of terminology, so that if it were to be unacceptable for any reason, then that change could be easily reversed. So, my still outstanding points are - s.5, re-arrange to dovetail better with 5539bis - wordsmith the Abstract/Introduction (as first suggested last November:-) where I think the first reference to 'SSH Connection' is wrong, so make it something like "This memo presents a technique for a NETCONF server to request that a NETCONF client initiates a SSH connection to the NETCONF server, a technique referred to as 'call home'." Tom Petch > > Bert > > On 01/05/14 11:58, t.petch wrote: > > Kent > > > > I commented earlier that I was uncertain about s.5 of reverse-ssh. I > > think that it has not got public key use (SSH host key) quite right. > > > > If I were asked to describe the use of public keys, then I would > > identify three steps. > > > > 1) get hold of a public key > > 2) verify that the key is tied to the identity of the other party > > 3) get the other party to demonstrate possession of the private key > > > > At that level, it is irrelevant where the key comes from, X.509 > > certificate, pre-configuration, Trust On First Use, etc. What varies is > > step 2). > > > > I can see no difference between the use of certificates with ssh and > > with TLS. And I think that certificates are naturally associated with > > TLS, and so the place to describe that is in 5539bis. In which case, I > > would omit any description of it from the ssh I-D and just put in a > > reference to 5539bis I-D. Currently, reverse-ssh does have some > > suggestions that are not in 5539bis but then they seem to me equally > > appropriate to the use of certificates with TLS and so I think that they > > should be in 5539bis. > > > > By contrast, other ways of verifying the key are more associated with > > ssh, in which case, they belong in reverse-ssh and 5539bis may then want > > to reference this I-D. > > > > I would be willing to expand this into replacement text if this > > suggestion meets with approval. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "t.petch" > > To: "Bert Wijnen (IETF)" ; "Kent Watsen" > > > > Cc: > > Sent: Tuesday, April 08, 2014 2:44 PM > > Subject: Re: [Netconf] WG Last Call Comments > > ondraft-ietf-netconf-reverse-ssh-03.txt > > > > > >> I do not think that this is ready to advance. I had not intended to > >> comment but having started on netconf-server, and found I had to read > >> 5539bis to understand where it was going, I then found that > > reverse-ssh > >> was another piece of the jigsaw. > >> > >> In particular, I think that this I-D is more or less updating RFC4742 > > in > >> its considerations of security. And I think it may be confused about > >> public keys and certificates and their role in authentication. > >> > >> Taken together, and I do not think they can be considered separately, > > I > >> do not think that the three I-Ds give a coherent view of how to secure > > a > >> NETCONF session. > >> > >> I would point to the queries raised by Tadek and Bajpai which, to me > > on > >> the one hand seem spot on and on the other, seem to regard the subject > >> material of these three I-Ds as of a one - which I obviously agree > > with. > >> > >> I think that netconf-server is the one in most need of progress and > > see > >> it as a Normative, not Informative, prerequisite. > >> > >> Tom Petch > >> > >> > >> ----- Original Message ----- > >> From: "Bert Wijnen (IETF)" > >> To: "Kent Watsen" > >> Cc: > >> Sent: Thursday, April 03, 2014 12:36 PM > >> > >>> WGLC period ended last Tuesday (April 1st). > >>> > >>> Kent, where are we with this one? > >>> > >>> Do you expect to post a rev 04 that addresses all comments we have > >> received? > >>> Either WGLC comments or other comments? Once that is done, I would > >> like to ask: > >>> - Kent to post which comments have not been addressed and why (if > > any) > >>> - If possible, Kent to post a summary of changes (although that may > >> already be > >>> in the document, and that is fine too). > >>> - All those that made comments to check if they are OK with the way > >> that > >>> they have been addressed or responded to. > >>> > >>> Bert > >>> > >>> On 27/03/14 17:02, Kent Watsen wrote: > >>>> > >>>> Hi Alan, > >>>> > >>>> > >>>> Awesome comments - thanks! > >>>> > >>>> > >>>> I applied all fixes mentioned below to my working copy of what > > will > >> be > >>>> -04, so you'll have to wait until then to see the diff. The > > reason > >> I'm > >>>> not posting -04 now is because I'm still trying to work out an > > issue > >> with > >>>> Applicability Statement and with the port's name. > >>>> > >>>> Below are my detailed responses. > >>>> > >>>> Cheers, > >>>> Kent > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Typos > >>>>> ----- > >>>>> > >>>> > >>>> I fixed all the issues you found. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Section 2.1, Page 3, Second Paragraph: (wording) > >>>>> ------------------------------------------------- > >>>>> > >>>>> The second paragraph seems vague. Would something along the > > lines > >> of > >>>>> the following text be clearer and/or more specific? > >>>> > >>>> I forwarded this comment to Steve Hanna, who wrote the > > Applicability > >>>> Statement. At first I was just going to ask if he was OK with the > >>>> proposed text, but then I started thinking that I didn't agree > > with > >> it. > >>>> That is, I think that the SSH protocol does require mutual > >> authentication > >>>> and that NETCONF's requirement that it be possible to derive a > >> "username" > >>>> from the transport doesn't change that. I'm still OK limiting > >> Reverse SSH > >>>> to just NETCONF, but I want the reason to be accurate. I'm now > >> waiting > >>>> for a response from Steve on this. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Section 4, Page 4: (wording) > >>>>> ----------------------------- > >>>>> > >>>>> The current text reads: > >>>>> > >>>>> o The NETCONF server initiates a TCP connection to the > > NETCONF > >>>>> client on the IANA-assigned Reverse SSH port YYYY. > >>>>> > >>>>> o The TCP connection is accepted and a TCP session is > >> established. > >>>> > >>>> > >>>> I'm not sure about this change since these bullet-points are > >> preceded by > >>>> the line "From the NETCONF server's perspective:". The intent is > > to > >> only > >>>> explain the NETCONF-server's perspective, and to let the next > >> section > >>>> provide the client's perspective. Currently, neither section > >> references > >>>> the remote peer, so that its text remains squarely focused on its > >> side of > >>>> the connection. What do you think? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Section 5, Page 5, First Paragraph: (wording) > >>>>> ---------------------------------------------- > >>>>> > >>>>> The current text reads: > >>>>> > >>>>> "When the management system accepts a new incoming connection, > >> it > >>>>> needs to authenticate the remote peer. Ultimately, this > >> entails > >>>>> identifying the peer and verifying its SSH host key. > >>>>> > >>>>> Due to Reverse SSH having the network element initiate the > > TCP > >>>>> connection," > >>>> > >>>> > >>>> I changed the wording to be more clear, but did it another way, > >> please let > >>>> me know if you think it's OK! > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Section 5, Page 6, First Paragraph: (clarification) > >>>>> ---------------------------------------------------- > >>>>> > >>>>> The current text reads: > >>>>> > >>>>> "However, configuring distinct host keys on the management > >> system > >>>>> doesn't scale well, which is an important consideration to a > >> network > >>>>> management system. A more scalable strategy is to have the > >> network > >>>>> element's host key signed by a common trusted key, such as a > >>>>> certificate authority. Thus, the mangement system only needs > > to > >>>>> trust a single public key, which vouches for the authenticity > > of > >> the > >>>>> various network element public keys." > >>>>> > >>>>> Please help me understand this. The way this paragraph is > > written, > >> it > >>>>> is not clear to me why "signing each network element's host key > >> with a > >>>>> common trusted key" scales better than "configuring distinct host > >> keys > >>>>> on the management system". > >>>>> > >>>>> In either of these two situations, it seems like an administrator > >> must > >>>>> do work for each network element. In one case, it is configuring > >> host > >>>>> keys, in another, it is signing each network element's host key. > >> If > >>>>> anything, it seems like signing a host key for each network > > element > >>>>> requires _more_ work for each network element, so it seems like > >> this > >>>>> would scale less well. > >>>>> > >>>>> What am I missing here? > >>>> > >>>> > >>>> Very good question. Of course it comes down to how the device's > >> "entity > >>>> certificates", as they are called, is distributed. In the best > >> case, as > >>>> described in the zero-touch draft, the device would ship from > >> factory with > >>>> a built-in entity-certificate, signed by a trust-chain to its > >> vendor's > >>>> well-known trust anchor. In this case, there is no additional > >> effort > >>>> needed, the management system only needs to trust the vendor's > >> certificate > >>>> for its well-known trust anchor. For cases where the device > > doesn't > >> ship > >>>> from factory with an entity-certificate, introducing PKI is still > >>>> advantageous as it decouples the management-system from direct > >>>> involvement, such that it could be outsourced to some 3rd-party. > >> Makes > >>>> sense? What update would you like to see in the draft? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> Section 7, Page 7, Third Paragraph: (wording) > >>>>> ---------------------------------------------- > >>>>> > >>>>> In a few places in the third paragraph, and possibly in other > >> places > >>>>> in the document, would changing "needs to" to lowercase "must", > > or > >>>>> lowercase "should", make the document a little more concise? > >> Example: > >>>>> > >>>>> "Note that since the SSH server would have to be configured to > >> know > >>>>> which IP address it needs to connect to," > >>>>> ^^^^^^^^ > >>>> > >>>> > >>>> I changed "needs to" to "is to" for this cited location and > > another > >> I > >>>> found. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Thanks again, > >>>> Kent > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Netconf mailing list > >>>> Netconf@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netconf > >>>> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > > > > From nobody Wed May 7 10:55:09 2014 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 8E04F1A0896 for ; Wed, 7 May 2014 10:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q7KCh8TGuSFR for ; Wed, 7 May 2014 10:55:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1E36A1A07BA for ; Wed, 7 May 2014 10:55:03 -0700 (PDT) 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.0.934.12; Wed, 7 May 2014 17:54:58 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.173]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.173]) with mapi id 15.00.0934.000; Wed, 7 May 2014 17:54:58 +0000 From: Kent Watsen To: t.petch , "Bert Wijnen (IETF)" Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsro1aWgAfuBgCAAXRlEYAAS5QA Date: Wed, 7 May 2014 17:54:57 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> In-Reply-To: <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.14] x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(164054003)(51444003)(51704005)(87936001)(36756003)(101416001)(81542001)(81342001)(21056001)(99396002)(99286001)(2656002)(83322001)(46102001)(76176999)(54356999)(50986999)(64706001)(20776003)(79102001)(83506001)(92566001)(74662001)(83072002)(74502001)(85852003)(77982001)(4396001)(80022001)(76482001)(86362001)(31966008)(66066001)(92726001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bBgTFa2KyhNEhyGBVTfefPW6gQI Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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, 07 May 2014 17:55:06 -0000 Hi Tom, >So, my still outstanding points are > >- s.5, re-arrange to dovetail better with 5539bis My understanding is that you believe that both drafts share the issue of the northbound management application being able to identify and verify the [SSH/TLS] server that uses call-home to connect to it. I agree. And that the text in the reverse-ssh draft, while ostensibly about SSH host keys, could similarly apply to TLS and its use of X.509 certificates. I agree again, there is an overlap. Thus you think that much of the text should be moved to 5539bis and for the reverse-ssh draft to reference it there. I don=B9t agree, for two reasons: 1) if there is a need to define common call-home behavior, we should have a =B3call-home=B2 draft that covers both TLS and SSH call-home together. I recall this being one of the options discussed before, but the WG decided to move ahead with this document structure. In lieu of that, I think that the reverse-ssh draft is closer to being a =B3call-home=B2 draft than 5539b= is, and so suggest putting common call-home information into it, perhaps pulled out into a section called =B3common call-home behavious=B2 - what do you think? 2) The text in the reverse-ssh draft is also much about the use of legacy host-keys versus the new X.509 based keys with SSH. Saying that use of legacy keys is possible and allowed, but fraught with issues that are resolved when using X.509 keys. Maybe this needs to be may clearer, but I don=B9t think the information should be lost. =20 >- wordsmith the Abstract/Introduction (as first suggested last >November:-) where I think the first reference to 'SSH Connection' is >wrong, so make it something like > >"This memo presents a technique for a NETCONF server to request that a >NETCONF client initiates a SSH connection to the NETCONF server, >a technique referred to as 'call home'." I like this text, especially since we switched everything else to "call-home" in -05. I just updated my local copy this this change, but will wait for resolution of the above before putting out -06 Thanks, Kent From nobody Wed May 7 15:16:08 2014 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 7D9B11A03FE for ; Wed, 7 May 2014 15:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 qBaQGxkpv43l for ; Wed, 7 May 2014 15:15:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by ietfa.amsl.com (Postfix) with ESMTP id 584F31A03DD for ; Wed, 7 May 2014 15:15:52 -0700 (PDT) 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.0.934.12; Wed, 7 May 2014 22:15:47 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.173]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.173]) with mapi id 15.00.0934.000; Wed, 7 May 2014 22:15:46 +0000 From: Kent Watsen To: t.petch , "Bert Wijnen (IETF)" Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsro1aWgAfuBgCAAXRlEYAAS5QAgABI34A= Date: Wed, 7 May 2014 22:15:46 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.14] x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51444003)(24454002)(479174003)(199002)(189002)(377454003)(164054003)(51704005)(101416001)(80022001)(76176999)(74502001)(92726001)(85852003)(86362001)(66066001)(21056001)(74662001)(87936001)(20776003)(81342001)(64706001)(2656002)(77982001)(81542001)(99396002)(46102001)(83322001)(54356999)(19580405001)(50986999)(83506001)(4396001)(76482001)(36756003)(83072002)(99286001)(19580395003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="euc-kr" Content-ID: <432D2F63AE1D924EA0B373D82763754E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/68tAY3nEapAAoAmlRTzSLohflQ0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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, 07 May 2014 22:16:04 -0000 DQpIaSBUb20sIA0KDQpObyBuZWVkIHRvIHdhaXQgZm9yIC0wNiwgaGVyZSdzIHRoZSBuZXcgdGV4 dCBmb3IgdGhlIEFic3RyYWN0Og0KDQogICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgdGVjaG5p cXVlIGZvciBhIE5FVENPTkYgc2VydmVyIHRvIHJlcXVlc3QNCiAgIHRoYXQgYSBORVRDT05GIGNs aWVudCBpbml0aWF0ZXMgYSBTU0ggY29ubmVjdGlvbiB0byB0aGUgTkVUQ09ORg0KICAgc2VydmVy LCBhIHRlY2huaXF1ZSByZWZlcnJlZCB0byBhcyAnY2FsbCBob21lJy4gIENhbGwgaG9tZSBpcyBu ZWVkZWQNCiAgIHRvIHN1cHBvcnQgZGVwbG95bWVudHMgd2hlcmUgdGhlIE5FVENPTkYgY2xpZW50 IGlzIG90aGVyd2lzZSB1bmFibGUNCiAgIHRvIGluaXRpYXRlIGEgU1NIIGNvbm5lY3Rpb24gdG8g dGhlIE5FVENPTkYgc2VydmVyIGRpcmVjdGx5Lg0KDQoNCkFzIHlvdSBjYW4gc2VlLCBJIHJld3Jv dGUgdGhlIHJlc3Qgb2YgdGhlIHBhcmFncmFwaCBhcyB3ZWxsLCBzaW1wbGlmeWluZw0KaXQgYW5k IGZvY3VzaW5nIGl0IG1vcmUgb24gbW90aXZhdGlvbiB0aGFuIHNvbHV0aW9uLiAgV2hhdCBkbyB5 b3UgdGhpbms/DQoNClRoYW5rcywNCktlbnQNCg0KDQoNCk9uIDUvNy8xNCwgMTo1NCBQTSwgIktl bnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCj4NCj5IaSBUb20sDQo+ DQo+DQo+PlNvLCBteSBzdGlsbCBvdXRzdGFuZGluZyBwb2ludHMgYXJlDQo+Pg0KPj4tIHMuNSwg cmUtYXJyYW5nZSB0byBkb3ZldGFpbCBiZXR0ZXIgd2l0aCA1NTM5YmlzDQo+DQo+TXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IHlvdSBiZWxpZXZlIHRoYXQgYm90aCBkcmFmdHMgc2hhcmUgdGhlIGlz c3VlIG9mDQo+dGhlIG5vcnRoYm91bmQgbWFuYWdlbWVudCBhcHBsaWNhdGlvbiBiZWluZyBhYmxl IHRvIGlkZW50aWZ5IGFuZCB2ZXJpZnkNCj50aGUgW1NTSC9UTFNdIHNlcnZlciB0aGF0IHVzZXMg Y2FsbC1ob21lIHRvIGNvbm5lY3QgdG8gaXQuICAgSSBhZ3JlZS4NCj4NCj5BbmQgdGhhdCB0aGUg dGV4dCBpbiB0aGUgcmV2ZXJzZS1zc2ggZHJhZnQsIHdoaWxlIG9zdGVuc2libHkgYWJvdXQgU1NI DQo+aG9zdCBrZXlzLCBjb3VsZCBzaW1pbGFybHkgYXBwbHkgdG8gVExTIGFuZCBpdHMgdXNlIG9m IFguNTA5IGNlcnRpZmljYXRlcy4NCj4gIEkgYWdyZWUgYWdhaW4sIHRoZXJlIGlzIGFuIG92ZXJs YXAuDQo+DQo+VGh1cyB5b3UgdGhpbmsgdGhhdCBtdWNoIG9mIHRoZSB0ZXh0IHNob3VsZCBiZSBt b3ZlZCB0byA1NTM5YmlzIGFuZCBmb3INCj50aGUgcmV2ZXJzZS1zc2ggZHJhZnQgdG8gcmVmZXJl bmNlIGl0IHRoZXJlLiAgSSBkb26p9nQgYWdyZWUsIGZvciB0d28NCj5yZWFzb25zOg0KPg0KPjEp IGlmIHRoZXJlIGlzIGEgbmVlZCB0byBkZWZpbmUgY29tbW9uIGNhbGwtaG9tZSBiZWhhdmlvciwg d2Ugc2hvdWxkIGhhdmUNCj5hIKn4Y2FsbC1ob21lqfcgZHJhZnQgdGhhdCBjb3ZlcnMgYm90aCBU TFMgYW5kIFNTSCBjYWxsLWhvbWUgdG9nZXRoZXIuICBJDQo+cmVjYWxsIHRoaXMgYmVpbmcgb25l IG9mIHRoZSBvcHRpb25zIGRpc2N1c3NlZCBiZWZvcmUsIGJ1dCB0aGUgV0cgZGVjaWRlZA0KPnRv IG1vdmUgYWhlYWQgd2l0aCB0aGlzIGRvY3VtZW50IHN0cnVjdHVyZS4gIEluIGxpZXUgb2YgdGhh dCwgSSB0aGluayB0aGF0DQo+dGhlIHJldmVyc2Utc3NoIGRyYWZ0IGlzIGNsb3NlciB0byBiZWlu ZyBhIKn4Y2FsbC1ob21lqfcgZHJhZnQgdGhhbiA1NTM5YmlzLA0KPmFuZCBzbyBzdWdnZXN0IHB1 dHRpbmcgY29tbW9uIGNhbGwtaG9tZSBpbmZvcm1hdGlvbiBpbnRvIGl0LCBwZXJoYXBzDQo+cHVs bGVkIG91dCBpbnRvIGEgc2VjdGlvbiBjYWxsZWQgqfhjb21tb24gY2FsbC1ob21lIGJlaGF2aW91 c6n3IC0gd2hhdCBkbw0KPnlvdSB0aGluaz8NCj4NCj4yKSBUaGUgdGV4dCBpbiB0aGUgcmV2ZXJz ZS1zc2ggZHJhZnQgaXMgYWxzbyBtdWNoIGFib3V0IHRoZSB1c2Ugb2YgbGVnYWN5DQo+aG9zdC1r ZXlzIHZlcnN1cyB0aGUgbmV3IFguNTA5IGJhc2VkIGtleXMgd2l0aCBTU0guICBTYXlpbmcgdGhh dCB1c2Ugb2YNCj5sZWdhY3kga2V5cyBpcyBwb3NzaWJsZSBhbmQgYWxsb3dlZCwgYnV0IGZyYXVn aHQgd2l0aCBpc3N1ZXMgdGhhdCBhcmUNCj5yZXNvbHZlZCB3aGVuIHVzaW5nIFguNTA5IGtleXMu ICBNYXliZSB0aGlzIG5lZWRzIHRvIGJlIG1heSBjbGVhcmVyLCBidXQgSQ0KPmRvbqn2dCB0aGlu ayB0aGUgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGxvc3QuDQo+IA0KPg0KPg0KPj4tIHdvcmRzbWl0 aCB0aGUgQWJzdHJhY3QvSW50cm9kdWN0aW9uIChhcyBmaXJzdCBzdWdnZXN0ZWQgbGFzdA0KPj5O b3ZlbWJlcjotKSB3aGVyZSBJIHRoaW5rIHRoZSBmaXJzdCByZWZlcmVuY2UgdG8gJ1NTSCBDb25u ZWN0aW9uJyBpcw0KPj53cm9uZywgc28gbWFrZSBpdCBzb21ldGhpbmcgbGlrZQ0KPj4NCj4+IlRo aXMgbWVtbyBwcmVzZW50cyBhIHRlY2huaXF1ZSBmb3IgYSBORVRDT05GIHNlcnZlciB0byByZXF1 ZXN0IHRoYXQgYQ0KPj5ORVRDT05GIGNsaWVudCBpbml0aWF0ZXMgYSBTU0ggY29ubmVjdGlvbiB0 byB0aGUgTkVUQ09ORiBzZXJ2ZXIsDQo+PmEgdGVjaG5pcXVlIHJlZmVycmVkIHRvIGFzICdjYWxs IGhvbWUnLiINCj4NCj5JIGxpa2UgdGhpcyB0ZXh0LCBlc3BlY2lhbGx5IHNpbmNlIHdlIHN3aXRj aGVkIGV2ZXJ5dGhpbmcgZWxzZSB0bw0KPiJjYWxsLWhvbWUiIGluIC0wNS4gICBJIGp1c3QgdXBk YXRlZCBteSBsb2NhbCBjb3B5IHRoaXMgdGhpcyBjaGFuZ2UsIGJ1dA0KPndpbGwgd2FpdCBmb3Ig cmVzb2x1dGlvbiBvZiB0aGUgYWJvdmUgYmVmb3JlIHB1dHRpbmcgb3V0IC0wNg0KPg0KPg0KPg0K PlRoYW5rcywNCj5LZW50DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5OZXRjb25mIG1haWxpbmcgbGlzdA0KPk5ldGNvbmZAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K From nobody Thu May 8 02:08:05 2014 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 4F4C91A026A for ; Thu, 8 May 2014 02:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ifgun98iZOh for ; Thu, 8 May 2014 02:07:59 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) by ietfa.amsl.com (Postfix) with ESMTP id AEBCE1A0239 for ; Thu, 8 May 2014 02:07:58 -0700 (PDT) Received: from DBXPRD0210HT001.eurprd02.prod.outlook.com (157.56.253.181) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.939.12; Thu, 8 May 2014 09:07:52 +0000 Message-ID: <007201cf6a9c$aa76f980$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Bert Wijnen (IETF)" References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> Date: Thu, 8 May 2014 09:59:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.181] X-ClientProxiedBy: AM3PR07CA0045.eurprd07.prod.outlook.com (10.141.45.173) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Forefront-PRVS: 0205EDCD76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(51444003)(51704005)(189002)(164054003)(199002)(377454003)(40224001)(13464003)(50226001)(76176999)(66066001)(81686999)(79102001)(62236002)(20776003)(50466002)(77982001)(88136002)(89996001)(50986999)(99396002)(44736004)(84392001)(19580395003)(93916002)(101416001)(46102001)(76482001)(74502001)(42186004)(87976001)(92726001)(19580405001)(86362001)(83322001)(4396001)(44716002)(33646001)(31966008)(81342001)(85852003)(61296002)(62966002)(81816999)(80022001)(83072002)(74662001)(87286001)(47776003)(1941001)(64706001)(92566001)(77156001)(21056001)(23756003)(14496001)(81542001)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB059; H:DBXPRD0210HT001.eurprd02.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/SgNTg2jRFnjbEcO6IBkmXRg38hY Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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, 08 May 2014 09:08:04 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Bert Wijnen (IETF)" Cc: Sent: Wednesday, May 07, 2014 6:54 PM Hi Tom, >So, my still outstanding points are > >- s.5, re-arrange to dovetail better with 5539bis My understanding is that you believe that both drafts share the issue of the northbound management application being able to identify and verify the [SSH/TLS] server that uses call-home to connect to it. I agree. And that the text in the reverse-ssh draft, while ostensibly about SSH host keys, could similarly apply to TLS and its use of X.509 certificates. I agree again, there is an overlap. Thus you think that much of the text should be moved to 5539bis and for the reverse-ssh draft to reference it there. I donıt agree, for two reasons: 1) if there is a need to define common call-home behavior, we should have a ³call-home² draft that covers both TLS and SSH call-home together. I recall this being one of the options discussed before, but the WG decided to move ahead with this document structure. In lieu of that, I think that the reverse-ssh draft is closer to being a ³call-home² draft than 5539bis, and so suggest putting common call-home information into it, perhaps pulled out into a section called ³common call-home behavious² - what do you think? 2) The text in the reverse-ssh draft is also much about the use of legacy host-keys versus the new X.509 based keys with SSH. Saying that use of legacy keys is possible and allowed, but fraught with issues that are resolved when using X.509 keys. Maybe this needs to be may clearer, but I donıt think the information should be lost. Kent No, I think I am not making myself clear. I am not saying that we need a common call home section. I am saying that having obtained a public key somehow, then it needs verifying, that it is tied to the party that we are trying to communicate with, and that that process is largely the same whether this is call home or not. One form of verification is using X.509 certs, and that is the usual way for TLS. My logic then is put everything we have to say about the use of X.509 certs for verification in the TLS I-D and reference it from the (reverse-)ssh I-D. The approach is the same for SSH and TLS and call home and not call home IMHO so put it in the one place. Currently, reverse-ssh lacks some of the points that 5539bis makes about the use of certs, and the base ssh RFC says nothing, but reverse-ssh has points that 5539bis does not such as the paragraph " Since both the identification and verification issues are addressed using certificates, this draft RECOMMENDS network elements use a host key that can encode a unique identifier (e.g., its serial number) and be signed by a common trust anchor (e.g., a certificate authority). Examples of suitable public host keys are the X.509v3 keys defined in defined in [RFC6187]." 5539bis would be better for having that information in it alongside what it currently has so I would move that to 5539bis leaving behind something like " Since both the identification and verification issues are addressed using certificates, this draft RECOMMENDS network elements use them - more details can be found in [5539bis]." By contrast, the use of raw public keys is rare in TLS and commonplace in SSH, so I would keep everything about that that is currently there in reverse-ssh - mostly it is nothing to do with call home but the base ssh RFC does not cover it so we might as well do the job properly now. So between them, reverse-ssh and 5539bis currently have all we need, it is just that you have to read both in tandem to learn what you should know. Tom Petch >- wordsmith the Abstract/Introduction (as first suggested last >November:-) where I think the first reference to 'SSH Connection' is >wrong, so make it something like > >"This memo presents a technique for a NETCONF server to request that a >NETCONF client initiates a SSH connection to the NETCONF server, >a technique referred to as 'call home'." I like this text, especially since we switched everything else to "call-home" in -05. I just updated my local copy this this change, but will wait for resolution of the above before putting out -06 Thanks, Kent From nobody Thu May 8 02:08:07 2014 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 ABC6F1A0239 for ; Thu, 8 May 2014 02:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcPR0OVL0CTC for ; Thu, 8 May 2014 02:08:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) by ietfa.amsl.com (Postfix) with ESMTP id 72A611A048C for ; Thu, 8 May 2014 02:07:59 -0700 (PDT) Received: from DBXPRD0210HT001.eurprd02.prod.outlook.com (157.56.253.181) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.939.12; Thu, 8 May 2014 09:07:53 +0000 Message-ID: <007301cf6a9c$aafd4080$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Bert Wijnen (IETF)" References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> Date: Thu, 8 May 2014 10:02:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.181] X-ClientProxiedBy: AM3PR07CA0045.eurprd07.prod.outlook.com (10.141.45.173) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Forefront-PRVS: 0205EDCD76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51444003)(51704005)(189002)(164054003)(199002)(479174003)(377454003)(24454002)(13464003)(50226001)(76176999)(66066001)(81686999)(79102001)(62236002)(20776003)(50466002)(77982001)(88136002)(89996001)(50986999)(99396002)(44736004)(84392001)(19580395003)(93916002)(101416001)(46102001)(76482001)(74502001)(42186004)(87976001)(92726001)(19580405001)(86362001)(83322001)(4396001)(44716002)(33646001)(31966008)(81342001)(23706002)(85852003)(61296002)(62966002)(81816999)(80022001)(83072002)(74662001)(87286001)(47776003)(64706001)(92566001)(77156001)(21056001)(14496001)(81542001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB059; H:DBXPRD0210HT001.eurprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/M4MnBO_f5ppK9xOL5r7REJl6Dp4 Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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, 08 May 2014 09:08:04 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Bert Wijnen (IETF)" Cc: Sent: Wednesday, May 07, 2014 11:15 PM > > Hi Tom, > > No need to wait for -06, here's the new text for the Abstract: > > This document presents a technique for a NETCONF server to request > that a NETCONF client initiates a SSH connection to the NETCONF > server, a technique referred to as 'call home'. Call home is needed > to support deployments where the NETCONF client is otherwise unable > to initiate a SSH connection to the NETCONF server directly. > > > As you can see, I rewrote the rest of the paragraph as well, simplifying > it and focusing it more on motivation than solution. What do you think? Looks good - go with it. And the Introduction needs a comparable change Tom Petch > > Thanks, > Kent > > > > On 5/7/14, 1:54 PM, "Kent Watsen" wrote: > > > > >Hi Tom, > > > > > >>So, my still outstanding points are > >> > >>- s.5, re-arrange to dovetail better with 5539bis > > > >My understanding is that you believe that both drafts share the issue of > >the northbound management application being able to identify and verify > >the [SSH/TLS] server that uses call-home to connect to it. I agree. > > > >And that the text in the reverse-ssh draft, while ostensibly about SSH > >host keys, could similarly apply to TLS and its use of X.509 certificates. > > I agree again, there is an overlap. > > > >Thus you think that much of the text should be moved to 5539bis and for > >the reverse-ssh draft to reference it there. I donİöt agree, for two > >reasons: > > > >1) if there is a need to define common call-home behavior, we should have > >a İĝcall-homeİ÷ draft that covers both TLS and SSH call-home together. I > >recall this being one of the options discussed before, but the WG decided > >to move ahead with this document structure. In lieu of that, I think that > >the reverse-ssh draft is closer to being a İĝcall-homeİ÷ draft than 5539bis, > >and so suggest putting common call-home information into it, perhaps > >pulled out into a section called İĝcommon call-home behaviousİ÷ - what do > >you think? > > > >2) The text in the reverse-ssh draft is also much about the use of legacy > >host-keys versus the new X.509 based keys with SSH. Saying that use of > >legacy keys is possible and allowed, but fraught with issues that are > >resolved when using X.509 keys. Maybe this needs to be may clearer, but I > >donİöt think the information should be lost. > > > > > > > >>- wordsmith the Abstract/Introduction (as first suggested last > >>November:-) where I think the first reference to 'SSH Connection' is > >>wrong, so make it something like > >> > >>"This memo presents a technique for a NETCONF server to request that a > >>NETCONF client initiates a SSH connection to the NETCONF server, > >>a technique referred to as 'call home'." > > > >I like this text, especially since we switched everything else to > >"call-home" in -05. I just updated my local copy this this change, but > >will wait for resolution of the above before putting out -06 > > > > > > > >Thanks, > >Kent > > > >_______________________________________________ > >Netconf mailing list > >Netconf@ietf.org > >https://www.ietf.org/mailman/listinfo/netconf > > From nobody Thu May 8 18:20:46 2014 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 BE1901A00B1 for ; Thu, 8 May 2014 18:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 mcTD5-pUP4c1 for ; Thu, 8 May 2014 18:20:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE6A51A0079 for ; Thu, 8 May 2014 18:20:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDY77810; Fri, 09 May 2014 01:20:38 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 02:19:14 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 02:20:36 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 9 May 2014 09:20:29 +0800 From: "Liubing (Leo)" To: "netconf@ietf.org" Thread-Topic: Netconf keep-alive (was [Netconf] periodic connections, heartbeats, reconnection, timeout) Thread-Index: AQHPayTcdlEKCkbuoUmknUejgxkm0g== Date: Fri, 9 May 2014 01:20:28 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D88838E@nkgeml506-mbx.china.huawei.com> References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/divvFbcBwy8yHHGxDD7zW7j7OHI Subject: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 09 May 2014 01:20:45 -0000 Hi all, This mail is regarding to the Netconf keep-alive issue raised in several we= eks ago, sorry for my late intervene to the discussion. My comment/proposal is inline. > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent > Watsen > Sent: Tuesday, April 15, 2014 3:27 AM > To: t.petch; Bert Wijnen (IETF) > Cc: netconf@ietf.org > Subject: Re: [Netconf] periodic connections, heartbeats, reconnection ... > >Reading the details, I struggle to see why these functions should be > >tied to > > - SSH > > - TLS > > - listen > > - call home > > - NETCONF client > > - NETCONF server > >That is, why shouldn't any NETCONF engine send a heartbeat, timeout if > >no response in a suitable period, drop a connection and reconnect when > >it wants to? These functions seem useful in any setting, rather than > >specific to a particular scenario. >=20 > Any NETCONF engine? Are you suggesting an RPC? [Bing] As explained in the follow-ups mails, Tom didn't mean to suggest suc= h an RPC. But I just support to have such a kind of extension to Netconf. I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in= some a specific scenario like reverse-SSH/call home/server/client.etc, but= a quite generic requirement.=20 One typical scenarios is, the NMS requiring a heavy search on the router, w= hich might cost the router a long time to process or even make the router s= uspend. Then it would be good for the NMS to learn the status of the router= through a periodic keep-alive, then it could close the session without wai= ting until the timeout in SSH/TLS if the router suspend. If we agree it is a generic requirement, then I think it's better to have t= he keep-alive function in Netconf-level rather than in SSH/TLS-level.=20 The main reason in my mind is that using SSH/TLS messages to inform Netconf= status would invoke a layering violation. SSH/TLS heartbeat messages shoul= d only represent the status of the transport channel, and should not repres= ent the status of the Netconf processing.=20 What are your thoughts on this issue? Best regards, Bing From nobody Thu May 8 19:00:21 2014 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 AB3641A00E2 for ; Thu, 8 May 2014 19:00:19 -0700 (PDT) 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 PTK-v-8RVdAV for ; Thu, 8 May 2014 19:00:17 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF521A00CD for ; Thu, 8 May 2014 19:00:16 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id cm18so3383752qab.22 for ; Thu, 08 May 2014 19:00:12 -0700 (PDT) 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=fUOHm6RrhL3d5gGg5y2K02zY4k2AYZbuWfeDdiPCbng=; b=JBlMB7dIOyDZ1GyEyZeu3d4WmmgvzbVdk6o6gJKMcgtnazoQXwBBejWINYgbbQ8fyE XfkoHUlMfUgwOWIUq5S3LV4a8XdLi8iDWbzjx/dtLrw19T3v/okLdUcth099bQRxFHZ2 LMCE1HpsIBoukwjbQSiJoQCHDix+Saho6BFBtZnREUty5SufaFjmNiklvAcQYUXARCIH tYH1HQujZp14lxiM8p6ubZ8qOioAn8pVpcB5/p/ovI93FZxcqa0IGvl7daBcE4QE+Ip6 BWmkGAAVtH7UGZBW3Zwnpf6YyRuMpi3qxXmWhBHAEyk9F+jedQpo5FRUqK7BCpyEGWg3 25pw== X-Gm-Message-State: ALoCoQlD7dT0umAMJPLvlgZ8rw5V0X9CahEN+jN4p7ERq6boZT6T8mjXk407f1a+GmiDiHMnundI MIME-Version: 1.0 X-Received: by 10.140.27.245 with SMTP id 108mr9885156qgx.18.1399600812099; Thu, 08 May 2014 19:00:12 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Thu, 8 May 2014 19:00:12 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D88838E@nkgeml506-mbx.china.huawei.com> References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D88838E@nkgeml506-mbx.china.huawei.com> Date: Thu, 8 May 2014 19:00:12 -0700 Message-ID: From: Andy Bierman To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c152603c0fab04f8edf5c8 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/CF5zUpEk42px5rVHEqELP387gcU Cc: "netconf@ietf.org" Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 09 May 2014 02:00:19 -0000 --001a11c152603c0fab04f8edf5c8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo) wrote: > Hi all, > > This mail is regarding to the Netconf keep-alive issue raised in several > weeks ago, sorry for my late intervene to the discussion. > My comment/proposal is inline. > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent > > Watsen > > Sent: Tuesday, April 15, 2014 3:27 AM > > To: t.petch; Bert Wijnen (IETF) > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] periodic connections, heartbeats, reconnection > ... > > >Reading the details, I struggle to see why these functions should be > > >tied to > > > - SSH > > > - TLS > > > - listen > > > - call home > > > - NETCONF client > > > - NETCONF server > > >That is, why shouldn't any NETCONF engine send a heartbeat, timeout if > > >no response in a suitable period, drop a connection and reconnect when > > >it wants to? These functions seem useful in any setting, rather than > > >specific to a particular scenario. > > > > Any NETCONF engine? Are you suggesting an RPC? > > [Bing] As explained in the follow-ups mails, Tom didn't mean to suggest > such an RPC. But I just support to have such a kind of extension to Netconf. > > I agree with Tom that we need a heartbeat/keep-alive mechanism, not only > in some a specific scenario like reverse-SSH/call home/server/client.etc, > but a quite generic requirement. > One typical scenarios is, the NMS requiring a heavy search on the router, > which might cost the router a long time to process or even make the router > suspend. Then it would be good for the NMS to learn the status of the > router through a periodic keep-alive, then it could close the session > without waiting until the timeout in SSH/TLS if the router suspend. > > If we agree it is a generic requirement, then I think it's better to have > the keep-alive function in Netconf-level rather than in SSH/TLS-level. > The main reason in my mind is that using SSH/TLS messages to inform > Netconf status would invoke a layering violation. SSH/TLS heartbeat > messages should only represent the status of the transport channel, and > should not represent the status of the Netconf processing. > > What are your thoughts on this issue? > > I do not agree a complex protocol extension is needed. Many implementations do not want to keep idle sessions alive. That's why they have --idle-timeout CLI parameters. SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax CLI parameters to deal with this issue (in addition to TCPKeepAlive). I want an idle session to get dropped by the server. It is trivial to implement a no-op RPC as a client keep-alive: rpc no-op; Clients can deal with keep-alive activity on their own. I am not against standardizing a reasonable solution, but servers generally support a limited number of concurrent sessions and dropping idle sessions is a feature. Best regards, > Bing > Andy --001a11c152603c0fab04f8edf5c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo) <= ;leo.liubing@hu= awei.com> wrote:
Hi all,

This mail is regarding to the Netconf keep-alive issue raised in several we= eks ago, sorry for my late intervene to the discussion.
My comment/proposal is inline.

> -----Original Message-----
> From: Netconf [mailto:netc= onf-bounces@ietf.org] On Behalf Of Kent
> Watsen
> Sent: Tuesday, April 15, 2014 3:27 AM
> To: t.petch; Bert Wijnen (IETF)
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] periodic connections, heartbeats, reconnection<= br> ...
> >Reading the details, I struggle to see why these functions should = be
> >tied to
> > - SSH
> > - TLS
> > - listen
> > - call home
> > - NETCONF client
> > - NETCONF server
> >That is, why shouldn't any NETCONF engine send a heartbeat, ti= meout if
> >no response in a suitable period, drop a connection and reconnect = when
> >it wants to? =A0These functions seem useful in any setting, rather= than
> >specific to a particular scenario.
>
> Any NETCONF engine? =A0Are you suggesting an <are-you-alive/> RP= C?

[Bing] As explained in the follow-ups mails, Tom didn't mean to suggest= such an RPC. But I just support to have such a kind of extension to Netcon= f.

I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in= some a specific scenario like reverse-SSH/call home/server/client.etc, but= a quite generic requirement.
One typical scenarios is, the NMS requiring a heavy search on the router, w= hich might cost the router a long time to process or even make the router s= uspend. Then it would be good for the NMS to learn the status of the router= through a periodic keep-alive, then it could close the session without wai= ting until the timeout in SSH/TLS if the router suspend.

If we agree it is a generic requirement, then I think it's better to ha= ve the keep-alive function in Netconf-level rather than in SSH/TLS-level. The main reason in my mind is that using SSH/TLS messages to inform Netconf= status would invoke a layering violation. SSH/TLS heartbeat messages shoul= d only represent the status of the transport channel, and should not repres= ent the status of the Netconf processing.

What are your thoughts on this issue?


I do not agree a complex protocol exte= nsion is needed.
Many implementations do not want to keep idle se= ssions alive.
That's why they have --idle-timeout CLI paramet= ers.

SSH (OpenSSH anyway) has ClientAliveInterval and Client= AliveCountMax
CLI parameters to deal with this issue (in addition= to TCPKeepAlive).

I want an idle session to get d= ropped by the server.
It is trivial to implement a no-op RPC as a client keep-alive:

=A0 =A0 rpc no-op;

Clients can d= eal with keep-alive activity on their own.
I am not against stand= ardizing a reasonable solution, but servers
generally support a limited number of concurrent sessions and
dropping idle sessions is a feature.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Best regards,
Bing


Andy

=
--001a11c152603c0fab04f8edf5c8-- From nobody Thu May 8 22:05:33 2014 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 8ACD71A01DB for ; Thu, 8 May 2014 22:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 xCwhYO2jj6sV for ; Thu, 8 May 2014 22:05:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34C671A01DA for ; Thu, 8 May 2014 22:05:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDY89395; Fri, 09 May 2014 05:05:21 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 06:03:55 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 06:05:17 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 9 May 2014 13:05:10 +0800 From: "Liubing (Leo)" To: Andy Bierman Thread-Topic: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) Thread-Index: AQHPayputtSOgj4VdkiXgRxlAPzJHps3nddw Date: Fri, 9 May 2014 05:05:10 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D888402@nkgeml506-mbx.china.huawei.com> References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D88838E@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D888402nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/CmK8GIegoGGRyggj66PGmWc7bgQ Cc: "netconf@ietf.org" Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 09 May 2014 05:05:32 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D888402nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Thanks for your quick response. Please see replies inline. From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, May 09, 2014 10:00 AM To: Liubing (Leo) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartb= eats, reconnection, timeout) On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo) > wrote: Hi all, This mail is regarding to the Netconf keep-alive issue raised in several we= eks ago, sorry for my late intervene to the discussion. My comment/proposal is inline. > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent > Watsen > Sent: Tuesday, April 15, 2014 3:27 AM > To: t.petch; Bert Wijnen (IETF) > Cc: netconf@ietf.org > Subject: Re: [Netconf] periodic connections, heartbeats, reconnection ... > >Reading the details, I struggle to see why these functions should be > >tied to > > - SSH > > - TLS > > - listen > > - call home > > - NETCONF client > > - NETCONF server > >That is, why shouldn't any NETCONF engine send a heartbeat, timeout if > >no response in a suitable period, drop a connection and reconnect when > >it wants to? These functions seem useful in any setting, rather than > >specific to a particular scenario. > > Any NETCONF engine? Are you suggesting an RPC? [Bing] As explained in the follow-ups mails, Tom didn't mean to suggest suc= h an RPC. But I just support to have such a kind of extension to Netconf. I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in= some a specific scenario like reverse-SSH/call home/server/client.etc, but= a quite generic requirement. One typical scenarios is, the NMS requiring a heavy search on the router, w= hich might cost the router a long time to process or even make the router s= uspend. Then it would be good for the NMS to learn the status of the router= through a periodic keep-alive, then it could close the session without wai= ting until the timeout in SSH/TLS if the router suspend. If we agree it is a generic requirement, then I think it's better to have t= he keep-alive function in Netconf-level rather than in SSH/TLS-level. The main reason in my mind is that using SSH/TLS messages to inform Netconf= status would invoke a layering violation. SSH/TLS heartbeat messages shoul= d only represent the status of the transport channel, and should not repres= ent the status of the Netconf processing. What are your thoughts on this issue? I do not agree a complex protocol extension is needed. [Bing] As in my mind, it doesn't need to be complex. Just a simple "keep-al= ive" indication might be sufficient. Many implementations do not want to keep idle sessions alive. That's why they have --idle-timeout CLI parameters. SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax CLI parameters to deal with this issue (in addition to TCPKeepAlive). I want an idle session to get dropped by the server. It is trivial to implement a no-op RPC as a client keep-alive: [Bing] The point is, the keep-alive is just NOT for idle session, it is for= an active session. If no Netconf keep-alives are received in a reasonable period, it means som= ething wrong happened in the Netconf server , then the client could termina= te the session without waiting until SSH ClientAliveCountMax. And as I said= above, it might be better to de-couple the Netconf-alive and the SSH/TLS-a= live, so that the status could be more precisely identified. Best regards, Bing rpc no-op; Clients can deal with keep-alive activity on their own. I am not against standardizing a reasonable solution, but servers generally support a limited number of concurrent sessions and dropping idle sessions is a feature. Best regards, Bing Andy --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D888402nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 = ;

Thanks for= your quick response. Please see replies inline.

 = ;

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, May 09, 2014 10:00 AM
To: Liubing (Leo)
Cc: netconf@ietf.org
Subject: Re: [Netconf] Netconf keep-alive (was periodic connections,= heartbeats, reconnection, timeout)

 

 

=  

On Thu, May 8, 2014 at 6:20 PM,= Liubing (Leo) <leo.liubing@huawei.com> wrote:

= Hi all,

This mail is regarding to the Netconf keep-alive issue raised in several we= eks ago, sorry for my late intervene to the discussion.
My comment/proposal is inline.

> -----Original Message-----
> From: Netconf [mailto:netc= onf-bounces@ietf.org] On Behalf Of Kent
> Watsen
> Sent: Tuesday, April 15, 2014 3:27 AM
> To: t.petch; Bert Wijnen (IETF)
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] periodic connections, heartbeats, reconnection<= br> ...
> >Reading the details, I struggle to see why these functions should = be
> >tied to
> > - SSH
> > - TLS
> > - listen
> > - call home
> > - NETCONF client
> > - NETCONF server
> >That is, why shouldn't any NETCONF engine send a heartbeat, timeou= t if
> >no response in a suitable period, drop a connection and reconnect = when
> >it wants to?  These functions seem useful in any setting, rat= her than
> >specific to a particular scenario.
>
> Any NETCONF engine?  Are you suggesting an <are-you-alive/>= RPC?

[Bing] As explained in the follow-ups mails, Tom didn't mean to suggest suc= h an RPC. But I just support to have such a kind of extension to Netconf.
I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in= some a specific scenario like reverse-SSH/call home/server/client.etc, but= a quite generic requirement.
One typical scenarios is, the NMS requiring a heavy search on the router, w= hich might cost the router a long time to process or even make the router s= uspend. Then it would be good for the NMS to learn the status of the router= through a periodic keep-alive, then it could close the session without waiting until the timeout in SSH/T= LS if the router suspend.

If we agree it is a generic requirement, then I think it's better to have t= he keep-alive function in Netconf-level rather than in SSH/TLS-level.
The main reason in my mind is that using SSH/TLS messages to inform Netconf= status would invoke a layering violation. SSH/TLS heartbeat messages shoul= d only represent the status of the transport channel, and should not repres= ent the status of the Netconf processing.

What are your thoughts on this issue?

 

I do not agree a complex protoc= ol extension is needed.

[Bing] As = in my mind, it doesn’t need to be complex. Just a simple “keep-= alive” indication might be sufficient.

 = ;

Many implementations do not wan= t to keep idle sessions alive.

That's why they have --idle-tim= eout CLI parameters.

SSH (OpenSSH anyway) has Client= AliveInterval and ClientAliveCountMax

CLI parameters to deal with thi= s issue (in addition to TCPKeepAlive).

 

I want an idle session to get d= ropped by the server.

It is trivial to implement a no= -op RPC as a client keep-alive:

[Bing] The= point is, the keep-alive is just NOT for idle session, it is for an active= session.

If no Netc= onf keep-alives are received in a reasonable period, it means something wro= ng happened in the Netconf server , then the client could terminate the session without waiting until SSH ClientAliveCountMax. And a= s I said above, it might be better to de-couple the Netconf-alive and the S= SH/TLS-alive, so that the status could be more precisely identified.

 = ;

Best regar= ds,

Bing<= /o:p>

 

    rpc no-op;

 

Clients can deal with keep-aliv= e activity on their own.

I am not against standardizing = a reasonable solution, but servers

generally support a limited num= ber of concurrent sessions and

dropping idle sessions is a fea= ture.

 

 

Best regards,
Bing

 

 

Andy

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D888402nkgeml506mbxchi_-- From nobody Fri May 9 02:19:00 2014 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 0ADF21A0234 for ; Fri, 9 May 2014 02:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4592JzQSGsiL for ; Fri, 9 May 2014 02:18:56 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) by ietfa.amsl.com (Postfix) with ESMTP id 53A911A0233 for ; Fri, 9 May 2014 02:18:56 -0700 (PDT) Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 09:18:49 +0000 Message-ID: <00ca01cf6b67$5be6f560$4001a8c0@gateway.2wire.net> From: t.petch To: "Liubing (Leo)" , Andy Bierman References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D88838E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D888402@nkgeml506-mbx.china.huawei.com> Date: Fri, 9 May 2014 10:16:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AMSPR07CA002.eurprd07.prod.outlook.com (10.242.77.170) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 02065A9E77 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(53754006)(13464003)(52054003)(51704005)(24454002)(189002)(199002)(31966008)(62966002)(61296002)(74502001)(23756003)(14496001)(76482001)(561944002)(46102001)(50466002)(4396001)(21056001)(44736004)(89996001)(50226001)(92566001)(79102001)(44716002)(74662001)(81542001)(101416001)(33646001)(62236002)(47776003)(83322001)(99396002)(19580395003)(80022001)(19580405001)(77982001)(66066001)(64706001)(87286001)(81342001)(92726001)(76176999)(20776003)(86362001)(87976001)(77156001)(42186004)(93916002)(81816999)(81686999)(85852003)(83072002)(50986999)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0310HT003.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pdmW6YPhxobNnvAapfI3erWRIEE Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 09 May 2014 09:18:59 -0000 ----- Original Message ----- From: "Liubing (Leo)" To: "Andy Bierman" Cc: Sent: Friday, May 09, 2014 6:05 AM Hi Andy, Thanks for your quick response. Please see replies inline. From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, May 09, 2014 10:00 AM To: Liubing (Leo) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo) > wrote: Hi all, This mail is regarding to the Netconf keep-alive issue raised in several weeks ago, sorry for my late intervene to the discussion. My comment/proposal is inline. > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent > Watsen > Sent: Tuesday, April 15, 2014 3:27 AM > To: t.petch; Bert Wijnen (IETF) > Cc: netconf@ietf.org > Subject: Re: [Netconf] periodic connections, heartbeats, reconnection ... > >Reading the details, I struggle to see why these functions should be > >tied to > > - SSH > > - TLS > > - listen > > - call home > > - NETCONF client > > - NETCONF server > >That is, why shouldn't any NETCONF engine send a heartbeat, timeout if > >no response in a suitable period, drop a connection and reconnect when > >it wants to? These functions seem useful in any setting, rather than > >specific to a particular scenario. > > Any NETCONF engine? Are you suggesting an RPC? [Bing] As explained in the follow-ups mails, Tom didn't mean to suggest such an RPC. But I just support to have such a kind of extension to Netconf. I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in some a specific scenario like reverse-SSH/call home/server/client.etc, but a quite generic requirement. One typical scenarios is, the NMS requiring a heavy search on the router , which might cost the router a long time to process or even make the router suspend. Then it would be good for the NMS to learn the status of the router through a periodic keep-alive, then it could close the session without waiting until the timeout in SSH/TLS if the router suspend. If we agree it is a generic requirement, then I think it's better to have the keep-alive function in Netconf-level rather than in SSH/TLS-level. The main reason in my mind is that using SSH/TLS messages to inform Netconf status would invoke a layering violation. SSH/TLS heartbeat messages should only represent the status of the transport channel, and should not represent the status of the Netconf processing. What are your thoughts on this issue? I do not agree a complex protocol extension is needed. [Bing] As in my mind, it doesn't need to be complex. Just a simple "keep-alive" indication might be sufficient. Many implementations do not want to keep idle sessions alive. That's why they have --idle-timeout CLI parameters. SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax CLI parameters to deal with this issue (in addition to TCPKeepAlive). I want an idle session to get dropped by the server. It is trivial to implement a no-op RPC as a client keep-alive: [Bing] The point is, the keep-alive is just NOT for idle session, it is for an active session. If no Netconf keep-alives are received in a reasonable period, it means something wrong happened in the Netconf server , then the client could terminate the session without waiting until SSH ClientAliveCountMax. And as I said above, it might be better to de-couple the Netconf-alive and the SSH/TLS-alive, so that the status could be more precisely identified. It came as a suprise to those on the syslog list that a TCP connection could go down, be down for hours and noone noticed so that when it was needed to convey a critical fault, syslog was not working. By analogy, there will be those using NETCONF who think that the reliable transport means that when a critical alert needs to get through, they can rely on the connection being there. So I see keep-alives as something that the IETF should recommend for anything involving alarms, alerts, traps, notifications etc. The SNMP NMS that I am familiar with poll at regular intervals - yes, over UDP, but I would hope they did the same over TCP, TLS, etc Ideally, NETCONF would do this at its layer, but we are not updating that and we are updating SSH and TLS transports thereof, so, compromising architectural purity, I would include it at that layer pro tem. As before, I do not see any disctinction is this regard between call home and regular sessions. Tom Petch Best regards, Bing rpc no-op; Clients can deal with keep-alive activity on their own. I am not against standardizing a reasonable solution, but servers generally support a limited number of concurrent sessions and dropping idle sessions is a feature. Best regards, Bing Andy From nobody Fri May 9 06:14:42 2014 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 3B8561A029E for ; Fri, 9 May 2014 06:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=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 NSgubu-Xvir1 for ; Fri, 9 May 2014 06:14:38 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE621A02AE for ; Fri, 9 May 2014 06:14:35 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j5so4082681qaq.29 for ; Fri, 09 May 2014 06:14:30 -0700 (PDT) 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=XgWtJNQDk4zJf1Z2rEQOkTuxVcQv8SJncRM3yfEIxt4=; b=WGIGiZIjqLkv7yEWFEpgsQdGZ6VDmuMfId8FtY16GK0+0w1NvJh7u+Uv0GxCbaK2cl zlOTHnD0/n+U8F2oYIBVIKCY2760t6udftLUQG9Vp2XJ+LBOC9xUNDCOjDUM5xH6OdpT LFGYZxZncuUmyg8FsUMPOOQYZknwmUULlcwDiGsbTV5goZLYt7qMDxs5VuX1gXwasiP4 eAT4jR2q8eZvZZuoyaLmKE1fnFxHOJXMxOfNWphJHQKNM6JlwbsYafZJ28hzIZ4M5wmN 4b6mNy7OmMBTflY30PZntRt/DWSW1sF5LUbFgBz9MGU8OgyWTL1/nmmRDezy0X8wBwM9 I9aA== X-Gm-Message-State: ALoCoQnGNIIgnnh0V8ZOzPWddgHWIWsJWKUv4yIz5BXhxhHhlNriM/Hg+y8gtbHHgMGC3fJ7ZRLb MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr13882825qad.88.1399641269806; Fri, 09 May 2014 06:14:29 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Fri, 9 May 2014 06:14:29 -0700 (PDT) In-Reply-To: <00ca01cf6b67$5be6f560$4001a8c0@gateway.2wire.net> References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D88838E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D888402@nkgeml506-mbx.china.huawei.com> <00ca01cf6b67$5be6f560$4001a8c0@gateway.2wire.net> Date: Fri, 9 May 2014 06:14:29 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=089e0158a9e4b349ae04f8f76048 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FQ4CU2gyfiUuIexS0dK1CZi8nHY Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 09 May 2014 13:14:40 -0000 --089e0158a9e4b349ae04f8f76048 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 9, 2014 at 2:16 AM, t.petch wrote: > ----- Original Message ----- > From: "Liubing (Leo)" > To: "Andy Bierman" > Cc: > Sent: Friday, May 09, 2014 6:05 AM > > Hi Andy, > > Thanks for your quick response. Please see replies inline. > > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Friday, May 09, 2014 10:00 AM > To: Liubing (Leo) > Cc: netconf@ietf.org > Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, > heartbeats, reconnection, timeout) > > > > On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo) > > wrote: > Hi all, > > This mail is regarding to the Netconf keep-alive issue raised in several > weeks ago, sorry for my late intervene to the discussion. > My comment/proposal is inline. > > > -----Original Message----- > > From: Netconf > [mailto:netconf-bounces@ietf.org] On > Behalf Of Kent > > Watsen > > Sent: Tuesday, April 15, 2014 3:27 AM > > To: t.petch; Bert Wijnen (IETF) > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] periodic connections, heartbeats, reconnection > ... > > >Reading the details, I struggle to see why these functions should be > > >tied to > > > - SSH > > > - TLS > > > - listen > > > - call home > > > - NETCONF client > > > - NETCONF server > > >That is, why shouldn't any NETCONF engine send a heartbeat, timeout > if > > >no response in a suitable period, drop a connection and reconnect > when > > >it wants to? These functions seem useful in any setting, rather than > > >specific to a particular scenario. > > > > Any NETCONF engine? Are you suggesting an RPC? > > [Bing] As explained in the follow-ups mails, Tom didn't mean to suggest > such an RPC. But I just support to have such a kind of extension to > Netconf. > > I agree with Tom that we need a heartbeat/keep-alive mechanism, not only > in some a specific scenario like reverse-SSH/call > home/server/client.etc, but a quite generic requirement. > One typical scenarios is, the NMS requiring a heavy search on the router > , which might cost the router a long time to process or even make the > router suspend. Then it would be good for the NMS to learn the status of > the router through a periodic keep-alive, then it could close the > session without waiting until the timeout in SSH/TLS if the router > suspend. > > If we agree it is a generic requirement, then I think it's better to > have the keep-alive function in Netconf-level rather than in > SSH/TLS-level. > The main reason in my mind is that using SSH/TLS messages to inform > Netconf status would invoke a layering violation. SSH/TLS heartbeat > messages should only represent the status of the transport channel, and > should not represent the status of the Netconf processing. > > What are your thoughts on this issue? > > I do not agree a complex protocol extension is needed. > [Bing] As in my mind, it doesn't need to be complex. Just a simple > "keep-alive" indication might be sufficient. > > Many implementations do not want to keep idle sessions alive. > That's why they have --idle-timeout CLI parameters. > SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax > CLI parameters to deal with this issue (in addition to TCPKeepAlive). > > I want an idle session to get dropped by the server. > It is trivial to implement a no-op RPC as a client keep-alive: > > [Bing] The point is, the keep-alive is just NOT for idle session, it is > for an active session. > If no Netconf keep-alives are received in a reasonable period, it means > something wrong happened in the Netconf server , then the client could > terminate the session without waiting until SSH ClientAliveCountMax. And > as I said above, it might be better to de-couple the Netconf-alive and > the SSH/TLS-alive, so that the status could be more precisely > identified. > > > It came as a suprise to those on the syslog list that a TCP connection > could go down, be down for hours and noone noticed so that when it was > needed to convey a critical fault, syslog was not working. > > By analogy, there will be those using NETCONF who think that the > reliable transport means that when a critical alert needs to get > through, they can rely on the connection being there. > > So I see keep-alives as something that the IETF should recommend for > anything involving alarms, alerts, traps, notifications etc. The SNMP > NMS that I am familiar with poll at regular intervals - yes, over UDP, > but I would hope they did the same over TCP, TLS, etc > > Ideally, NETCONF would do this at its layer, but we are not updating > that and we are updating SSH and TLS transports thereof, so, > compromising architectural purity, I would include it at that layer pro > tem. > > Why? NETCONF does not run directly over TCP. Why is it NETCONF's job to make sure the TCP connection stays up? It seems like that should be SSH or TLS doing that. I have never seen this problem in real deployments because OpenSSH is supposed to be configured correctly (TCPKeepAlive yes is the default). > As before, I do not see any disctinction is this regard between call > home and regular sessions. > > Tom Petch > > Best regards, > Bing > > Andy > rpc no-op; > > Clients can deal with keep-alive activity on their own. > I am not against standardizing a reasonable solution, but servers > generally support a limited number of concurrent sessions and > dropping idle sessions is a feature. > > > Best regards, > Bing > > > Andy > > --089e0158a9e4b349ae04f8f76048 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 9, 2014 at 2:16 AM, t.petch <ietfc@btconnect.com= > wrote:
----- Original Message -----
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: "Andy Bierman" <andy= @yumaworks.com>
Cc: <netconf@ietf.org>
Sent: Friday, May 09, 2014 6:05 AM

Hi Andy,

Thanks for your quick response. Please see replies inline.

From: Andy Bierman [mailto:andy@yumaw= orks.com]
Sent: Friday, May 09, 2014 10:00 AM
To: Liubing (Leo)
Cc: netconf@ietf.org
Subject: Re: [Netconf] Netconf keep-alive (was periodic connections,
heartbeats, reconnection, timeout)



On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo)
<leo.liubing@huawei.com<= ;mailto:leo.liubing@huawei.com>> wrote:
Hi all,

This mail is regarding to the Netconf keep-alive issue raised in several weeks ago, sorry for my late intervene to the discussion.
My comment/proposal is inline.

> -----Original Message-----
> From: Netconf
[mailto:netconf-bounces@ietf.or= g<mailto:netconf-bounces= @ietf.org>] On
Behalf Of Kent
> Watsen
> Sent: Tuesday, April 15, 2014 3:27 AM
> To: t.petch; Bert Wijnen (IETF)
> Cc: netconf@ietf.org<mailto= :netconf@ietf.org>
> Subject: Re: [Netconf] periodic connections, heartbeats, reconnection<= br> ...
> >Reading the details, I struggle to see why these functions should = be
> >tied to
> > - SSH
> > - TLS
> > - listen
> > - call home
> > - NETCONF client
> > - NETCONF server
> >That is, why shouldn't any NETCONF engine send a heartbeat, ti= meout
if
> >no response in a suitable period, drop a connection and reconnect<= br> when
> >it wants to? =A0These functions seem useful in any setting, rather= than
> >specific to a particular scenario.
>
> Any NETCONF engine? =A0Are you suggesting an <are-you-alive/> RP= C?

[Bing] As explained in the follow-ups mails, Tom didn't mean to suggest=
such an RPC. But I just support to have such a kind of extension to
Netconf.

I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in some a specific scenario like reverse-SSH/call
home/server/client.etc, but a quite generic requirement.
One typical scenarios is, the NMS requiring a heavy search on the router , which might cost the router a long time to process or even make the
router suspend. Then it would be good for the NMS to learn the status of the router through a periodic keep-alive, then it could close the
session without waiting until the timeout in SSH/TLS if the router
suspend.

If we agree it is a generic requirement, then I think it's better to have the keep-alive function in Netconf-level rather than in
SSH/TLS-level.
The main reason in my mind is that using SSH/TLS messages to inform
Netconf status would invoke a layering violation. SSH/TLS heartbeat
messages should only represent the status of the transport channel, and
should not represent the status of the Netconf processing.

What are your thoughts on this issue?

I do not agree a complex protocol extension is needed.
[Bing] As in my mind, it doesn't need to be complex. Just a simple
"keep-alive" indication might be sufficient.

Many implementations do not want to keep idle sessions alive.
That's why they have --idle-timeout CLI parameters.
SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax
CLI parameters to deal with this issue (in addition to TCPKeepAlive).

I want an idle session to get dropped by the server.
It is trivial to implement a no-op RPC as a client keep-alive:

[Bing] The point is, the keep-alive is just NOT for idle session, it is
for an active session.
If no Netconf keep-alives are received in a reasonable period, it means
something wrong happened in the Netconf server , then the client could
terminate the session without waiting until SSH ClientAliveCountMax. And as I said above, it might be better to de-couple the Netconf-alive and
the SSH/TLS-alive, so that the status could be more precisely
identified.

<tp>
It came as a suprise to those on the syslog list that a TCP connection
could go down, be down for hours and noone noticed so that when it was
needed to convey a critical fault, syslog was not working.

By analogy, there will be those using NETCONF who think that the
reliable transport means that when a critical alert needs to get
through, they can rely on the connection being there.

So I see keep-alives as something that the IETF should recommend for
anything involving alarms, alerts, traps, notifications etc. =A0The SNMP NMS that I am familiar with poll at regular intervals - yes, over UDP,
but I would hope they did the same over TCP, TLS, etc

Ideally, NETCONF would do this at its layer, but we are not updating
that and we are updating SSH and TLS transports thereof, so,
compromising architectural purity, I would include it at that layer pro
tem.



Why?
NETCONF = does not run directly over TCP.
Why is it NETCONF's job to ma= ke sure the TCP connection stays up?
It seems like that should be= SSH or TLS doing that.
I have never seen this problem in real deployments because OpenSSH
is supposed to be configured correctly (TCPKeepAlive yes is the defa= ult).

=A0
As before, I do not see any disctinction is this regard between call
home and regular sessions.

Tom Petch

Best regards,
Bing



Andy

=A0
=A0 =A0 rpc no-op;

Clients can deal with keep-alive activity on their own.
I am not against standardizing a reasonable solution, but servers
generally support a limited number of concurrent sessions and
dropping idle sessions is a feature.


Best regards,
Bing


Andy


--089e0158a9e4b349ae04f8f76048-- From nobody Fri May 9 11:58:24 2014 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 F21601A0076 for ; Fri, 9 May 2014 11:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 vIRljN6n5vRt for ; Fri, 9 May 2014 11:58:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 312FB1A0053 for ; Fri, 9 May 2014 11:58:18 -0700 (PDT) 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.0.939.12; Fri, 9 May 2014 18:58:10 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) with mapi id 15.00.0939.000; Fri, 9 May 2014 18:58:10 +0000 From: Kent Watsen To: Andy Bierman , t.petch Thread-Topic: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) Thread-Index: AQHPayrnhMBsqp0TmUSXTxwk80lj6ps3sisAgABHJgCAAEGQgIAAHPYA Date: Fri, 9 May 2014 18:58:09 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D88838E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D888402@nkgeml506-mbx.china.huawei.com> <00ca01cf6b67$5be6f560$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.14] x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(13464003)(51444003)(164054003)(24454002)(377454003)(51704005)(189002)(53754006)(199002)(81542001)(86362001)(81342001)(36756003)(83322001)(2656002)(19580405001)(101416001)(87936001)(64706001)(19580395003)(20776003)(74662001)(31966008)(74502001)(92566001)(92726001)(46102001)(4396001)(561944002)(77982001)(16236675002)(99286001)(21056001)(66066001)(79102001)(80022001)(76482001)(83506001)(83072002)(76176999)(50986999)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: multipart/alternative; boundary="_000_CF9297EE6F4A1kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dehY7es5SnmFSbHQmiqACsQ1668 Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 09 May 2014 18:58:23 -0000 --_000_CF9297EE6F4A1kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Before debating how we do keep-alives, did we agree that we want to support= persistent connections? Keep-alives are only needed for persistent connec= tions, and I recall Martin questioning if persistent connections needed to = be supported. My answer at the time and now is that I think persistent con= nections are important for call-home scenario where it's the NMS wants to s= end commands to the device immediately, without waiting for the device's ne= xt "periodic" connection. On the flip-side, we could take out persistent c= onnections, and the NMS could configure the device to connect often (e.g., = every 30 seconds) so that the wait isn't unnecessarily long. This may or m= ay not fly. I don't know, but perhaps we should be conservative and define= it anyways, leaving it as an option for deployments to decide if they want= to use it or not. Also, Tom wrote before that we should have symmetry, not a device-side only= solution. I think that the current solution is symmetric because, in the= normal case where the NMS initiates the TCP connection, it already has the= ability to keep the connection open as long as it likes and even send TCP/= SSH/TLS-level keep-alives as it sees fit. We don't need to define a confi= guration model for the NC client (i.e. the NMS). We only need to define a= config model for the NC server (i.e. the device). Maybe I'm misunderstan= ding the symmetry concern, another way of looking at it is that the current= netconf-server-model only configures keep-alives under the "call-home" nod= e (not the "listen") node. Tom, is this what you meant? Thanks, Kent From: Andy Bierman > Date: Friday, May 9, 2014 at 9:14 AM To: "t.petch" > Cc: NetConf > Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartb= eats, reconnection, timeout) On Fri, May 9, 2014 at 2:16 AM, t.petch > wrote: ----- Original Message ----- From: "Liubing (Leo)" > To: "Andy Bierman" > Cc: > Sent: Friday, May 09, 2014 6:05 AM Hi Andy, Thanks for your quick response. Please see replies inline. From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, May 09, 2014 10:00 AM To: Liubing (Leo) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo) >> wrote: Hi all, This mail is regarding to the Netconf keep-alive issue raised in several weeks ago, sorry for my late intervene to the discussion. My comment/proposal is inline. > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org>] On Behalf Of Kent > Watsen > Sent: Tuesday, April 15, 2014 3:27 AM > To: t.petch; Bert Wijnen (IETF) > Cc: netconf@ietf.org> > Subject: Re: [Netconf] periodic connections, heartbeats, reconnection ... > >Reading the details, I struggle to see why these functions should be > >tied to > > - SSH > > - TLS > > - listen > > - call home > > - NETCONF client > > - NETCONF server > >That is, why shouldn't any NETCONF engine send a heartbeat, timeout if > >no response in a suitable period, drop a connection and reconnect when > >it wants to? These functions seem useful in any setting, rather than > >specific to a particular scenario. > > Any NETCONF engine? Are you suggesting an RPC? [Bing] As explained in the follow-ups mails, Tom didn't mean to suggest such an RPC. But I just support to have such a kind of extension to Netconf. I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in some a specific scenario like reverse-SSH/call home/server/client.etc, but a quite generic requirement. One typical scenarios is, the NMS requiring a heavy search on the router , which might cost the router a long time to process or even make the router suspend. Then it would be good for the NMS to learn the status of the router through a periodic keep-alive, then it could close the session without waiting until the timeout in SSH/TLS if the router suspend. If we agree it is a generic requirement, then I think it's better to have the keep-alive function in Netconf-level rather than in SSH/TLS-level. The main reason in my mind is that using SSH/TLS messages to inform Netconf status would invoke a layering violation. SSH/TLS heartbeat messages should only represent the status of the transport channel, and should not represent the status of the Netconf processing. What are your thoughts on this issue? I do not agree a complex protocol extension is needed. [Bing] As in my mind, it doesn't need to be complex. Just a simple "keep-alive" indication might be sufficient. Many implementations do not want to keep idle sessions alive. That's why they have --idle-timeout CLI parameters. SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax CLI parameters to deal with this issue (in addition to TCPKeepAlive). I want an idle session to get dropped by the server. It is trivial to implement a no-op RPC as a client keep-alive: [Bing] The point is, the keep-alive is just NOT for idle session, it is for an active session. If no Netconf keep-alives are received in a reasonable period, it means something wrong happened in the Netconf server , then the client could terminate the session without waiting until SSH ClientAliveCountMax. And as I said above, it might be better to de-couple the Netconf-alive and the SSH/TLS-alive, so that the status could be more precisely identified. It came as a suprise to those on the syslog list that a TCP connection could go down, be down for hours and noone noticed so that when it was needed to convey a critical fault, syslog was not working. By analogy, there will be those using NETCONF who think that the reliable transport means that when a critical alert needs to get through, they can rely on the connection being there. So I see keep-alives as something that the IETF should recommend for anything involving alarms, alerts, traps, notifications etc. The SNMP NMS that I am familiar with poll at regular intervals - yes, over UDP, but I would hope they did the same over TCP, TLS, etc Ideally, NETCONF would do this at its layer, but we are not updating that and we are updating SSH and TLS transports thereof, so, compromising architectural purity, I would include it at that layer pro tem. Why? NETCONF does not run directly over TCP. Why is it NETCONF's job to make sure the TCP connection stays up? It seems like that should be SSH or TLS doing that. I have never seen this problem in real deployments because OpenSSH is supposed to be configured correctly (TCPKeepAlive yes is the default). As before, I do not see any disctinction is this regard between call home and regular sessions. Tom Petch Best regards, Bing Andy rpc no-op; Clients can deal with keep-alive activity on their own. I am not against standardizing a reasonable solution, but servers generally support a limited number of concurrent sessions and dropping idle sessions is a feature. Best regards, Bing Andy --_000_CF9297EE6F4A1kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <7931E3F87D1E2A4096A9132BBC06B4A7@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Before debating how we do keep-alives, did we agree that we want to su= pport persistent connections?  Keep-alives are only needed for persist= ent connections, and I recall Martin questioning if persistent connections = needed to be supported.  My answer at the time and now is that I think persistent connections are important for = call-home scenario where it's the NMS wants to send commands to the device = immediately, without waiting for the device's next "periodic" con= nection.  On the flip-side, we could take out persistent connections, and the NMS could configure the device to conn= ect often (e.g., every 30 seconds) so that the wait isn't unnecessarily lon= g.  This may or may not fly.  I don't know, but perhaps we should= be conservative and define it anyways, leaving it as an option for deployments to decide if they want to use it or not.

Also, Tom wrote before that we should have symmetry, not a device-side= only solution.   I think that the current solution is symmetric becau= se, in the normal case where the NMS initiates the TCP connection, it alrea= dy has the ability to keep the connection open as long as it likes and even send TCP/SSH/TLS-level keep-alives as it= sees fit.   We don't need to define a configuration model for the NC = client (i.e. the NMS).   We only need to define a config model for the= NC server (i.e. the device).   Maybe I'm misunderstanding the symmetry concern, another way of looking at it is tha= t the current netconf-server-model only configures keep-alives under the &q= uot;call-home" node (not the "listen") node.   Tom, is = this what you meant?

Thanks,
Kent


From: Andy Bierman <andy@yumaworks.com>
Date: Friday, May 9, 2014 at 9:14 A= M
To: "t.petch" <ietfc@btconnect.com>
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] Netconf keep= -alive (was periodic connections, heartbeats, reconnection, timeout)




On Fri, May 9, 2014 at 2:16 AM, t.petch <ietfc@btconnec= t.com> wrote:
----- Original Message -----
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: "Andy Bierman" <andy= @yumaworks.com>
Cc: <netconf@ietf.org>
Sent: Friday, May 09, 2014 6:05 AM

Hi Andy,

Thanks for your quick response. Please see replies inline.

From: Andy Bierman [mailto:andy@yumaw= orks.com]
Sent: Friday, May 09, 2014 10:00 AM
To: Liubing (Leo)
Cc: netconf@ietf.org
Subject: Re: [Netconf] Netconf keep-alive (was periodic connections,
heartbeats, reconnection, timeout)



On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo)
<leo.liubing@huawei.com<= ;mailto:leo.liubing@huawei.com>> wrote:
Hi all,

This mail is regarding to the Netconf keep-alive issue raised in several weeks ago, sorry for my late intervene to the discussion.
My comment/proposal is inline.

> -----Original Message-----
> From: Netconf
[mailto:netconf-bounces@ietf.or= g<mailto:netconf-bounces= @ietf.org>] On
Behalf Of Kent
> Watsen
> Sent: Tuesday, April 15, 2014 3:27 AM
> To: t.petch; Bert Wijnen (IETF)
> Cc: netconf@ietf.org<mailto= :netconf@ietf.org>
> Subject: Re: [Netconf] periodic connections, heartbeats, reconnection<= br> ...
> >Reading the details, I struggle to see why these functions should = be
> >tied to
> > - SSH
> > - TLS
> > - listen
> > - call home
> > - NETCONF client
> > - NETCONF server
> >That is, why shouldn't any NETCONF engine send a heartbeat, timeou= t
if
> >no response in a suitable period, drop a connection and reconnect<= br> when
> >it wants to?  These functions seem useful in any setting, rat= her than
> >specific to a particular scenario.
>
> Any NETCONF engine?  Are you suggesting an <are-you-alive/>= RPC?

[Bing] As explained in the follow-ups mails, Tom didn't mean to suggest
such an RPC. But I just support to have such a kind of extension to
Netconf.

I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in some a specific scenario like reverse-SSH/call
home/server/client.etc, but a quite generic requirement.
One typical scenarios is, the NMS requiring a heavy search on the router , which might cost the router a long time to process or even make the
router suspend. Then it would be good for the NMS to learn the status of the router through a periodic keep-alive, then it could close the
session without waiting until the timeout in SSH/TLS if the router
suspend.

If we agree it is a generic requirement, then I think it's better to
have the keep-alive function in Netconf-level rather than in
SSH/TLS-level.
The main reason in my mind is that using SSH/TLS messages to inform
Netconf status would invoke a layering violation. SSH/TLS heartbeat
messages should only represent the status of the transport channel, and
should not represent the status of the Netconf processing.

What are your thoughts on this issue?

I do not agree a complex protocol extension is needed.
[Bing] As in my mind, it doesn't need to be complex. Just a simple
"keep-alive" indication might be sufficient.

Many implementations do not want to keep idle sessions alive.
That's why they have --idle-timeout CLI parameters.
SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax
CLI parameters to deal with this issue (in addition to TCPKeepAlive).

I want an idle session to get dropped by the server.
It is trivial to implement a no-op RPC as a client keep-alive:

[Bing] The point is, the keep-alive is just NOT for idle session, it is
for an active session.
If no Netconf keep-alives are received in a reasonable period, it means
something wrong happened in the Netconf server , then the client could
terminate the session without waiting until SSH ClientAliveCountMax. And as I said above, it might be better to de-couple the Netconf-alive and
the SSH/TLS-alive, so that the status could be more precisely
identified.

<tp>
It came as a suprise to those on the syslog list that a TCP connection
could go down, be down for hours and noone noticed so that when it was
needed to convey a critical fault, syslog was not working.

By analogy, there will be those using NETCONF who think that the
reliable transport means that when a critical alert needs to get
through, they can rely on the connection being there.

So I see keep-alives as something that the IETF should recommend for
anything involving alarms, alerts, traps, notifications etc.  The SNMP=
NMS that I am familiar with poll at regular intervals - yes, over UDP,
but I would hope they did the same over TCP, TLS, etc

Ideally, NETCONF would do this at its layer, but we are not updating
that and we are updating SSH and TLS transports thereof, so,
compromising architectural purity, I would include it at that layer pro
tem.



Why?
NETCONF does not run directly over TCP.
Why is it NETCONF's job to make sure the TCP connection stays up?
It seems like that should be SSH or TLS doing that.
I have never seen this problem in real deployments because OpenSSH
is supposed to be configured correctly (TCPKeepAlive yes is the defaul= t).

 
As before, I do not see any disctinction is this regard between call
home and regular sessions.

Tom Petch

Best regards,
Bing



Andy

 
    rpc no-op;

Clients can deal with keep-alive activity on their own.
I am not against standardizing a reasonable solution, but servers
generally support a limited number of concurrent sessions and
dropping idle sessions is a feature.


Best regards,
Bing


Andy


--_000_CF9297EE6F4A1kwatsenjunipernet_-- From nobody Fri May 9 12:35:35 2014 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 079611A0156 for ; Fri, 9 May 2014 12:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6r6znaIjriz0 for ; Fri, 9 May 2014 12:35:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4D99E1A008F for ; Fri, 9 May 2014 12:35:32 -0700 (PDT) Received: from DM2PR05CA005.namprd05.prod.outlook.com (10.141.96.25) by BY2PR05MB062.namprd05.prod.outlook.com (10.242.34.147) with Microsoft SMTP Server (TLS) id 15.0.939.12; Fri, 9 May 2014 19:35:24 +0000 Received: from BY2FFO11FD031.protection.gbl (2a01:111:f400:7c0c::182) by DM2PR05CA005.outlook.office365.com (2a01:111:e400:2428::25) with Microsoft SMTP Server (TLS) id 15.0.939.12 via Frontend Transport; Fri, 9 May 2014 19:35:24 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD031.mail.protection.outlook.com (10.1.14.196) with Microsoft SMTP Server (TLS) id 15.0.939.9 via Frontend Transport; Fri, 9 May 2014 19:35:23 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 9 May 2014 12:35:20 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s49JZHL14923; Fri, 9 May 2014 12:35:18 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id s49JZEPt067551; Fri, 9 May 2014 15:35:14 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201405091935.s49JZEPt067551@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Fri, 9 May 2014 15:35:14 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(164054003)(21056001)(84676001)(77096999)(54356999)(68736004)(44976005)(69596002)(77982001)(80022001)(83322001)(81156002)(6806004)(87936001)(53416003)(81542001)(76482001)(50466002)(48376002)(558084003)(47776003)(64706001)(79102001)(81342001)(50986999)(4396001)(46102001)(31966008)(74502001)(83072002)(2009001)(92726001)(74662001)(86362001)(92566001)(20776003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB062; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Forefront-PRVS: 02065A9E77 Received-SPF: SoftFail (: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pWgLk8ItKrn6JWag55bxgkg6Ap4 Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 09 May 2014 19:35:34 -0000 Kent Watsen writes: >Before debating how we do keep-alives, did we agree that we want to support >persistent connections? Aren't keep-alives a transport issue? For example SSH should use the existing ssh keep-alives. Thanks, Phil From nobody Fri May 9 12:39:46 2014 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 D72201A0322 for ; Fri, 9 May 2014 12:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=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 zxc-4pE_lZaS for ; Fri, 9 May 2014 12:39:38 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 130BC1A031A for ; Fri, 9 May 2014 12:39:35 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id i8so5202507qcq.29 for ; Fri, 09 May 2014 12:39:30 -0700 (PDT) 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=08x4figEhTjlbCHW64s03EGJt0z2+2l2Xwn97e8JzQ4=; b=RRqMkZGbf6oo2qSjuEQBz1cgTvUOe6u8zPkBVYgqfhffCeo4cMiV/ZugwZaWYfli6r 13xjLdyrYyQB1/nKPoSLmT4H+hPtH2LBNbOHGn6UdVIxPQGnDfz4jpb0JOWZFX/+w9Ue +KJ7T9vdQC2ElEGQ+9B42DZrPGpn/zuQyfpKM62OqIJ6a7+tsZUaqDnIlgqrYt4+kRu8 ozsb77z/SjGEPfEhAuRaI7jdSG3QFTWyyhnWv2I7Jkt0AVBWqLSMIS1WWKRvj1Zmod9g SkY7rSleapEuk6+lCpL94cMVJjvyG10V+ObBGrYAyWk3Tq6l0AzcEO7apfmHS5RofXPm B/wQ== X-Gm-Message-State: ALoCoQn1UdSdpJrBe1Nk93w5/QBLKRzyW0Ytp8yDC7BOESZ9fo5+BW5aQaT/CiRQVDAQaXlCKbA5 MIME-Version: 1.0 X-Received: by 10.224.55.6 with SMTP id s6mr17482077qag.7.1399664369981; Fri, 09 May 2014 12:39:29 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Fri, 9 May 2014 12:39:29 -0700 (PDT) In-Reply-To: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D88838E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D888402@nkgeml506-mbx.china.huawei.com> <00ca01cf6b67$5be6f560$4001a8c0@gateway.2wire.net> Date: Fri, 9 May 2014 12:39:29 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=089e0153705e93eeb404f8fcc1dd Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/BnxztbTmDXupsVfbJmyPzZvwM58 Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 09 May 2014 19:39:41 -0000 --089e0153705e93eeb404f8fcc1dd Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 9, 2014 at 11:58 AM, Kent Watsen wrote: > > Before debating how we do keep-alives, did we agree that we want to > support persistent connections? Keep-alives are only needed for persistent > connections, and I recall Martin questioning if persistent connections > needed to be supported. My answer at the time and now is that I think > persistent connections are important for call-home scenario where it's the > NMS wants to send commands to the device immediately, without waiting for > the device's next "periodic" connection. On the flip-side, we could take > out persistent connections, and the NMS could configure the device to > connect often (e.g., every 30 seconds) so that the wait isn't unnecessarily > long. This may or may not fly. I don't know, but perhaps we should be > conservative and define it anyways, leaving it as an option for deployments > to decide if they want to use it or not. > > Also, Tom wrote before that we should have symmetry, not a device-side > only solution. I think that the current solution is symmetric because, in > the normal case where the NMS initiates the TCP connection, it already has > the ability to keep the connection open as long as it likes and even send > TCP/SSH/TLS-level keep-alives as it sees fit. We don't need to define a > configuration model for the NC client (i.e. the NMS). We only need to > define a config model for the NC server (i.e. the device). Maybe I'm > misunderstanding the symmetry concern, another way of looking at it is that > the current netconf-server-model only configures keep-alives under the > "call-home" node (not the "listen") node. Tom, is this what you meant? > > I also said I prefer not to have persistent connections, at least for client-initiated sessions. Side issue: a leaf in the /netconf-state tree indicating the idle-timeout (if any) used by the server will help clients know how the server will treat their session. > Thanks, > Kent > Andy > > > From: Andy Bierman > Date: Friday, May 9, 2014 at 9:14 AM > To: "t.petch" > Cc: NetConf > Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, > heartbeats, reconnection, timeout) > > > > > On Fri, May 9, 2014 at 2:16 AM, t.petch wrote: > >> ----- Original Message ----- >> From: "Liubing (Leo)" >> To: "Andy Bierman" >> Cc: >> Sent: Friday, May 09, 2014 6:05 AM >> >> Hi Andy, >> >> Thanks for your quick response. Please see replies inline. >> >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Friday, May 09, 2014 10:00 AM >> To: Liubing (Leo) >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, >> heartbeats, reconnection, timeout) >> >> >> >> On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo) >> > wrote: >> Hi all, >> >> This mail is regarding to the Netconf keep-alive issue raised in several >> weeks ago, sorry for my late intervene to the discussion. >> My comment/proposal is inline. >> >> > -----Original Message----- >> > From: Netconf >> [mailto:netconf-bounces@ietf.org] On >> Behalf Of Kent >> > Watsen >> > Sent: Tuesday, April 15, 2014 3:27 AM >> > To: t.petch; Bert Wijnen (IETF) >> > Cc: netconf@ietf.org >> > Subject: Re: [Netconf] periodic connections, heartbeats, reconnection >> ... >> > >Reading the details, I struggle to see why these functions should be >> > >tied to >> > > - SSH >> > > - TLS >> > > - listen >> > > - call home >> > > - NETCONF client >> > > - NETCONF server >> > >That is, why shouldn't any NETCONF engine send a heartbeat, timeout >> if >> > >no response in a suitable period, drop a connection and reconnect >> when >> > >it wants to? These functions seem useful in any setting, rather than >> > >specific to a particular scenario. >> > >> > Any NETCONF engine? Are you suggesting an RPC? >> >> [Bing] As explained in the follow-ups mails, Tom didn't mean to suggest >> such an RPC. But I just support to have such a kind of extension to >> Netconf. >> >> I agree with Tom that we need a heartbeat/keep-alive mechanism, not only >> in some a specific scenario like reverse-SSH/call >> home/server/client.etc, but a quite generic requirement. >> One typical scenarios is, the NMS requiring a heavy search on the router >> , which might cost the router a long time to process or even make the >> router suspend. Then it would be good for the NMS to learn the status of >> the router through a periodic keep-alive, then it could close the >> session without waiting until the timeout in SSH/TLS if the router >> suspend. >> >> If we agree it is a generic requirement, then I think it's better to >> have the keep-alive function in Netconf-level rather than in >> SSH/TLS-level. >> The main reason in my mind is that using SSH/TLS messages to inform >> Netconf status would invoke a layering violation. SSH/TLS heartbeat >> messages should only represent the status of the transport channel, and >> should not represent the status of the Netconf processing. >> >> What are your thoughts on this issue? >> >> I do not agree a complex protocol extension is needed. >> [Bing] As in my mind, it doesn't need to be complex. Just a simple >> "keep-alive" indication might be sufficient. >> >> Many implementations do not want to keep idle sessions alive. >> That's why they have --idle-timeout CLI parameters. >> SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax >> CLI parameters to deal with this issue (in addition to TCPKeepAlive). >> >> I want an idle session to get dropped by the server. >> It is trivial to implement a no-op RPC as a client keep-alive: >> >> [Bing] The point is, the keep-alive is just NOT for idle session, it is >> for an active session. >> If no Netconf keep-alives are received in a reasonable period, it means >> something wrong happened in the Netconf server , then the client could >> terminate the session without waiting until SSH ClientAliveCountMax. And >> as I said above, it might be better to de-couple the Netconf-alive and >> the SSH/TLS-alive, so that the status could be more precisely >> identified. >> >> >> It came as a suprise to those on the syslog list that a TCP connection >> could go down, be down for hours and noone noticed so that when it was >> needed to convey a critical fault, syslog was not working. >> >> By analogy, there will be those using NETCONF who think that the >> reliable transport means that when a critical alert needs to get >> through, they can rely on the connection being there. >> >> So I see keep-alives as something that the IETF should recommend for >> anything involving alarms, alerts, traps, notifications etc. The SNMP >> NMS that I am familiar with poll at regular intervals - yes, over UDP, >> but I would hope they did the same over TCP, TLS, etc >> >> Ideally, NETCONF would do this at its layer, but we are not updating >> that and we are updating SSH and TLS transports thereof, so, >> compromising architectural purity, I would include it at that layer pro >> tem. >> >> > > Why? > NETCONF does not run directly over TCP. > Why is it NETCONF's job to make sure the TCP connection stays up? > It seems like that should be SSH or TLS doing that. > I have never seen this problem in real deployments because OpenSSH > is supposed to be configured correctly (TCPKeepAlive yes is the default). > > > >> As before, I do not see any disctinction is this regard between call >> home and regular sessions. >> >> Tom Petch >> >> Best regards, >> Bing >> >> > > Andy > > > >> rpc no-op; >> >> Clients can deal with keep-alive activity on their own. >> I am not against standardizing a reasonable solution, but servers >> generally support a limited number of concurrent sessions and >> dropping idle sessions is a feature. >> >> >> Best regards, >> Bing >> >> >> Andy >> >> > --089e0153705e93eeb404f8fcc1dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 9, 2014 at 11:58 AM, Kent Watsen <= kwatsen@juniper.ne= t> wrote:

Before debating how we do keep-alives, did we agree that we want to su= pport persistent connections? =A0Keep-alives are only needed for persistent= connections, and I recall Martin questioning if persistent connections nee= ded to be supported. =A0My answer at the time and now is that I think persistent connections are important for = call-home scenario where it's the NMS wants to send commands to the dev= ice immediately, without waiting for the device's next "periodic&q= uot; connection. =A0On the flip-side, we could take out persistent connections, and the NMS could configure the device to conn= ect often (e.g., every 30 seconds) so that the wait isn't unnecessarily= long. =A0This may or may not fly. =A0I don't know, but perhaps we shou= ld be conservative and define it anyways, leaving it as an option for deployments to decide if they want to use it or not.

Also, Tom wrote before that we should have symmetry, not a device-side= only solution. =A0 I think that the current solution is symmetric because,= in the normal case where the NMS initiates the TCP connection, it already = has the ability to keep the connection open as long as it likes and even send TCP/SSH/TLS-level keep-alives as it= sees fit. =A0 We don't need to define a configuration model for the NC= client (i.e. the NMS). =A0 We only need to define a config model for the N= C server (i.e. the device). =A0 Maybe I'm misunderstanding the symmetry concern, another way of looking at it is tha= t the current netconf-server-model only configures keep-alives under the &q= uot;call-home" node (not the "listen") node. =A0 Tom, is thi= s what you meant?



I also= said I prefer not to have persistent connections,
at least for c= lient-initiated sessions.

Side issue: a leaf in th= e /netconf-state tree indicating the idle-timeout
(if any) used by the server will help clients know how the server will=
treat their session.

=A0
Thanks,
Kent

Andy
=A0


From: Andy Bierman <andy@yumaworks.com>
Date: Friday, May 9, 2014 at 9:14 A= M
To: "t.petch" <ietfc@btconnect.com&g= t;
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] Netconf keep= -alive (was periodic connections, heartbeats, reconnection, timeout)




On Fri, May 9, 2014 at 2:16 AM, t.petch <ietfc@btconnec= t.com> wrote:
----- Original Message -----
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: "Andy Bierman" <andy@yumaworks.com>
Cc: <netconf@ietf.= org>
Sent: Friday, May 09, 2014 6:05 AM

Hi Andy,

Thanks for your quick response. Please see replies inline.

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, May 09, 2014 10:00 AM
To: Liubing (Leo)
Cc: netconf@ietf.org<= /a>
Subject: Re: [Netconf] Netconf keep-alive (was periodic connections,
heartbeats, reconnection, timeout)



On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo)
<leo.liubing= @huawei.com<mailto:leo.liubing@huawei.com>> wrote:
Hi all,

This mail is regarding to the Netconf keep-alive issue raised in several weeks ago, sorry for my late intervene to the discussion.
My comment/proposal is inline.

> -----Original Message-----
> From: Netconf
[mailto:netco= nf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>] On
Behalf Of Kent
> Watsen
> Sent: Tuesday, April 15, 2014 3:27 AM
> To: t.petch; Bert Wijnen (IETF)
> Cc: netconf@ietf= .org<mailto:ne= tconf@ietf.org>
> Subject: Re: [Netconf] periodic connections, heartbeats, reconnection<= br> ...
> >Reading the details, I struggle to see why these functions should = be
> >tied to
> > - SSH
> > - TLS
> > - listen
> > - call home
> > - NETCONF client
> > - NETCONF server
> >That is, why shouldn't any NETCONF engine send a heartbeat, ti= meout
if
> >no response in a suitable period, drop a connection and reconnect<= br> when
> >it wants to? =A0These functions seem useful in any setting, rather= than
> >specific to a particular scenario.
>
> Any NETCONF engine? =A0Are you suggesting an <are-you-alive/> RP= C?

[Bing] As explained in the follow-ups mails, Tom didn't mean to suggest=
such an RPC. But I just support to have such a kind of extension to
Netconf.

I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in some a specific scenario like reverse-SSH/call
home/server/client.etc, but a quite generic requirement.
One typical scenarios is, the NMS requiring a heavy search on the router , which might cost the router a long time to process or even make the
router suspend. Then it would be good for the NMS to learn the status of the router through a periodic keep-alive, then it could close the
session without waiting until the timeout in SSH/TLS if the router
suspend.

If we agree it is a generic requirement, then I think it's better to have the keep-alive function in Netconf-level rather than in
SSH/TLS-level.
The main reason in my mind is that using SSH/TLS messages to inform
Netconf status would invoke a layering violation. SSH/TLS heartbeat
messages should only represent the status of the transport channel, and
should not represent the status of the Netconf processing.

What are your thoughts on this issue?

I do not agree a complex protocol extension is needed.
[Bing] As in my mind, it doesn't need to be complex. Just a simple
"keep-alive" indication might be sufficient.

Many implementations do not want to keep idle sessions alive.
That's why they have --idle-timeout CLI parameters.
SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax
CLI parameters to deal with this issue (in addition to TCPKeepAlive).

I want an idle session to get dropped by the server.
It is trivial to implement a no-op RPC as a client keep-alive:

[Bing] The point is, the keep-alive is just NOT for idle session, it is
for an active session.
If no Netconf keep-alives are received in a reasonable period, it means
something wrong happened in the Netconf server , then the client could
terminate the session without waiting until SSH ClientAliveCountMax. And as I said above, it might be better to de-couple the Netconf-alive and
the SSH/TLS-alive, so that the status could be more precisely
identified.

<tp>
It came as a suprise to those on the syslog list that a TCP connection
could go down, be down for hours and noone noticed so that when it was
needed to convey a critical fault, syslog was not working.

By analogy, there will be those using NETCONF who think that the
reliable transport means that when a critical alert needs to get
through, they can rely on the connection being there.

So I see keep-alives as something that the IETF should recommend for
anything involving alarms, alerts, traps, notifications etc. =A0The SNMP NMS that I am familiar with poll at regular intervals - yes, over UDP,
but I would hope they did the same over TCP, TLS, etc

Ideally, NETCONF would do this at its layer, but we are not updating
that and we are updating SSH and TLS transports thereof, so,
compromising architectural purity, I would include it at that layer pro
tem.



Why?
NETCONF does not run directly over TCP.
Why is it NETCONF's job to make sure the TCP connection stays up?<= /div>
It seems like that should be SSH or TLS doing that.
I have never seen this problem in real deployments because OpenSSH
is supposed to be configured correctly (TCPKeepAlive yes is the defaul= t).

=A0
As before, I do not see any disctinction is this regard between call
home and regular sessions.

Tom Petch

Best regards,
Bing



Andy

=A0
=A0 =A0 rpc no-op;

Clients can deal with keep-alive activity on their own.
I am not against standardizing a reasonable solution, but servers
generally support a limited number of concurrent sessions and
dropping idle sessions is a feature.


Best regards,
Bing


Andy



--089e0153705e93eeb404f8fcc1dd-- From nobody Fri May 9 12:40:02 2014 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 9F3021A0327 for ; Fri, 9 May 2014 12:39:58 -0700 (PDT) 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 z3zCAE45ud6J for ; Fri, 9 May 2014 12:39:56 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id E979A1A0308 for ; Fri, 9 May 2014 12:39:55 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id r5so5092239qcx.7 for ; Fri, 09 May 2014 12:39:50 -0700 (PDT) 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=0NWPqv3AuGY6xL7QBfmCTQPyWo01om/2w9wez/jhWYU=; b=cvmS+SFXu6W64u1yITx+yCCMF80MUOKj2KNk0gwp989lFpbsFPFWT6Hpp7EIH6jrUt WAYqIwDPCBqXFP/A4JeDWL/Y08ikKK68Fz2F++vh+4jpx68FLHLJ+rBvmkzGBupP1++Y Vlv+RUHO8i0lzB1nZAYJ7O6M+qa4LGNotZrPZldpIAUJHH9kfCO5wuy8tRt/MCMVGdS3 ODlWvc7warM/61i0KTMrIqXZpK1W2Se2jI4jHHeoxTPw1ZU5Zdpj+zLpIJjVTKJguUoJ 16ftrBkVgzML5K5ZemFMXRKMoBNrmAcfpsgy8I1hOgYHWkzLVVpQUQS03SQ35rtH5axx k7Qg== X-Gm-Message-State: ALoCoQmuW3BGSVPX6SFPs7foGUZIcpO1BTb1sticTQ8fp5WjQ+/Ag9WphUMXyjCaMTiYmgtx5vnL MIME-Version: 1.0 X-Received: by 10.224.138.3 with SMTP id y3mr17749088qat.78.1399664390790; Fri, 09 May 2014 12:39:50 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Fri, 9 May 2014 12:39:50 -0700 (PDT) In-Reply-To: <201405091935.s49JZEPt067551@idle.juniper.net> References: <201405091935.s49JZEPt067551@idle.juniper.net> Date: Fri, 9 May 2014 12:39:50 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: multipart/alternative; boundary=047d7b672b44d1769d04f8fcc26f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UiAXA5KyAfl_j3B7tngItgbXWgw Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 09 May 2014 19:39:59 -0000 --047d7b672b44d1769d04f8fcc26f Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 9, 2014 at 12:35 PM, Phil Shafer wrote: > Kent Watsen writes: > >Before debating how we do keep-alives, did we agree that we want to > support > >persistent connections? > > Aren't keep-alives a transport issue? For example SSH should use > the existing ssh keep-alives. > > +1 > Thanks, > Phil > --047d7b672b44d1769d04f8fcc26f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 9, 2014 at 12:35 PM, Phil Shafer <= phil@juniper.net&= gt; wrote:
Kent Watsen writes:
>Before debating how we do keep-alives, did we agree that we want to sup= port
>persistent connections?

Aren't keep-alives a transport issue? =A0For example SSH should use
the existing ssh keep-alives.


+1
=A0
Thanks,
=A0Phil

--047d7b672b44d1769d04f8fcc26f-- From nobody Fri May 9 14:09:18 2014 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 692C01A00D8 for ; Fri, 9 May 2014 14:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 T6BJ9a1zsL_n for ; Fri, 9 May 2014 14:08:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id AFC361A0127 for ; Fri, 9 May 2014 14:08:45 -0700 (PDT) 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.0.939.12; Fri, 9 May 2014 21:08:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) with mapi id 15.00.0939.000; Fri, 9 May 2014 21:08:37 +0000 From: Kent Watsen To: t.petch , "Bert Wijnen (IETF)" Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsro1aWgAfuBgCAAXRlEYAAS5QAgAFCeQGAAhhMgA== Date: Fri, 9 May 2014 21:08:36 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> <007201cf6a9c$aa76f980$4001a8c0@gateway.2wire.net> In-Reply-To: <007201cf6a9c$aa76f980$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.14] x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(164054003)(40224001)(199002)(189002)(92566001)(87936001)(83506001)(2656002)(86362001)(92726001)(83072002)(21056001)(76482001)(46102001)(99286001)(77982001)(101416001)(80022001)(76176999)(66066001)(54356999)(50986999)(79102001)(20776003)(81542001)(36756003)(64706001)(74662001)(74502001)(81342001)(83322001)(31966008)(4396001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <5C8EC8E32693CB40B795BA79FFA4A8F6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Ja3_QdWyk-I0LybLboIul7op6pk Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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, 09 May 2014 21:08:57 -0000 Hi Tom, Regarding the paragraph you quoted below, note that it's about more than just X.509. Specifically, there are other SSH host-key formats that can encode a unique identifier and be signed by a common trust anchor (e.g., the PGP keys from RFC 4253). I admit the text could be made better - how about this? Examples of suitable public host keys are the X.509v3 keys defined in defined in [RFC6187] and the PGP keys defined in [RFC5253]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this doesn't resolve the issue, can you also provide the text you hope to now show up in 5539bis? I see below what text is proposed to be removed from draft-ietf-netconf-reverse-ssh, but it doesn't make sense to just put that into 5539bis, what more do you hope to see in 5539bis? Thanks, Kent > >Kent > >No, I think I am not making myself clear. > >I am not saying that we need a common call home section. > >I am saying that having obtained a public key somehow, then it needs >verifying, that it is tied to the party that we are trying to >communicate with, and that that process is largely the same whether this >is call home or not. > >One form of verification is using X.509 certs, and that is the usual way >for TLS. My logic then is put everything we have to say about the use >of X.509 certs for verification in the TLS I-D and reference it from the >(reverse-)ssh I-D. The approach is the same for SSH and TLS and call >home and not call home IMHO so put it in the one place. > >Currently, reverse-ssh lacks some of the points that 5539bis makes about >the use of certs, and the base ssh RFC says nothing, but reverse-ssh has >points that 5539bis does not such as the paragraph >" Since both the identification and verification issues are addressed > using certificates, this draft RECOMMENDS network elements use a host > key that can encode a unique identifier (e.g., its serial number) and > be signed by a common trust anchor (e.g., a certificate authority). > Examples of suitable public host keys are the X.509v3 keys defined in > defined in [RFC6187]." >5539bis would be better for having that information in it alongside what >it currently has so I would move that to 5539bis leaving behind >something like > >" Since both the identification and verification issues are addressed > using certificates, this draft RECOMMENDS network elements use them - > more details can be found in [5539bis]." > >By contrast, the use of raw public keys is rare in TLS and commonplace >in SSH, so I would keep everything about that that is currently there in >reverse-ssh - mostly it is nothing to do with call home but the base ssh >RFC does not cover it so we might as well do the job properly now. > >So between them, reverse-ssh and 5539bis currently have all we need, it >is just that you have to read both in tandem to learn what you should >know. From nobody Sat May 10 04:26:40 2014 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 435771A0221 for ; Sat, 10 May 2014 04:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogPzH2Qy93xN for ; Sat, 10 May 2014 04:26:34 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9151A0217 for ; Sat, 10 May 2014 04:26:33 -0700 (PDT) Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.939.12; Sat, 10 May 2014 11:26:27 +0000 Message-ID: <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Phil Shafer References: <201405091935.s49JZEPt067551@idle.juniper.net> Date: Sat, 10 May 2014 12:23:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-ClientProxiedBy: AMSPR07CA009.eurprd07.prod.outlook.com (10.242.77.177) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Forefront-PRVS: 02070414A1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(377454003)(51704005)(164054003)(189002)(199002)(81816999)(62966002)(81542001)(87286001)(92566001)(47776003)(61296002)(85852003)(83072002)(21056001)(77156001)(80022001)(64706001)(20776003)(50466002)(81342001)(84392001)(14496001)(81686999)(50226001)(4396001)(83322001)(66066001)(50986999)(76176999)(79102001)(92726001)(19580405001)(77982001)(19580395003)(93916002)(99396002)(46102001)(44716002)(33646001)(86362001)(87976001)(31966008)(101416001)(74502001)(76482001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB059; H:DBXPRD0510HT002.eurprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NLX_YVZdTbiFp-906J1u6_SZcVQ Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 10 May 2014 11:26:38 -0000 ----- Original Message ----- From: "Phil Shafer" To: "Kent Watsen" Cc: "Andy Bierman" ; "t.petch" ; "Netconf" Sent: Friday, May 09, 2014 8:35 PM > Kent Watsen writes: > >Before debating how we do keep-alives, did we agree that we want to support > >persistent connections? > > Aren't keep-alives a transport issue? For example SSH should use > the existing ssh keep-alives. Isn't Transport Level Security a Transport issue? yet the IETF takes it upon itself to put a lot of effort into specifying how applications could and should use it; and do not do so in the Transport Area (or the Security Area)! As I have said before, there are plenty of clued-up engineers who think that a reliable TCP connection will tell them when it fails, as in the syslog WG, and were surprised to learn that that was not the case. So, knowing that, I think that we have a responsibility to document that in a reasonably obvious place. I am not suggesting that we need to create a new protocol or protocol variant if there is already one available but I do think, particuarly in the context of call home, that this is a signficant issue that we would be irresponsible to omit. And yes, I think that the rationale for call home makes persistent connections an essential option, not something that can be ignored. Tom Petch > > Thanks, > Phil From nobody Sat May 10 04:40:57 2014 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 081851A0229 for ; Sat, 10 May 2014 04:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxu4t-4UrZPd for ; Sat, 10 May 2014 04:40:52 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0011.outbound.protection.outlook.com [213.199.154.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4731A0228 for ; Sat, 10 May 2014 04:40:50 -0700 (PDT) Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.939.12; Sat, 10 May 2014 11:40:44 +0000 Message-ID: <00c301cf6c44$5876f280$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Andy Bierman References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <005101cf54b0$16a93940$4001a8c0@gateway.2wire.net> <008701cf5565$408130a0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D88838E@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D888402@nkgeml506-mbx.china.huawei.com> <00ca01cf6b67$5be6f560$4001a8c0@gateway.2wire.net> Date: Sat, 10 May 2014 12:38:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-ClientProxiedBy: AM3PR07CA003.eurprd07.prod.outlook.com (10.242.16.43) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 02070414A1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(189002)(199002)(53754006)(377454003)(13464003)(24454002)(51704005)(87286001)(64706001)(81342001)(92726001)(77982001)(19580395003)(80022001)(19580405001)(66066001)(81686999)(85852003)(86362001)(50986999)(83072002)(93916002)(20776003)(76176999)(77156001)(81816999)(87976001)(99396002)(46102001)(81542001)(561944002)(76482001)(31966008)(62966002)(61296002)(74502001)(101416001)(33646001)(92566001)(47776003)(44716002)(83322001)(14496001)(84392001)(79102001)(50226001)(4396001)(21056001)(50466002)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0510HT002.eurprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GddJZVYlVd1C6PjL7jk0gp7PE_w Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 10 May 2014 11:40:55 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Andy Bierman" ; "t.petch" Cc: "Netconf" Sent: Friday, May 09, 2014 7:58 PM Before debating how we do keep-alives, did we agree that we want to support persistent connections? Keep-alives are only needed for persistent connections, and I recall Martin questioning if persistent connections needed to be supported. My answer at the time and now is that I think persistent connections are important for call-home scenario where it's the NMS wants to send commands to the device immediately, without waiting for the device's next "periodic" connection. On the flip-side, we could take out persistent connections, and the NMS could configure the device to connect often (e.g., every 30 seconds) so that the wait isn't unnecessarily long. This may or may not fly. I don't know, but perhaps we should be conservative and define it anyways, leaving it as an option for deployments to decide if they want to use it or not. Also, Tom wrote before that we should have symmetry, not a device-side only solution. I think that the current solution is symmetric because, in the normal case where the NMS initiates the TCP connection, it already has the ability to keep the connection open as long as it likes and even send TCP/SSH/TLS-level keep-alives as it sees fit. We don't need to define a configuration model for the NC client (i.e. the NMS). We only need to define a config model for the NC server (i.e. the device). Maybe I'm misunderstanding the symmetry concern, another way of looking at it is that the current netconf-server-model only configures keep-alives under the "call-home" node (not the "listen") node. Tom, is this what you meant? Kent My experience with SNMP is that every NMS polls; if something is down, then likely, when you need the Notification most, you will not be able to get it. Some people think that this is a UDP issue. Switch to TCP and the NMS will know when things are down - err, no! So I think that NMS need keepalives, or the option of using keepalives - they may know better and dispense with them but the option should be there, and we SHOULD recommend their use - i.e. use them unless you know what you are doing and know better. The device I think is not so concerned and I would not mention it in this context, except with call home, when I think that the device SHOULD take responsibility for ensuring that a connection is there when the NMS needs it - only it can do something about it. In practice, the keep-alive protocols I am familiar with are mostly symmetric, they take it for granted that both ends have an interest in knowing what is going on and so the protocol is defined such that either or both ends can detect an outage and decide what to do. So while we are at it, that is what I would recommend; it is what I think people would expect of a keep-alive (and reusing an existing protocol if a suitable one is available which is just what SNMP does). Tom Petch Thanks, Kent From: Andy Bierman > Date: Friday, May 9, 2014 at 9:14 AM To: "t.petch" > Cc: NetConf > Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) On Fri, May 9, 2014 at 2:16 AM, t.petch > wrote: ----- Original Message ----- From: "Liubing (Leo)" > To: "Andy Bierman" > Cc: > Sent: Friday, May 09, 2014 6:05 AM Hi Andy, Thanks for your quick response. Please see replies inline. From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, May 09, 2014 10:00 AM To: Liubing (Leo) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) On Thu, May 8, 2014 at 6:20 PM, Liubing (Leo) >> wrote: Hi all, This mail is regarding to the Netconf keep-alive issue raised in several weeks ago, sorry for my late intervene to the discussion. My comment/proposal is inline. > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org>] On Behalf Of Kent > Watsen > Sent: Tuesday, April 15, 2014 3:27 AM > To: t.petch; Bert Wijnen (IETF) > Cc: netconf@ietf.org> > Subject: Re: [Netconf] periodic connections, heartbeats, reconnection ... > >Reading the details, I struggle to see why these functions should be > >tied to > > - SSH > > - TLS > > - listen > > - call home > > - NETCONF client > > - NETCONF server > >That is, why shouldn't any NETCONF engine send a heartbeat, timeout if > >no response in a suitable period, drop a connection and reconnect when > >it wants to? These functions seem useful in any setting, rather than > >specific to a particular scenario. > > Any NETCONF engine? Are you suggesting an RPC? [Bing] As explained in the follow-ups mails, Tom didn't mean to suggest such an RPC. But I just support to have such a kind of extension to Netconf. I agree with Tom that we need a heartbeat/keep-alive mechanism, not only in some a specific scenario like reverse-SSH/call home/server/client.etc, but a quite generic requirement. One typical scenarios is, the NMS requiring a heavy search on the router , which might cost the router a long time to process or even make the router suspend. Then it would be good for the NMS to learn the status of the router through a periodic keep-alive, then it could close the session without waiting until the timeout in SSH/TLS if the router suspend. If we agree it is a generic requirement, then I think it's better to have the keep-alive function in Netconf-level rather than in SSH/TLS-level. The main reason in my mind is that using SSH/TLS messages to inform Netconf status would invoke a layering violation. SSH/TLS heartbeat messages should only represent the status of the transport channel, and should not represent the status of the Netconf processing. What are your thoughts on this issue? I do not agree a complex protocol extension is needed. [Bing] As in my mind, it doesn't need to be complex. Just a simple "keep-alive" indication might be sufficient. Many implementations do not want to keep idle sessions alive. That's why they have --idle-timeout CLI parameters. SSH (OpenSSH anyway) has ClientAliveInterval and ClientAliveCountMax CLI parameters to deal with this issue (in addition to TCPKeepAlive). I want an idle session to get dropped by the server. It is trivial to implement a no-op RPC as a client keep-alive: [Bing] The point is, the keep-alive is just NOT for idle session, it is for an active session. If no Netconf keep-alives are received in a reasonable period, it means something wrong happened in the Netconf server , then the client could terminate the session without waiting until SSH ClientAliveCountMax. And as I said above, it might be better to de-couple the Netconf-alive and the SSH/TLS-alive, so that the status could be more precisely identified. It came as a suprise to those on the syslog list that a TCP connection could go down, be down for hours and noone noticed so that when it was needed to convey a critical fault, syslog was not working. By analogy, there will be those using NETCONF who think that the reliable transport means that when a critical alert needs to get through, they can rely on the connection being there. So I see keep-alives as something that the IETF should recommend for anything involving alarms, alerts, traps, notifications etc. The SNMP NMS that I am familiar with poll at regular intervals - yes, over UDP, but I would hope they did the same over TCP, TLS, etc Ideally, NETCONF would do this at its layer, but we are not updating that and we are updating SSH and TLS transports thereof, so, compromising architectural purity, I would include it at that layer pro tem. Why? NETCONF does not run directly over TCP. Why is it NETCONF's job to make sure the TCP connection stays up? It seems like that should be SSH or TLS doing that. I have never seen this problem in real deployments because OpenSSH is supposed to be configured correctly (TCPKeepAlive yes is the default). As before, I do not see any disctinction is this regard between call home and regular sessions. Tom Petch Best regards, Bing Andy rpc no-op; Clients can deal with keep-alive activity on their own. I am not against standardizing a reasonable solution, but servers generally support a limited number of concurrent sessions and dropping idle sessions is a feature. Best regards, Bing Andy From nobody Sat May 10 08:38:42 2014 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 C62CF1A000C for ; Sat, 10 May 2014 08:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 4MImBc0M9mCH for ; Sat, 10 May 2014 08:38:40 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) by ietfa.amsl.com (Postfix) with ESMTP id 79C5E1A000E for ; Sat, 10 May 2014 08:38:40 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so5911222qgd.13 for ; Sat, 10 May 2014 08:38:35 -0700 (PDT) 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=nFzTOCDwxpAtySb0DvnxrVreYx1ZrNhTTRrlu53oWEg=; b=UI8WZNHi5WqsD14EWy0zAub216XgVv3W76TkOw6Cq179tkS/NIxrWCVmSPXnyYcE4C ln2/A6pr1Cj4k5YRH8THN6U3i32urHuX64ns0oRsb8HarKwVr8NYAZm/F7ftt12ov5Xi Ke/6JLd88Q4e+YA1Vxx8aARvQ1dI7Hcc5dE8GqHBKarIARhQDVuouNmBpcrmXG49puyR fNKprsXmbrIRCrGzPjxUG0hznx+60iO3dLWUSK7Y1Jn/MI1R2BvjFgcAz+wQfcpLBbcp YMULxR0ZNB3Z4ENpgnwo9zlwkc/N+KROVgtzcXk38X5I+Qo9cS9bCdDduUNOfyZH2oGY Jd6w== X-Gm-Message-State: ALoCoQkRAJ9KA3p/Ky5wM9HZsNokAE22H6NS/B8f+MpNyO28oFfIMuMUyvaxAKTsDFL7VTI8mPF/ MIME-Version: 1.0 X-Received: by 10.229.72.10 with SMTP id k10mr24028046qcj.2.1399736315077; Sat, 10 May 2014 08:38:35 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Sat, 10 May 2014 08:38:34 -0700 (PDT) In-Reply-To: <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> Date: Sat, 10 May 2014 08:38:34 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=089e01681318d6fa2504f90d8110 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/45X8TlFdut5JwOa2H3sXX-jSt24 Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 10 May 2014 15:38:41 -0000 --089e01681318d6fa2504f90d8110 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 10, 2014 at 4:23 AM, t.petch wrote: > ----- Original Message ----- > From: "Phil Shafer" > To: "Kent Watsen" > Cc: "Andy Bierman" ; "t.petch" > ; "Netconf" > Sent: Friday, May 09, 2014 8:35 PM > > Kent Watsen writes: > > >Before debating how we do keep-alives, did we agree that we want to > support > > >persistent connections? > > > > Aren't keep-alives a transport issue? For example SSH should use > > the existing ssh keep-alives. > > Isn't Transport Level Security a Transport issue? yet the IETF takes it > upon itself to put a lot of effort into specifying how applications > could and should use it; and do not do so in the Transport Area (or the > Security Area)! > > As I have said before, there are plenty of clued-up engineers who think > that a reliable TCP connection will tell them when it fails, as in the > syslog WG, and were surprised to learn that that was not the case. > > So, knowing that, I think that we have a responsibility to document that > in a reasonably obvious place. I am not suggesting that we need to > create a new protocol or protocol variant if there is already one > available but I do think, particuarly in the context of call home, that > this is a signficant issue that we would be irresponsible to omit. > > And yes, I think that the rationale for call home makes persistent > connections an essential option, not something that can be ignored. > > SSH has its own keep-alive. NETCONF uses that. In implementation, the NETCONF layer has access to an SSH channel, not directly to a TCP socket. If the TCP connection is lost, then NETCONF relies on the SSH session and channels getting closed. If SSH cannot detect the loss of TCP, then how would NETCONF be able to do so? The SSH keep-alives are essentially the same thing as if NETCONF used the channel periodically to send a keep-alive message, so why bother replicating that functionality at the application layer? Tom Petch > > > > Thanks, > > Phil > > Andy --089e01681318d6fa2504f90d8110 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, May 10, 2014 at 4:23 AM, t.petch <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Phil Shafer" <phil@= juniper.net>
To: "Kent Watsen" <kwat= sen@juniper.net>
Cc: "Andy Bierman" <andy= @yumaworks.com>; "t.petch"
<ietfc@btconnect.com>; &qu= ot;Netconf" <netconf@ietf.org>
Sent: Friday, May 09, 2014 8:35 PM
> Kent Watsen writes:
> >Before debating how we do keep-alives, did we agree that we want t= o
support
> >persistent connections?
>
> Aren't keep-alives a transport issue? =A0For example SSH should us= e
> the existing ssh keep-alives.

Isn't Transport Level Security a Transport issue? =A0yet the IETF takes= it
upon itself to put a lot of effort into specifying how applications
could and should use it; and do not do so in the Transport Area (or the
Security Area)!

As I have said before, there are plenty of clued-up engineers who think
that a reliable TCP connection will tell them when it fails, as in the
syslog WG, and were surprised to learn that that was not the case.

So, knowing that, I think that we have a responsibility to document that in a reasonably obvious place. =A0I am not suggesting that we need to
create a new protocol or protocol variant if there is already one
available but I do think, particuarly in the context of call home, that
this is a signficant issue that we would be irresponsible to omit.

And yes, I think that the rationale for call home makes persistent
connections an essential option, not something that can be ignored.



TCP connection is lost, then NETCONF relies on the SSH session
and channels getting closed. =A0If SSH cannot detect the loss of TCP,
then how would NETCONF be able to do so?=A0

The SSH keep-alives are essentially the same thing as if NETCONF
bother replicating that functionality at the application layer?


Tom Petch
>
> Thanks,
> =A0Phil


Andy

--089e01681318d6fa2504f90d8110-- From nobody Mon May 12 02:43:32 2014 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 32C5F1A065D for ; Mon, 12 May 2014 02:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSO2sSBxfoK5 for ; Mon, 12 May 2014 02:43:29 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0078.outbound.protection.outlook.com [213.199.154.78]) by ietfa.amsl.com (Postfix) with ESMTP id 733551A065F for ; Mon, 12 May 2014 02:43:28 -0700 (PDT) Received: from DBXPRD0610HT005.eurprd06.prod.outlook.com (157.56.252.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.939.12; Mon, 12 May 2014 09:43:21 +0000 Message-ID: <00a801cf6dc6$45f881e0$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <201405091935.s49JZEPt067551@idle.juniper.net><00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> Date: Mon, 12 May 2014 10:40:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DBXPR07CA015.eurprd07.prod.outlook.com (10.141.8.173) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 0209425D0A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(189002)(199002)(51444003)(377454003)(13464003)(24454002)(57704003)(51704005)(81342001)(64706001)(81686999)(86362001)(81816999)(42186004)(66066001)(92726001)(87286001)(93916002)(76176999)(83072002)(50986999)(85852003)(77156001)(87976001)(46102001)(99396002)(20776003)(19580395003)(88136002)(81542001)(77982001)(76482001)(31966008)(62966002)(61296002)(74502001)(74662001)(101416001)(33646001)(92566001)(47776003)(44716002)(23756003)(4396001)(50466002)(21056001)(19580405001)(62236002)(84392001)(50226001)(80022001)(79102001)(14496001)(83322001)(89996001)(44736004)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0610HT005.eurprd06.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xU2CvGDfDgciQRxnCZ_MJyw1qMI Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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, 12 May 2014 09:43:32 -0000 ---- Original Message ----- From: "Andy Bierman" To: "t.petch" Cc: "Kent Watsen" ; "Phil Shafer" ; "Netconf" Sent: Saturday, May 10, 2014 4:38 PM > On Sat, May 10, 2014 at 4:23 AM, t.petch wrote: > > > ----- Original Message ----- > > From: "Phil Shafer" > > To: "Kent Watsen" > > Cc: "Andy Bierman" ; "t.petch" > > ; "Netconf" > > Sent: Friday, May 09, 2014 8:35 PM > > > Kent Watsen writes: > > > >Before debating how we do keep-alives, did we agree that we want to > > support > > > >persistent connections? > > > > > > Aren't keep-alives a transport issue? For example SSH should use > > > the existing ssh keep-alives. > > > > Isn't Transport Level Security a Transport issue? yet the IETF takes it > > upon itself to put a lot of effort into specifying how applications > > could and should use it; and do not do so in the Transport Area (or the > > Security Area)! > > > > As I have said before, there are plenty of clued-up engineers who think > > that a reliable TCP connection will tell them when it fails, as in the > > syslog WG, and were surprised to learn that that was not the case. > > > > So, knowing that, I think that we have a responsibility to document that > > in a reasonably obvious place. I am not suggesting that we need to > > create a new protocol or protocol variant if there is already one > > available but I do think, particuarly in the context of call home, that > > this is a signficant issue that we would be irresponsible to omit. > > > > And yes, I think that the rationale for call home makes persistent > > connections an essential option, not something that can be ignored. > > SSH has its own keep-alive. NETCONF uses that. > In implementation, the NETCONF layer has access to > an SSH channel, not directly to a TCP socket. If the > TCP connection is lost, then NETCONF relies on the SSH session > and channels getting closed. If SSH cannot detect the loss of TCP, > then how would NETCONF be able to do so? > > The SSH keep-alives are essentially the same thing as if NETCONF > used the channel periodically to send a keep-alive message, so why > bother replicating that functionality at the application layer? If the functionality is there and meets the requirements, then use it! Kent was stepping back a little and asking as a matter of principle, do we need keep-alives? Yes. Looking at the four ends of a connection, NMS and device, call home and normal, IMHO, the most important case is 'device call home' but I think that 'NMS normal' is not far behind. 'NMS call home' is interesting because it can do nothing about it, but is again signficant. 'device normal' would be the lowest priority of the four - I would expect such a device to log the failure and wait for the connection to be resumed but I would still want that to happen. But my starting point would be to RECOMMEND all four, unless there are onerous technical difficulties in doing so, in which case I would apply the priorities above to revisit that recommendation. I think that persistence is a subjective concept. Keeping a connection up for an hour might be persistent for some, for me persistence would cover more like a shift, a day or a month, and it is these sorts of timescales that I am used to seeing with NMS. Tom Petch > > > > > > Thanks, > > > Phil > > > Andy From nobody Mon May 12 04:34:45 2014 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 73E981A067A for ; Mon, 12 May 2014 04:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHx5FQKOj2BM for ; Mon, 12 May 2014 04:34:40 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) by ietfa.amsl.com (Postfix) with ESMTP id A01E81A0675 for ; Mon, 12 May 2014 04:34:39 -0700 (PDT) Received: from DBXPRD0610HT003.eurprd06.prod.outlook.com (157.56.252.181) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.0.939.12; Mon, 12 May 2014 11:34:32 +0000 Message-ID: <00da01cf6dd5$ce36e740$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Bert Wijnen (IETF)" References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> <007201cf6a9c$aa76f980$4001a8c0@gateway.2wire.net> Date: Mon, 12 May 2014 12:29:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DB4PR07CA024.eurprd07.prod.outlook.com (10.242.229.34) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) X-Forefront-PRVS: 0209425D0A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(189002)(164054003)(199002)(377454003)(40224001)(13464003)(19580395003)(77982001)(92726001)(19580405001)(76482001)(79102001)(76176999)(62236002)(42186004)(99396002)(31966008)(74502001)(44716002)(101416001)(87976001)(46102001)(33646001)(86362001)(50226001)(93916002)(61296002)(81686999)(85852003)(81816999)(81542001)(62966002)(87286001)(64706001)(20776003)(14496001)(74662001)(89996001)(81342001)(88136002)(83322001)(47776003)(50986999)(92566001)(66066001)(23756003)(4396001)(80022001)(50466002)(83072002)(77156001)(21056001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB059; H:DBXPRD0610HT003.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/mzZweAc8h5Wh4eb-UxAp2NF2gZk Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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, 12 May 2014 11:34:43 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Bert Wijnen (IETF)" Cc: Sent: Friday, May 09, 2014 10:08 PM Hi Tom, Regarding the paragraph you quoted below, note that it's about more than just X.509. Specifically, there are other SSH host-key formats that can encode a unique identifier and be signed by a common trust anchor (e.g., the PGP keys from RFC 4253). I admit the text could be made better - how about this? Examples of suitable public host keys are the X.509v3 keys defined in defined in [RFC6187] and the PGP keys defined in [RFC5253]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Kent This is where we start to part company. A host key is a host key, it is public, it is generated for me as part of a key pair for use in public key cryptography. Of itself, it conveys nothing, no verification, no validation, no identification. It only acquires value when it can be tied into an identity or identifier, which X.509 certificates do. Or it can preconfigured into the NMS (the key or a fingerprint thereof) but is the act of configuring that gives the key some value, there is nothing inherent in the key. You say in the I-D that this does not scale, but that is true of (almost) everything. If you use X.509 certificates, then they bind the key to an identity; guess what, that identity has to be configured into the NMS, so if configuring raw keys does not scale then neither do X.509 certificates:-( The only thing that scales is Trust On First Use, which I think too flaky for us to recommend. Manual acceptance when a key is first used is more secure, but, arguably, scales no better. We have been here before - look at RFC5592, which basically says 'preconfigure host keys' to which I would now add 'or else use certificates', RFC6125 etc. So my section 5 (skating over PGP use) would be more like "When the management system accepts a new incoming TCP connection on the NETCONF over SSH Call Home port, it starts the SSH client protocol. As the SSH client, it MUST authenticate the SSH server, by both identifying the network element and verifying its SSH host key. When not using call home, the management system initiates the TCP connection and so may place some reliance on the fact that the device that responds is the one that it is configured to communicate with. With call home, the network element initiates the TCP connection and no reliance can be placed on the source IP address of the TCP connection. Identifying the remote peer by its source IP address, as recommended in [RFC6187] is NOT RECOMMENDED in the case of call home, unless the network takes steps to validate IP source addresses. The management system may be configured with the host keys of the network elements, or fingerprints thereof, and these MAY be used as an identifier. The management system MAY request manually verification of a host key or a fingerprint thereof the first time the network element connects, and any time the host key changes thereafter. Digital certificates, such as those in X.509 version 3 (X.509v3) bind a public key to a digital identity [RFC5280] and are used in many environments for identity management. This approach is discussed in more detail in [5539bis]; this approach is RECOMMENDED." Tom Petch If this doesn't resolve the issue, can you also provide the text you hope to now show up in 5539bis? I see below what text is proposed to be removed from draft-ietf-netconf-reverse-ssh, but it doesn't make sense to just put that into 5539bis, what more do you hope to see in 5539bis? Thanks, Kent > >Kent > >No, I think I am not making myself clear. > >I am not saying that we need a common call home section. > >I am saying that having obtained a public key somehow, then it needs >verifying, that it is tied to the party that we are trying to >communicate with, and that that process is largely the same whether this >is call home or not. > >One form of verification is using X.509 certs, and that is the usual way >for TLS. My logic then is put everything we have to say about the use >of X.509 certs for verification in the TLS I-D and reference it from the >(reverse-)ssh I-D. The approach is the same for SSH and TLS and call >home and not call home IMHO so put it in the one place. > >Currently, reverse-ssh lacks some of the points that 5539bis makes about >the use of certs, and the base ssh RFC says nothing, but reverse-ssh has >points that 5539bis does not such as the paragraph >" Since both the identification and verification issues are addressed > using certificates, this draft RECOMMENDS network elements use a host > key that can encode a unique identifier (e.g., its serial number) and > be signed by a common trust anchor (e.g., a certificate authority). > Examples of suitable public host keys are the X.509v3 keys defined in > defined in [RFC6187]." >5539bis would be better for having that information in it alongside what >it currently has so I would move that to 5539bis leaving behind >something like > >" Since both the identification and verification issues are addressed > using certificates, this draft RECOMMENDS network elements use them - > more details can be found in [5539bis]." > >By contrast, the use of raw public keys is rare in TLS and commonplace >in SSH, so I would keep everything about that that is currently there in >reverse-ssh - mostly it is nothing to do with call home but the base ssh >RFC does not cover it so we might as well do the job properly now. > >So between them, reverse-ssh and 5539bis currently have all we need, it >is just that you have to read both in tandem to learn what you should >know. From nobody Mon May 12 09:37:52 2014 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 94D901A0759 for ; Mon, 12 May 2014 09:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 dSEL45xJK4mx for ; Mon, 12 May 2014 09:37:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by ietfa.amsl.com (Postfix) with ESMTP id 765FD1A0757 for ; Mon, 12 May 2014 09:37:47 -0700 (PDT) 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.0.939.12; Mon, 12 May 2014 16:37:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) with mapi id 15.00.0939.000; Mon, 12 May 2014 16:37:38 +0000 From: Kent Watsen To: t.petch , "Bert Wijnen (IETF)" Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsro1aWgAfuBgCAAXRlEYAAS5QAgAFCeQGAAhhMgIAEWebjgAARYgA= Date: Mon, 12 May 2014 16:37:38 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> <007201cf6a9c$aa76f980$4001a8c0@gateway.2wire.net> <00da01cf6dd5$ce36e740$4001a8c0@gateway.2wire.net> In-Reply-To: <00da01cf6dd5$ce36e740$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.13] x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(164054003)(199002)(189002)(99286001)(92566001)(2656002)(46102001)(76176999)(54356999)(83072002)(85852003)(31966008)(83506001)(86362001)(87936001)(50986999)(99396002)(81542001)(101416001)(81342001)(74662001)(92726001)(74502001)(77982001)(4396001)(83322001)(21056001)(76482001)(79102001)(64706001)(66066001)(80022001)(36756003)(20776003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6041216AAFDEAF43B23683E7E5E75899@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/u3OhbK2UpwpM-fW3DElEEhAGTXw Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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, 12 May 2014 16:37:50 -0000 Hi Tom, >This is where we start to part company. A host key is a host key, it is >public, it is generated for me as part of a key pair for use in public >key cryptography. Of itself, it conveys nothing, no verification, no >validation, no identification. > >It only acquires value when it can be tied into an identity or >identifier, which X.509 certificates do. Or it can preconfigured into >the NMS (the key or a fingerprint thereof) but is the act of configuring >that gives the key some value, there is nothing inherent in the key. RFC 4251 section 4.1 on "Host Keys" extends the definition to include certificates too.=20 >You say in the I-D that this does not scale, but that is true of >(almost) everything. If you use X.509 certificates, then they bind the >key to an identity; guess what, that identity has to be configured into >the NMS, so if configuring raw keys does not scale then neither do X.509 >certificates:-( Yes, the NMS needs to be programed with the identity of the CA, but that one CA can vouch for any number of devices. This *is* scalable, from the NMS's POV. What is potentially not scalable, is the need to provision each device with a signed certificate, as the na=EFve solution would again be per-device, though it has the up-side that the certificate-provisioning could be delegated to a 3rd-party, leveraging PKI to its fullest. However, any solution that needs the device to be "touched" before being put into commission is not ideal. The only no-touch solution I know of is for the device to already have a signed-certificate when released from its manufacturer's factory. This is the strategy is codified in the zero-touch draft. >The only thing that scales is Trust On First Use, which I think too >flaky for us to recommend. Manual acceptance when a key is first used >is more secure, but, arguably, scales no better. Agreed, TOFU is not ideal. >We have been here before - look at RFC5592, which basically says >'preconfigure host keys' to which I would now add 'or else use >certificates', RFC6125 etc. > >So my section 5 (skating over PGP use) would be more like > >"When the management system accepts a new incoming TCP connection on the >NETCONF over SSH Call Home port, it starts the SSH client protocol. As >the SSH client, it MUST authenticate the SSH server, by both identifying >the network element and verifying its SSH host key. > >When not using call home, the management system initiates the TCP >connection and so may place some reliance on the fact that the device >that responds is the one that it is configured to communicate with. >With call home, the network element initiates the TCP connection and no >reliance can be placed on the source IP address of the TCP connection. >Identifying the remote peer by its source IP address, as recommended in >[RFC6187] is NOT RECOMMENDED in the case of call home, unless the >network takes steps to validate IP source addresses. > >The management system may be configured with the host keys of the >network elements, or fingerprints thereof, and these MAY be used as an >identifier. > >The management system MAY request manually verification of a host key or >a fingerprint thereof the first time the network element connects, and >any time the host key changes thereafter. > >Digital certificates, such as those in X.509 version 3 (X.509v3) bind a >public key to a digital identity [RFC5280] and are used in many >environments for identity management. This approach is discussed in >more detail in [5539bis]; this approach is RECOMMENDED." This text is almost the same as what is there now. One thing different is I don't see the word "scale" anymore. So you want 5539bis to say PKI is scalable and hence particularly suitable for NMS and then have this draft reference it for that fact? You didn't provide text for 5539bis, so I'm just guessing, is there anything else? Thanks, Kent From nobody Mon May 12 15:49:25 2014 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 630BE1A07A7 for ; Mon, 12 May 2014 15:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 SBRv3LNtUNsb for ; Mon, 12 May 2014 15:49:23 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8F1A07A4 for ; Mon, 12 May 2014 15:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=166; q=dns/txt; s=iport; t=1399934957; x=1401144557; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=1Z8Q3mx6JuQMCqEuMPOi4DF116M44FLc6n1SunQgWpw=; b=NqxgYPHImZqxTYAye6Qkj23DHLtgV8drFkaC4tl5XHQFUQlykEpAC70s hhoSTaYy0W7KGLIZ1XHt2KiAVrd9eUdaXgrHa1puyqatksACNyGQuu9Gs IAQLNAlwxXaL2Qy/TAsjlYJUBNSKxamg/g7yuM0bLC9SBcOerHf6gx1h/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFALROcVOtJV2R/2dsb2JhbABZgwZPjU+4coEjFnSCZEA9FhgDAgECAUsNCAEBiD0NnFizXheTGQSKD485gTyFKYwigXeBXx0 X-IronPort-AV: E=Sophos;i="4.97,1038,1389744000"; d="scan'208";a="321288747" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP; 12 May 2014 22:49:17 +0000 Received: from [10.154.137.143] (dhcp-10-154-137-143.cisco.com [10.154.137.143]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4CMnGLu026752 for ; Mon, 12 May 2014 22:49:16 GMT Message-ID: <53714FEC.2030709@cisco.com> Date: Mon, 12 May 2014 15:49:16 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/EcuRMEArnLQfCWsvqVZJ3XBoGhg Subject: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) 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, 12 May 2014 22:49:24 -0000 Dear all, Please review the http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-04 BCP in light of RESTCONF and let me know. Regards, Benoit From nobody Mon May 12 16:06:15 2014 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 821BA1A07B2 for ; Mon, 12 May 2014 16:06:11 -0700 (PDT) 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 jlAzdAOIwuEV for ; Mon, 12 May 2014 16:06:10 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id CABE21A07B3 for ; Mon, 12 May 2014 16:06:09 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e16so8754727qcx.27 for ; Mon, 12 May 2014 16:06:03 -0700 (PDT) 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=c0Kc54sAmlqL/oiaL/YZ0wBIKd0gRqZNQ3XoFVKqabI=; b=TI2CW4/0ysUNNOLDWWPLi+SoGvQOdNxMJCqq6wkV7/W1y/JgaZ68BI1YFIjhn7e6QP xwWOslzDtv7fmVVp5KDfz8ZSf5pAbPX6WwuxPrDED3nkZfhkwtM1dbYm9u9/KTeNzrKT yd9l+kGDszu0UhywWsdNBos+q4l25AQ+bIiJMFHIeZ4zRnWyWSIFRwLB07pXcbQsjTKU DpaukznreCCDK+DcxHijknUNz9r1nLKuyNCb1Ur2rUnzUPlW9Dsk3DP8BEzsMeOY43HI RZIZPYC25vLqxP78Gqiydj+E6biQy93X+v0GPwGAxTphD9pT5vvFEq1y/jVMrw+hvqud jwcg== X-Gm-Message-State: ALoCoQmv8mlsWjzIfDC0BbvaGeGHXL+xwbQGuNqppVe1PSB2lbYE7FcGqAxbkXMOrEUY/Kz40KnD MIME-Version: 1.0 X-Received: by 10.140.36.105 with SMTP id o96mr40483903qgo.25.1399935963629; Mon, 12 May 2014 16:06:03 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 12 May 2014 16:06:03 -0700 (PDT) In-Reply-To: <53714FEC.2030709@cisco.com> References: <53714FEC.2030709@cisco.com> Date: Mon, 12 May 2014 16:06:03 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c17334d22eb404f93bfdec Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Ybc6khH7-sOisxQOWgZ4f8Twdss Cc: NETCONF Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) 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, 12 May 2014 23:06:11 -0000 --001a11c17334d22eb404f93bfdec Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 12, 2014 at 3:49 PM, Benoit Claise wrote: > Dear all, > > Please review the http://tools.ietf.org/html/draft-ietf-appsawg-uri-get- > off-my-lawn-04 BCP in light of RESTCONF and let me know. > > I think RESTCONF violates sec 2.3 wrt/ structure within the URI path. This is by design. The document complains about ad-hoc mechanisms, and RESTCONF is in complete agreement with that. The RESTCONF mapping of data nodes to resource identifiers is the opposite of ad-hoc. It allows multi-vendor naming without collisions and dramatically improved application efficiency. (It is arguable that configuration management of complex routers would be impossible with a robust schema language like YANG). Regards, Benoit > > Andy --001a11c17334d22eb404f93bfdec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, May 12, 2014 at 3:49 PM, Benoit Claise &l= t;bclaise@cisco.com<= /a>> wrote:
Dear all,

Please review the http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-04 BCP in light of RESTC= ONF and let me know.



I think RESTCONF violat= es sec 2.3 wrt/ structure within the URI path.
This is by design.= =A0The document complains about ad-hoc mechanisms,
and RESTCONF = is in complete agreement with that. =A0The RESTCONF
mapping of data nodes to resource identifiers is the opposite of ad-ho= c.
It allows multi-vendor naming without collisions and dramatica= lly
improved application efficiency. =A0(It is arguable that conf= iguration management
of complex routers would be impossible with a robust schema language
like YANG).


Regards, Benoit


Andy
=A0
--001a11c17334d22eb404f93bfdec-- From nobody Mon May 12 17:40:26 2014 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 98F341A07D4 for ; Mon, 12 May 2014 17:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ez44dXeiJYqm for ; Mon, 12 May 2014 17:40:22 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2AD1A07D0 for ; Mon, 12 May 2014 17:40:22 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id 63so8727371qgz.30 for ; Mon, 12 May 2014 17:40:16 -0700 (PDT) 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=BCSgcJZeeFXrsdmjEy/n9wvkriOzfKKVhJ/Gy7zafIA=; b=PbTYIzGA0zSyMVRdUEA3YMMzmazz7puVIdQ52ZtD1OM0r8RbwcVFG/d6FBZlxbGn5m 0i4LnS3qOYGguyOzmKuRczdtCrHrHqt3JFPcuYAyq8qTuhWvGdcepmaFOP0/Yeae3+yH /SXxBMN7Q3pklgkOrlLPsQpp6FgbgzJV7Ct8x9J/1rWiiFqEJY/tgW5DIs6o2yOb8V2k 73YWsQPWiaVFmA3QbARcYJPfaJiss0YeSRB+PGH8Nc5U/m5Yfj9x6+ISn5Au9pzqkZsk TVyZLWqPrlef1IgdiHhtx5V0bbiZzIpfiYg7XSeCH61IkEUUoNfmiA4YIB+1Wub7EEqy TQgw== X-Gm-Message-State: ALoCoQm8xJPHz2GOVGfJzW/3M5kPhSIuREgEZlOio9R0jw6lbwSI+LdSGxHxGyrjeahSN6DP6U7d MIME-Version: 1.0 X-Received: by 10.140.41.75 with SMTP id y69mr40638639qgy.34.1399941616017; Mon, 12 May 2014 17:40:16 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Mon, 12 May 2014 17:40:15 -0700 (PDT) In-Reply-To: References: <53714FEC.2030709@cisco.com> Date: Mon, 12 May 2014 17:40:15 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c126babab8ee04f93d4e05 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/IhOtIYBzSvvfuzEto1t6cOeJG9A Cc: NETCONF Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) 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, 13 May 2014 00:40:24 -0000 --001a11c126babab8ee04f93d4e05 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 12, 2014 at 4:06 PM, Andy Bierman wrote: > > > > On Mon, May 12, 2014 at 3:49 PM, Benoit Claise wrote: > >> Dear all, >> >> Please review the http://tools.ietf.org/html/draft-ietf-appsawg-uri-get- >> off-my-lawn-04 BCP in light of RESTCONF and let me know. >> >> > > I think RESTCONF violates sec 2.3 wrt/ structure within the URI path. > This is by design. The document complains about ad-hoc mechanisms, > and RESTCONF is in complete agreement with that. The RESTCONF > mapping of data nodes to resource identifiers is the opposite of ad-hoc. > It allows multi-vendor naming without collisions and dramatically > improved application efficiency. (It is arguable that configuration > management > of complex routers would be impossible with a robust schema language > oops -- s/with/without/ in previous line > like YANG). > > > Regards, Benoit >> >> > Andy > > --001a11c126babab8ee04f93d4e05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, May 12, 2014 at 4:06 PM, Andy Bierman <= ;andy@yumaworks.com= > wrote:



On Mon, May 12, 2014 at 3:49 PM, Ben= oit Claise <bclaise@cisco.com> wrote:
Dear all,

Please review the http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-04 BCP in light of RESTC= ONF and let me know.



I think RESTCONF violat= es sec 2.3 wrt/ structure within the URI path.
This is by design.= =A0The document complains about ad-hoc mechanisms,
and RESTCONF = is in complete agreement with that. =A0The RESTCONF
mapping of data nodes to resource identifiers is the opposite of ad-ho= c.
It allows multi-vendor naming without collisions and dramatica= lly
improved application efficiency. =A0(It is arguable that conf= iguration management
of complex routers would be impossible with a robust schema language

oops -- s/with/witho= ut/ in previous line
=A0
like YANG).


Regards, Benoit


Andy
=A0

--001a11c126babab8ee04f93d4e05-- From nobody Tue May 13 11:53:21 2014 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 8A0E91A00E3 for ; Tue, 13 May 2014 11:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 phjUHlT5DH4F for ; Tue, 13 May 2014 11:53:18 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id E88021A0096 for ; Tue, 13 May 2014 11:53:17 -0700 (PDT) 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.0.939.12; Tue, 13 May 2014 18:53:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.115]) with mapi id 15.00.0939.000; Tue, 13 May 2014 18:53:09 +0000 From: Kent Watsen To: Andy Bierman , Benoit Claise Thread-Topic: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) Thread-Index: AQHPbjTesrzdWmo2rkmRPyjc5i2Otps9kRSAgAAaUoCAAO5HgA== Date: Tue, 13 May 2014 18:53:07 +0000 Message-ID: References: <53714FEC.2030709@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.1.140326 x-originating-ip: [66.129.241.13] x-forefront-prvs: 0210479ED8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(17383004)(189002)(199002)(16813002)(74502001)(81342001)(36756003)(86362001)(81542001)(64706001)(31966008)(87936001)(4396001)(92726001)(20776003)(77982001)(16236675002)(83506001)(66066001)(76482001)(21056001)(79102001)(80022001)(50986999)(83322001)(46102001)(85852003)(83072002)(2656002)(99396002)(101416001)(76176999)(92566001)(74662001)(54356999)(166863002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: multipart/alternative; boundary="_000_CF97DDB16FB67kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6Mt7Rw0GVxX0qMzejtl5nmOkzDw Cc: NETCONF Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) 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, 13 May 2014 18:53:20 -0000 --_000_CF97DDB16FB67kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy writes: I think RESTCONF violates sec 2.3 wrt/ structure within the URI path. I agree with Andy that RESTCONF violates section 2.3. I also think that we= can remove that violation by supporting "well-known" URIs. Notice that th= e 2nd paragraph in section 2.3 says "The only exception to this requirement= is registered 'well-known' URIs, as specified by [RFC5785]." My reading = is, if we use a "well-known" URI, then our subtree can defined sub-structur= e per RESTCONF convention. We discussed using well-known URIs before. Appendix B.3. in the RESTCONF = draft ("Open Issues") regards ".well-known usage". This issue was closed w= ith the resolution "not needed in RESTCONF". We may need to revisit that = decision now. Thanks, Kent --_000_CF97DDB16FB67kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <33F6D8316CA438438034538F9E337422@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Andy writes:
I think RESTCONF violates sec 2.3 wrt/ structure within the URI path.<= /div>
<snip/>

I agree with Andy that RESTCONF violates section 2.3.  I also thi= nk that we can remove that violation by supporting "well-known" U= RIs.  Notice that the 2nd paragraph in section 2.3 says "The only= exception to this requirement is registered 'well-known' URIs, as specified by [RFC5785]."   My reading is, if we use a &= quot;well-known" URI, then our subtree can defined sub-structure per R= ESTCONF convention.

We discussed using well-known URIs before.   Appendix B.3. in the= RESTCONF draft ("Open Issues") regards ".well-known usage&q= uot;.  This issue was closed with the resolution "not needed in R= ESTCONF".   We may need to revisit that decision now.

Thanks,
Kent

--_000_CF97DDB16FB67kwatsenjunipernet_-- From nobody Tue May 13 12:03:59 2014 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 CE17B1A0146 for ; Tue, 13 May 2014 12:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 opVejWnI5kZH for ; Tue, 13 May 2014 12:03:57 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) by ietfa.amsl.com (Postfix) with ESMTP id 624C51A0164 for ; Tue, 13 May 2014 12:03:56 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id i50so1033146qgf.17 for ; Tue, 13 May 2014 12:03:49 -0700 (PDT) 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=1UuqEgfgwQ53wNF/v9QuZKXGbrPMeDJJhsOkQI/scgQ=; b=WXVrw+UKIF4UOSXnZl5N9SvW3H5F1jJEXUMdQ5YugujLACFObRF6olPV59JpC0cUT2 Bm88zkDnhJMqd0y6wvx71eValfvKp5bFsWjii8B2IOlW8HJGbmfNV5YakPHoVDjO4VgI 3uAib7xdlrcrQpYaRyFy+/jqTv2PGDs5QumCBEXvAhY8ztn/chEwdemyfv2b0YqoqO9q dxX6opeIP3Dvg4ky5/A3IZEneDDBdxgLqZ+g9e/NPQju9urGQzQj7YCqcqhbeGMwa8ib dGIQ41WruspAt1uYSteoS6g36R3V19Jt5mbOLiAiBVwEjUyH53qUAvzmm+xF5E/DZx5n hoxg== X-Gm-Message-State: ALoCoQmG43UwQ7IOEQFyL2rqIC+fBm/9+8qpKuq6rw2ek5AwCTqjh5SP4XE8VFCsrWI/oi2qOuXO MIME-Version: 1.0 X-Received: by 10.140.27.45 with SMTP id 42mr37577240qgw.94.1400007829830; Tue, 13 May 2014 12:03:49 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Tue, 13 May 2014 12:03:49 -0700 (PDT) In-Reply-To: References: <53714FEC.2030709@cisco.com> Date: Tue, 13 May 2014 12:03:49 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c152f461577c04f94cb98b Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/EsErvwrhIHRwr0ROvH7JnnBoyPc Cc: NETCONF Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) 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, 13 May 2014 19:03:59 -0000 --001a11c152f461577c04f94cb98b Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 13, 2014 at 11:53 AM, Kent Watsen wrote: > > Andy writes: > >> I think RESTCONF violates sec 2.3 wrt/ structure within the URI path. >> > > > I agree with Andy that RESTCONF violates section 2.3. I also think that > we can remove that violation by supporting "well-known" URIs. Notice that > the 2nd paragraph in section 2.3 says "The only exception to this > requirement is registered 'well-known' URIs, as specified by [RFC5785]." > My reading is, if we use a "well-known" URI, then our subtree can defined > sub-structure per RESTCONF convention. > > We discussed using well-known URIs before. Appendix B.3. in the > RESTCONF draft ("Open Issues") regards ".well-known usage". This issue was > closed with the resolution "not needed in RESTCONF". We may need to > revisit that decision now. > > I agree we need to support .well-known to conform to this BCP. > Thanks, > Kent > > Andy --001a11c152f461577c04f94cb98b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, May 13, 2014 at 11:53 AM, Kent Watsen <= ;kwatsen@juniper.n= et> wrote:

Andy writes:
I think RESTCONF violates sec 2.3 wrt/ structure within the URI path.<= /div>
<snip/>

I agree with Andy that RESTCONF violates section 2.3. =A0I also think = that we can remove that violation by supporting "well-known" URIs= . =A0Notice that the 2nd paragraph in section 2.3 says "The only excep= tion to this requirement is registered 'well-known' URIs, as specified by [RFC5785]." =A0 My reading is, if we use a &quo= t;well-known" URI, then our subtree can defined sub-structure per REST= CONF convention.

We discussed using well-known URIs before. =A0 Appendix B.3. in the RE= STCONF draft ("Open Issues") regards ".well-known usage"= ;. =A0This issue was closed with the resolution "not needed in RESTCON= F". =A0 We may need to revisit that decision now.


I agree we need to su= pport .well-known to conform to this BCP.
=A0
Thanks,
Kent


Andy

--001a11c152f461577c04f94cb98b-- From nobody Tue May 13 15:34:05 2014 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 5A1A61A024C for ; Tue, 13 May 2014 15:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fpTg-biCVqsC for ; Tue, 13 May 2014 15:33:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id 582AF1A0123 for ; Tue, 13 May 2014 15:33:54 -0700 (PDT) Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB454.namprd05.prod.outlook.com (10.141.59.17) with Microsoft SMTP Server (TLS) id 15.0.939.12; Tue, 13 May 2014 22:33:46 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.208]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.204]) with mapi id 15.00.0939.000; Tue, 13 May 2014 22:33:45 +0000 From: Kent Watsen To: t.petch Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsro1aWgAfuBgCAAXRlEYAAS5QAgAFCeQGAAhhMgIAEWebjgAARYgCAAfXVgA== Date: Tue, 13 May 2014 22:33:44 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> <007201cf6a9c$aa76f980$4001a8c0@gateway.2wire.net> <00da01cf6dd5$ce36e740$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.13] x-forefront-prvs: 0210479ED8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(189002)(199002)(4396001)(54356999)(36756003)(64706001)(99396002)(86362001)(92566001)(83506001)(21056001)(76176999)(20776003)(77982001)(83322001)(92726001)(79102001)(99286001)(76482001)(46102001)(66066001)(85852003)(50986999)(74502001)(81542001)(74662001)(80022001)(87936001)(83072002)(101416001)(81342001)(2656002)(31966008); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB454; H:BN1PR05MB456.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <5CAFBFDE61A7F048A2379E2AD85910C7@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FRN6FcqXRUf_sjvkjYX1HqokrHs Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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: Tue, 13 May 2014 22:33:58 -0000 Hi Tom,=20 I think we should close this discussion with resolution of not moving any text to 5539bis. =20 I would be OK moving text to a generic "call home" draft, but the WG already decided against that approach. Too bad, as there is quite a bit in addition to S.5; for instance, look at S.3 "Benefits to Device Management" and parts of S.7 "Security Considerations". All of it seems to apply to nearly any call-home solution. Oh well. If you recall, this thread began by your saying reverse-ssh wasn't ready for LC. Since then, we've: - changed all the "reverse ssh" references to "call home" - updated the abstract and introduction sections - added that PGP keys also satisfy the RECOMMENDED key algorithm criteria - clarified why a device config model is out of scope (e.g., Informative) =20 But this last bit about moving text to 5539bis seems questionable and not worth it discussing further. So, can we agree to close this particular discussion now? If so, then I'll post -06 so the draft can enter LC again. Thanks, Kent From nobody Tue May 13 22:56:59 2014 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 E56931A022F for ; Tue, 13 May 2014 22:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 BCH9ysuwuy1P for ; Tue, 13 May 2014 22:56:52 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 59BC31A0233 for ; Tue, 13 May 2014 22:56:52 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id D9AC527452 for ; Wed, 14 May 2014 13:56:32 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 9F527725B2B for ; Wed, 14 May 2014 13:56:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s4E5uWQt033888 for ; Wed, 14 May 2014 13:56:32 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) To: netconf@ietf.org MIME-Version: 1.0 X-KeepSent: 1BC71EEA:488125E6-48257CD8:001E91D9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Wed, 14 May 2014 13:56:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-05-14 13:56:34, Serialize complete at 2014-05-14 13:56:34 Content-Type: multipart/alternative; boundary="=_alternative 0020A4E348257CD8_=" X-MAIL: mse02.zte.com.cn s4E5uWQt033888 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/vWDty8m3y1r9n9rjJ3gTgR5bvJ8 Cc: ye.xu1@zte.com.cn Subject: [Netconf] question about merge operation 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 May 2014 05:56:56 -0000 This is a multipart message in MIME format. --=_alternative 0020A4E348257CD8_= Content-Type: text/plain; charset="US-ASCII" Hi all, I have a question about merge operation. For example: YANG MODEL container foo { typedef priority { type enumeration { enum first {...} enum second {..} } } list source { key name; unique priority; leaf name {...} leaf priority { type priority; } } } Existed data: src1 first src2 second If NETCONF server received a message like listed below: src1 second src2 first The client want to exchange priorities of src1 and src2. What should the NETCONF server do? 1.report an error? Because priority is unique. When set src1's priority to second, while existed data src2's priority is also second. 2. return ok? Treat the config of two srcs as whole? /frank -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 0020A4E348257CD8_= Content-Type: text/html; charset="US-ASCII" Hi all,
      I have a question about merge operation.
     
      For example:
      YANG MODEL
       container foo {
           typedef priority {
               type enumeration {
                    enum first {...}
                    enum second {..}
               }
           }
           
           list source {
                key name;
                unique priority;
                leaf name {...}
                leaf priority {
                    type priority;
                }
           }
       }

     Existed data:
     <foo>
          <source>
             <name>src1</name>
             <priority>first</priority>
          </source>
          <source>
             <name>src2</name>
             <priority>second</priority>
          </source>
     </foo>

     If NETCONF server received a message like listed below:
     <rpc message-id = "101">
          <edit-config>
               <target>
                   <candidate/>
               </target>
               <config>
                  <foo>
                      <source>
                         <name>src1</name>
                         <priority>second</priority>
                      </source>
                      <source>
                         <name>src2</name>
                         <priority>first</priority>
                      </source>
                  </foo>
               </config>
          </edit-config>
     </rpc>

      The client want to exchange priorities of src1 and src2.
     
      What should the NETCONF server do?
      1.report an error?
        Because priority is unique. When set src1's priority to second, while existed data src2's priority is also second.
      2. return ok?
         Treat the config of two srcs as whole?
/frank 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 0020A4E348257CD8_=-- From nobody Tue May 13 23:55:10 2014 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 8C0C01A0235 for ; Tue, 13 May 2014 23:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlKtGlyhpASq for ; Tue, 13 May 2014 23:55:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id C62551A0230 for ; Tue, 13 May 2014 23:55:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 052A9FDA; Wed, 14 May 2014 08:54:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lqbnFRrK9Lmj; Wed, 14 May 2014 08:54:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 14 May 2014 08:54:57 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E21920017; Wed, 14 May 2014 08:54:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8QVRpP1cmZXR; Wed, 14 May 2014 08:54:55 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26D0C20013; Wed, 14 May 2014 08:54:55 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id 2C3F02CD14BE; Wed, 14 May 2014 08:54:55 +0200 (CEST) Date: Wed, 14 May 2014 08:54:55 +0200 From: Juergen Schoenwaelder To: feng.chong33@zte.com.cn Message-ID: <20140514065455.GB91188@elstar.jacobs.jacobs-university.de> Mail-Followup-To: feng.chong33@zte.com.cn, netconf@ietf.org, ye.xu1@zte.com.cn 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: http://mailarchive.ietf.org/arch/msg/netconf/ty0283RqGq0IhAtlTEstyAsLzMk Cc: ye.xu1@zte.com.cn, netconf@ietf.org Subject: Re: [Netconf] question about merge operation 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: Wed, 14 May 2014 06:55:06 -0000 Frank, RFC 6020 section 8.3.3 specifies more details. In short, the validation happens at commit time (this is relevant since you example uses and the tree that is validated is the resulting new configuration and not each intermediate result (if you consider partial edits in isolation). /js On Wed, May 14, 2014 at 01:56:33PM +0800, feng.chong33@zte.com.cn wrote: > Hi all, > I have a question about merge operation. > > For example: > YANG MODEL > container foo { > typedef priority { > type enumeration { > enum first {...} > enum second {..} > } > } > > list source { > key name; > unique priority; > leaf name {...} > leaf priority { > type priority; > } > } > } > > Existed data: > > > src1 > first > > > src2 > second > > > > If NETCONF server received a message like listed below: > > > > > > > > > src1 > second > > > src2 > first > > > > > > > The client want to exchange priorities of src1 and src2. > > What should the NETCONF server do? > 1.report an error? > Because priority is unique. When set src1's priority to second, > while existed data src2's priority is also second. > 2. return ok? > Treat the config of two srcs as whole? > /frank > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > _______________________________________________ > 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 Wed May 14 01:20:40 2014 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 64E771A020A; Tue, 13 May 2014 14:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 p270CC6oFQn0; Tue, 13 May 2014 14:53:28 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 69D0F1A01FE; Tue, 13 May 2014 14:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=253; q=dns/txt; s=iport; t=1400018002; x=1401227602; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=4oFmIAYRIg+3qO32X87MhJnNn1TPBnWrl817FF9q3BE=; b=iQZzadP4TxMMJE3HouRBhMvMuh1UzwDdueVtqdKRCx5774R6gBgE/dPS e2ZH1JBL1nxPFD3ZWGxRJ46xrlCOeHDNV94DiNnS9N5XsNcG/kagI7a2v tH7yxCc1k3jK7E/6ppDn0gh1f5PQadaREfPJy8wUWMvgObBO52kPhE39m M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgKAFuTclNIo8UY/2dsb2JhbABZAQ6DRo1PuH4CBQGBPnMBgh1HQD0WGAMCAQIBNhgDAQYIAQEFhW2CSw2cS6oqF5FZgTwEihGPP4ZohTmGb4J7AlkdMA X-IronPort-AV: E=Sophos;i="4.97,1046,1389744000"; d="scan'208";a="40720526" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 13 May 2014 21:53:19 +0000 Received: from [10.154.208.84] ([10.154.208.84]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4DLrHnH023191; Tue, 13 May 2014 21:53:18 GMT Message-ID: <5372944D.5010509@cisco.com> Date: Tue, 13 May 2014 14:53:17 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ShgmWVcMdLJ2izET25XeJ7yEtEs X-Mailman-Approved-At: Wed, 14 May 2014 01:20:38 -0700 Subject: [Netconf] YANG Advice and Editing Session at the next IETF 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: Tue, 13 May 2014 21:53:30 -0000 [Sorry for the potential cross-posting] http://www.ietf.org/meeting/90/tutorials/yang-session.html Let me stress that this should be an interactive session, and not a tutorial. So come with your (plan to create) YANG modules. Regards, Benoit From nobody Wed May 14 02:17:28 2014 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 65C7E1A0291 for ; Wed, 14 May 2014 02:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLxlVhnUZAhV for ; Wed, 14 May 2014 02:17:23 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0663.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::663]) by ietfa.amsl.com (Postfix) with ESMTP id C5F2F1A027C for ; Wed, 14 May 2014 02:17:22 -0700 (PDT) Received: from DBXPRD0610HT005.eurprd06.prod.outlook.com (157.56.252.181) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 14 May 2014 09:16:53 +0000 Message-ID: <021c01cf6f54$e6ed96a0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Bert Wijnen (IETF)" References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> <007201cf6a9c$aa76f980$4001a8c0@gateway.2wire.net> <00da01cf6dd5$ce36e740$4001a8c0@gateway.2wire.net> Date: Wed, 14 May 2014 10:10:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DBXPR07CA001.eurprd07.prod.outlook.com (10.255.191.159) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) X-Forefront-PRVS: 0211965D06 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51704005)(377454003)(13464003)(164054003)(77156001)(93916002)(86362001)(99396002)(14496001)(83072002)(85852003)(92566001)(92726001)(1941001)(19300405004)(50986999)(88136002)(87976001)(15202345003)(87286001)(81686999)(23756003)(89996001)(81816999)(76176999)(64706001)(74502001)(81542001)(81342001)(31966008)(15975445006)(61296002)(20776003)(47776003)(101416001)(76482001)(80022001)(66066001)(44736004)(77982001)(50226001)(46102001)(74662001)(42186004)(4396001)(33646001)(84392001)(50466002)(62236002)(79102001)(44716002)(102836001)(62966002)(83322001)(21056001)(19580405001)(19580395003)(74416001)(7726001)(562404015); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB063; H:DBXPRD0610HT005.eurprd06.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/sEw0eMs9LsWbZzH_I-5bi-K5Zvk Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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 May 2014 09:17:26 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Bert Wijnen (IETF)" Cc: Sent: Monday, May 12, 2014 5:37 PM Hi Tom, >This is where we start to part company. A host key is a host key, it is >public, it is generated for me as part of a key pair for use in public >key cryptography. Of itself, it conveys nothing, no verification, no >validation, no identification. > >It only acquires value when it can be tied into an identity or >identifier, which X.509 certificates do. Or it can preconfigured into >the NMS (the key or a fingerprint thereof) but is the act of configuring >that gives the key some value, there is nothing inherent in the key. RFC 4251 section 4.1 on "Host Keys" extends the definition to include certificates too. >You say in the I-D that this does not scale, but that is true of >(almost) everything. If you use X.509 certificates, then they bind the >key to an identity; guess what, that identity has to be configured into >the NMS, so if configuring raw keys does not scale then neither do X.509 >certificates:-( Yes, the NMS needs to be programed with the identity of the CA, but that one CA can vouch for any number of devices. This *is* scalable, from the NMS's POV. What is potentially not scalable, is the need to provision each device with a signed certificate, as the naïve solution would again be per-device, though it has the up-side that the certificate-provisioning could be delegated to a 3rd-party, leveraging PKI to its fullest. However, any solution that needs the device to be "touched" before being put into commission is not ideal. The only no-touch solution I know of is for the device to already have a signed-certificate when released from its manufacturer's factory. This is the strategy is codified in the zero-touch draft. Kent, No, we are still not meeting anywhere in the middle. It seems to me that you are proposing that all devices share the same private key and so the same public key (in which case the choice of CA seems irrelevant). AFAICT, anything else requires that the NMS is configured with some identifier for each and every device, which could be the public key, could be something that appears in the subjectAltName, could be the IP address (although I think not for 'call home') etc. I see you describing this per device configuration as 'does not scale' but I see no other way. As http://www.rfc-editor.org/rfc/rfc5592.txt says "this requires the client to know the host's public key a priori and to verify that the correct key is being used." which is the sort of thing I would expect to see, in the absence of X.509 certificates. With certificates, then you know the subjectAltName a priori. Either way, you configure the NMS for every device. Tom Petch >The only thing that scales is Trust On First Use, which I think too >flaky for us to recommend. Manual acceptance when a key is first used >is more secure, but, arguably, scales no better. Agreed, TOFU is not ideal. >We have been here before - look at RFC5592, which basically says >'preconfigure host keys' to which I would now add 'or else use >certificates', RFC6125 etc. > >So my section 5 (skating over PGP use) would be more like > >"When the management system accepts a new incoming TCP connection on the >NETCONF over SSH Call Home port, it starts the SSH client protocol. As >the SSH client, it MUST authenticate the SSH server, by both identifying >the network element and verifying its SSH host key. > >When not using call home, the management system initiates the TCP >connection and so may place some reliance on the fact that the device >that responds is the one that it is configured to communicate with. >With call home, the network element initiates the TCP connection and no >reliance can be placed on the source IP address of the TCP connection. >Identifying the remote peer by its source IP address, as recommended in >[RFC6187] is NOT RECOMMENDED in the case of call home, unless the >network takes steps to validate IP source addresses. > >The management system may be configured with the host keys of the >network elements, or fingerprints thereof, and these MAY be used as an >identifier. > >The management system MAY request manually verification of a host key or >a fingerprint thereof the first time the network element connects, and >any time the host key changes thereafter. > >Digital certificates, such as those in X.509 version 3 (X.509v3) bind a >public key to a digital identity [RFC5280] and are used in many >environments for identity management. This approach is discussed in >more detail in [5539bis]; this approach is RECOMMENDED." This text is almost the same as what is there now. One thing different is I don't see the word "scale" anymore. So you want 5539bis to say PKI is scalable and hence particularly suitable for NMS and then have this draft reference it for that fact? You didn't provide text for 5539bis, so I'm just guessing, is there anything else? Thanks, Kent From nobody Wed May 14 14:30:45 2014 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 B71BD1A0202 for ; Wed, 14 May 2014 14:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 ys6kRH89jC14 for ; Wed, 14 May 2014 14:30:40 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4A61A01F0 for ; Wed, 14 May 2014 14:30:40 -0700 (PDT) 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.0.944.11; Wed, 14 May 2014 21:30:32 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) with mapi id 15.00.0944.000; Wed, 14 May 2014 21:30:32 +0000 From: Kent Watsen To: t.petch , "Bert Wijnen (IETF)" Thread-Topic: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPU0KVQTfYkuZcEUioVZNKor+uVZsro1aWgAfuBgCAAXRlEYAAS5QAgAFCeQGAAhhMgIAEWebjgAARYgCAAuzV2IAAia6A Date: Wed, 14 May 2014 21:30:31 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> <007201cf6a9c$aa76f980$4001a8c0@gateway.2wire.net> <00da01cf6dd5$ce36e740$4001a8c0@gateway.2wire.net> <021c01cf6f54$e6ed96a0$4001a8c0@gateway.2wire.net> In-Reply-To: <021c01cf6f54$e6ed96a0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.13] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(164054003)(189002)(199002)(40224001)(21056001)(19300405004)(64706001)(99396002)(83506001)(54356999)(83322001)(19580395003)(99286001)(76482001)(46102001)(74502001)(36756003)(77982001)(76176999)(81342001)(83072002)(85852003)(2656002)(20776003)(79102001)(87936001)(66066001)(86362001)(80022001)(4396001)(92566001)(81542001)(74662001)(50986999)(31966008)(92726001)(101416001)(562404015)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: <3F6475BB3B7FD347AB756C937CE9B119@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/SLbgo6WcDKiO_B-C54GxPsWZRN4 Cc: "netconf@ietf.org" Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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 May 2014 21:30:42 -0000 Hi Tom, >No, we are still not meeting anywhere in the middle. On this we can agree, but hopefully we'll get there soon ;) >It seems to me that you are proposing that all devices share the same >private key and so the same public key (in which case the choice of CA >seems irrelevant). Of course not, each device must have unique private keys. The zero-touch draft goes into more specifics regarding certificate construction and use of PKI. >As >http://www.rfc-editor.org/rfc/rfc5592.txt >says "this requires the client > to know the host's public key a priori and to verify that the correct > key is being used." >which is the sort of thing I would expect to see, in the absence of >X.509 certificates. With certificates, then you know the subjectAltName >a priori. Either way, you configure the NMS for every device. The zero-touch draft touches on this as well: Section 3.5: The NMS SHOULD also validate that the unique identifier (e.g., serial number), within the "Common Name" field of the device's X.509 certificate, is an identity that the NMS is expecting, and not another device having the same device type. In order for the NMS to know the unique identifiers for devices shipped directly to their destinations, it may be necessary for the device manufacturer to provide the unique identifiers along with other shipping or billing information. This draft not specify a format for this information exchange. Section 4.1: The unique identifier MUST be something that is both known to the device and easily tracked through labels affixed to the device as well as the box it is packaged in. A device's serial number is commonly treated this way and would be suitable for this purpose. I guess my point is that we agree on how the solution can scale. The reverse-ssh draft leaves it up to deployments to decide what to do, while the zero-touch draft specifies a specific solution that satisfies all its particular use-cases. Thanks, Kent From nobody Wed May 14 16:37:43 2014 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 A9A981A0377 for ; Wed, 14 May 2014 16:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 uXkJVVdk-aXP for ; Wed, 14 May 2014 16:37:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3A81A0345 for ; Wed, 14 May 2014 16:37:31 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB361.namprd05.prod.outlook.com (10.141.51.148) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 23:37:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) with mapi id 15.00.0944.000; Wed, 14 May 2014 23:37:20 +0000 From: Kent Watsen To: t.petch , Andy Bierman Thread-Topic: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) Thread-Index: AQHPayrnhMBsqp0TmUSXTxwk80lj6ps3sisAgABHJgCAAEGQgIAAHPYAgABNbACAAQqf64AARZYAgALBnvOAA8pngA== Date: Wed, 14 May 2014 23:37:20 +0000 Message-ID: References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> <00a801cf6dc6$45f881e0$4001a8c0@gateway.2wire.net> In-Reply-To: <00a801cf6dc6$45f881e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(189002)(199002)(164054003)(51444003)(85852003)(76176999)(80022001)(64706001)(92566001)(74662001)(83072002)(21056001)(54356999)(92726001)(4396001)(99286001)(46102001)(76482001)(31966008)(77982001)(20776003)(83506001)(81542001)(79102001)(81342001)(2656002)(50986999)(83322001)(86362001)(101416001)(74502001)(87936001)(36756003)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB361; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/BKV2ch68AE6Usghdip3CUuYHBLA Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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 May 2014 23:37:41 -0000 [Sorry for the delay - busy busy] >If the functionality is there and meets the requirements, then use it! That's our working assumption until shot down ;) >Kent was stepping back a little and asking as a matter of principle, do >we need keep-alives? Yes, I wanted to reaffirm that we needed to discuss keep-alives at all. I agree with Tom that we should support persistent connections. I believe that deployments should be able to decide for themselves if they want to use persistent connections or not, but not due to an artificial limitation we introduced to the model... >Yes. Looking at the four ends of a connection, NMS and device, call >home and normal, IMHO, the most important case is 'device call home' but >I think that 'NMS normal' is not far behind. 'NMS call home' is >interesting because it can do nothing about it, but is again signficant. >'device normal' would be the lowest priority of the four - I would >expect such a device to log the failure and wait for the connection to >be resumed but I would still want that to happen. But my starting point >would be to RECOMMEND all four, unless there are onerous technical >difficulties in doing so, in which case I would apply the priorities >above to revisit that recommendation. I like your looking at the four ends. Presenting them another way, we have: For listen (normal) case: - device: - keep-alives can be configured (e.g., via sshd_config) - YANG for configuring this could be an augmentation to the system-mgmt draft - this is because it effects the system-wide sshd listening on port 22 - NMS: - keep-alives can be configured (e.g., via ssh_config) - no need to define a YANG model since we do that for NC clients - note: it's most likely the NMS is linking to a SSH client library For call home case: - device - keep-alives can be configured (e.g., via sshd_config) - YANG for configuring this is in the netconf-server-model draft - this is because it's a distinct `sshd` process per call-home - NMS - keep-alives can be configured (e.g., via ssh_config) - no need to define a YANG model since we do that for NC clients - note: it's most likely the NMS is linking to a SSH client library So, at least for SSH, each of the four ends can have keep-alives - this is what you wanted, right? I don't know yet if TLS keep-alives are symmetric, but I imagine so. As you say, it's normal for a protocol to offer it at both ends... >I think that persistence is a subjective concept. Keeping a connection >up for an hour might be persistent for some, for me persistence would >cover more like a shift, a day or a month, and it is these sorts of >timescales that I am used to seeing with NMS. The intent is that it is "forever" until the device is configured otherwise. Should I clarify the text? - currently it says this: Applications may vary greatly on how frequently they need to interact with a device, how responsive interactions with devices need to be, and how many simultaneous connections they can support. Some applications may need a persistent connection to devices to optimize real-time interactions, while others are satisfied with periodic interactions and reduced resources required. Therefore, when it is necessary for devices to initiate connections, the type of connection desired should be configured. Thanks, Kent From nobody Wed May 14 21:16:27 2014 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 7FED01A03B6 for ; Wed, 14 May 2014 21:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 eD5p7dFXYfG3 for ; Wed, 14 May 2014 21:16:24 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196C31A03A9 for ; Wed, 14 May 2014 21:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6348; q=dns/txt; s=iport; t=1400127377; x=1401336977; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=EG8d21C+g9xT6AEBw4MhkH7muK/M2OY10QeJb6jvPkc=; b=YXGZnBRyJO5qOwjp/FVrxqXW+0UlJzyUfYE7c3XSaKi4elrT+mkVSBmS cFGAbQGYT4nwcgvEDqAVhKVt3sTjulT+p7zBRJZQ6ygGoRiGstFilaAsW snxBmZvev5ma7SzkPENlOePTUjXgleWv3lqxiHL1GIbyr/XvWpx27zy5x 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAGM+dFOtJV2Q/2dsb2JhbABZgkJEiWy8dgGBHBZ0giUBAQEEeAEQCxgJFgQEBwkDAgECATQRBgEMAQUCAQEXiCbRRBeOTgeEQASKEY9AhmmMK4F3gV8d X-IronPort-AV: E=Sophos;i="4.97,1056,1389744000"; d="scan'208,217";a="43998327" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 15 May 2014 04:16:16 +0000 Received: from [10.21.92.228] (sjc-vpn5-1252.cisco.com [10.21.92.228]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4F4GFGD025095; Thu, 15 May 2014 04:16:15 GMT Message-ID: <53743F8F.2050308@cisco.com> Date: Wed, 14 May 2014 21:16:15 -0700 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andy Bierman , Kent Watsen References: <53714FEC.2030709@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040108000304090703060405" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nGpyhvfWYiWf5uhpt1wQ49jqR6I Cc: Mark Nottingham , 'Barry Leiba' , NETCONF Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) 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 May 2014 04:16:25 -0000 This is a multi-part message in MIME format. --------------040108000304090703060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Discussing this issue with Barry: Yes, .well-known is a possible solution for netconf/restconf. Another possibility is URI templates. The get-off-my-lawn document talks about both. For restconf, Mark Nottingham could help advise which would be a better option for them. Regards, Benoit > > > On Tue, May 13, 2014 at 11:53 AM, Kent Watsen > wrote: > > > Andy writes: > > I think RESTCONF violates sec 2.3 wrt/ structure within the > URI path. > > > > I agree with Andy that RESTCONF violates section 2.3. I also > think that we can remove that violation by supporting "well-known" > URIs. Notice that the 2nd paragraph in section 2.3 says "The only > exception to this requirement is registered 'well-known' URIs, as > specified by [RFC5785]." My reading is, if we use a "well-known" > URI, then our subtree can defined sub-structure per RESTCONF > convention. > > We discussed using well-known URIs before. Appendix B.3. in the > RESTCONF draft ("Open Issues") regards ".well-known usage". This > issue was closed with the resolution "not needed in RESTCONF". > We may need to revisit that decision now. > > > I agree we need to support .well-known to conform to this BCP. > > Thanks, > Kent > > > Andy > --------------040108000304090703060405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Discussing this issue with Barry:
Yes, .well-known is a possible solution for netconf/restconf.  Another possibility is URI templates.  The get-off-my-lawn document talks about both.  For restconf, Mark Nottingham could help advise which would be a better option for them.
Regards, Benoit


On Tue, May 13, 2014 at 11:53 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Andy writes:
I think RESTCONF violates sec 2.3 wrt/ structure within the URI path.
<snip/>

I agree with Andy that RESTCONF violates section 2.3.  I also think that we can remove that violation by supporting "well-known" URIs.  Notice that the 2nd paragraph in section 2.3 says "The only exception to this requirement is registered 'well-known' URIs, as specified by [RFC5785]."   My reading is, if we use a "well-known" URI, then our subtree can defined sub-structure per RESTCONF convention.

We discussed using well-known URIs before.   Appendix B.3. in the RESTCONF draft ("Open Issues") regards ".well-known usage".  This issue was closed with the resolution "not needed in RESTCONF".   We may need to revisit that decision now.


I agree we need to support .well-known to conform to this BCP.
 
Thanks,
Kent


Andy


--------------040108000304090703060405-- From nobody Wed May 14 23:55:11 2014 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 713B51A03DC for ; Wed, 14 May 2014 23:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 d1DRsJpVVRVM for ; Wed, 14 May 2014 23:55:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBDC1A0245 for ; Wed, 14 May 2014 23:55:08 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C072B574001; Thu, 15 May 2014 08:54:59 +0200 (CEST) Date: Thu, 15 May 2014 08:54:59 +0200 (CEST) Message-Id: <20140515.085459.2135864207024302109.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <00a801cf6dc6$45f881e0$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ZkBeaNQQVfP7FiMvbI3MaHif7hM Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf keep-alive 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 May 2014 06:55:09 -0000 Kent Watsen wrote: > [Sorry for the delay - busy busy] > > > > >If the functionality is there and meets the requirements, then use it! > > That's our working assumption until shot down ;) This is regarding SSH keepalives, right? As I've said before, I agree it can be used, but you need to provide a reference to what you mean when you say "SSH keepalive". AFAIK, this is not defined in any RFC, but implementations use a trick (hopefully the same) where they send a bogus packet and expect a failure reply back. /martin From nobody Thu May 15 07:27:08 2014 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 AECB51A00BD for ; Thu, 15 May 2014 07:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sYBLBgqApnA for ; Thu, 15 May 2014 07:26:56 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412891A00B9 for ; Thu, 15 May 2014 07:26:56 -0700 (PDT) Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 15 May 2014 14:26:47 +0000 Message-ID: <002001cf7049$5b2c7f00$4001a8c0@gateway.2wire.net> From: t.petch To: , Martin Bjorklund References: <00a801cf6dc6$45f881e0$4001a8c0@gateway.2wire.net> <20140515.085459.2135864207024302109.mbj@tail-f.com> Date: Thu, 15 May 2014 15:11:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AM3PR07CA008.eurprd07.prod.outlook.com (10.242.16.48) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Forefront-PRVS: 0212BDE3BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(199002)(189002)(377454003)(24454002)(51444003)(51704005)(77156001)(93916002)(4396001)(77982001)(86362001)(99396002)(89996001)(64706001)(19580395003)(21056001)(19580405001)(83322001)(47776003)(62236002)(20776003)(88136002)(44716002)(102836001)(101416001)(50466002)(81542001)(87286001)(1941001)(92726001)(92566001)(61296002)(79102001)(23756003)(50226001)(76482001)(31966008)(84392001)(42186004)(44736004)(74502001)(74662001)(62966002)(46102001)(85852003)(80022001)(87976001)(81342001)(33646001)(81816999)(81686999)(83072002)(50986999)(76176999)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB052; H:AMXPRD0310HT001.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0kpg8o5Zr3taviMxF0K5QN__vUc Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf keep-alive 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 May 2014 14:27:03 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; ; Sent: Thursday, May 15, 2014 7:54 AM > Kent Watsen wrote: > > [Sorry for the delay - busy busy] > > > > >If the functionality is there and meets the requirements, then use it! > > > > That's our working assumption until shot down ;) > > This is regarding SSH keepalives, right? As I've said before, I agree > it can be used, but you need to provide a reference to what you mean > when you say "SSH keepalive". AFAIK, this is not defined in any RFC, > but implementations use a trick (hopefully the same) where they send a > bogus packet and expect a failure reply back. Martin, I think not, that this is a NETCONF issue or at least a call home issue, that a call home device should be using keepalives regardless of the transport in use (and, not quite so important, I think that a normal NMS should be using them as well). So while we may have started talking about it in the context of SSH call home, I think that Kent is right to widen the discussion. If we have it for call home over one (unreliable:-) transport, then I think we need it for all. Whether or not the mechanics are the same is, for me, a separate question. Neither SSH nor TLS saw fit to include keepalives initially, TLS has added them later (RFC6520), ssh can fudge it. Tom Petch. > > /martin From nobody Thu May 15 07:27:10 2014 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 A09C91A00B9 for ; Thu, 15 May 2014 07:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jmMMhIzb274 for ; Thu, 15 May 2014 07:26:57 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33BF1A029D for ; Thu, 15 May 2014 07:26:56 -0700 (PDT) Received: from AMXPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.133) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 15 May 2014 14:26:47 +0000 Message-ID: <002101cf7049$5b7ee4c0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Andy Bierman References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> <00a801cf6dc6$45f881e0$4001a8c0@gateway.2wire.net> Date: Thu, 15 May 2014 15:22:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-ClientProxiedBy: AM3PR07CA008.eurprd07.prod.outlook.com (10.242.16.48) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) X-Forefront-PRVS: 0212BDE3BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(199002)(189002)(377454003)(164054003)(51444003)(77156001)(93916002)(4396001)(77982001)(86362001)(99396002)(89996001)(64706001)(19580395003)(21056001)(19580405001)(83322001)(47776003)(62236002)(20776003)(88136002)(44716002)(102836001)(101416001)(50466002)(81542001)(87286001)(1941001)(92726001)(92566001)(61296002)(79102001)(23756003)(50226001)(76482001)(31966008)(84392001)(42186004)(44736004)(74502001)(74662001)(62966002)(46102001)(85852003)(80022001)(87976001)(81342001)(33646001)(81816999)(81686999)(83072002)(50986999)(76176999)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB052; H:AMXPRD0310HT001.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/n4xP-eRTLZntyztWrjKaCi0DTxs Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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 May 2014 14:27:03 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Andy Bierman" Cc: "Phil Shafer" ; "Netconf" Sent: Thursday, May 15, 2014 12:37 AM [Sorry for the delay - busy busy] >If the functionality is there and meets the requirements, then use it! That's our working assumption until shot down ;) >Kent was stepping back a little and asking as a matter of principle, do >we need keep-alives? Yes, I wanted to reaffirm that we needed to discuss keep-alives at all. I agree with Tom that we should support persistent connections. I believe that deployments should be able to decide for themselves if they want to use persistent connections or not, but not due to an artificial limitation we introduced to the model... >Yes. Looking at the four ends of a connection, NMS and device, call >home and normal, IMHO, the most important case is 'device call home' but >I think that 'NMS normal' is not far behind. 'NMS call home' is >interesting because it can do nothing about it, but is again signficant. >'device normal' would be the lowest priority of the four - I would >expect such a device to log the failure and wait for the connection to >be resumed but I would still want that to happen. But my starting point >would be to RECOMMEND all four, unless there are onerous technical >difficulties in doing so, in which case I would apply the priorities >above to revisit that recommendation. I like your looking at the four ends. Presenting them another way, we have: For listen (normal) case: - device: - keep-alives can be configured (e.g., via sshd_config) - YANG for configuring this could be an augmentation to the system-mgmt draft - this is because it effects the system-wide sshd listening on port 22 - NMS: - keep-alives can be configured (e.g., via ssh_config) - no need to define a YANG model since we do that for NC clients - note: it's most likely the NMS is linking to a SSH client library For call home case: - device - keep-alives can be configured (e.g., via sshd_config) - YANG for configuring this is in the netconf-server-model draft - this is because it's a distinct `sshd` process per call-home - NMS - keep-alives can be configured (e.g., via ssh_config) - no need to define a YANG model since we do that for NC clients - note: it's most likely the NMS is linking to a SSH client library So, at least for SSH, each of the four ends can have keep-alives - this is what you wanted, right? I don't know yet if TLS keep-alives are symmetric, but I imagine so. As you say, it's normal for a protocol to offer it at both ends... TLS defines keepalives in RFC6520 as a separate protocol running on top of the Record layer, requested by a TLS Hello extension. The extension says that the sender (TLS client) wants to be able to send HeartbeatRequest and get back HeartbeatResponse and it also allows or disallows the other end to send a HeartbeatRequest. So symmetric operation is configurable. Tom Petch >I think that persistence is a subjective concept. Keeping a connection >up for an hour might be persistent for some, for me persistence would >cover more like a shift, a day or a month, and it is these sorts of >timescales that I am used to seeing with NMS. The intent is that it is "forever" until the device is configured otherwise. Should I clarify the text? - currently it says this: Applications may vary greatly on how frequently they need to interact with a device, how responsive interactions with devices need to be, and how many simultaneous connections they can support. Some applications may need a persistent connection to devices to optimize real-time interactions, while others are satisfied with periodic interactions and reduced resources required. Therefore, when it is necessary for devices to initiate connections, the type of connection desired should be configured. Thanks, Kent From nobody Thu May 15 08:21:58 2014 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 AB57E1A0099 for ; Thu, 15 May 2014 08:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 upauPGg5syUa for ; Thu, 15 May 2014 08:21:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1324D1A008D for ; Thu, 15 May 2014 08:21:51 -0700 (PDT) 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.0.944.11; Thu, 15 May 2014 15:21:42 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) with mapi id 15.00.0944.000; Thu, 15 May 2014 15:21:42 +0000 From: Kent Watsen To: Benoit Claise , Andy Bierman Thread-Topic: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) Thread-Index: AQHPbjTesrzdWmo2rkmRPyjc5i2Otps9kRSAgAAaUoCAAO5HgIAARg6AgAIsroCAAHbbgA== Date: Thu, 15 May 2014 15:21:42 +0000 Message-ID: References: <53714FEC.2030709@cisco.com> <53743F8F.2050308@cisco.com> In-Reply-To: <53743F8F.2050308@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.16] x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(164054003)(17383004)(189002)(199002)(377454003)(24454002)(52604005)(16236675002)(74502001)(80022001)(64706001)(74662001)(20776003)(31966008)(79102001)(77982001)(76482001)(46102001)(81342001)(2656002)(36756003)(87936001)(50986999)(76176999)(81542001)(54356999)(4396001)(83322001)(19580405001)(99286001)(99396002)(83072002)(85852003)(86362001)(92566001)(92726001)(19580395003)(83506001)(101416001)(15202345003)(15975445006)(21056001)(166863002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: multipart/alternative; boundary="_000_CF9A4A3A71AEBkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/fED77z1LYwbucOdkv5VPXVucflE Cc: Mark Nottingham , 'Barry Leiba' , NETCONF Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) 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 May 2014 15:21:56 -0000 --_000_CF9A4A3A71AEBkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mark, thanks for looking in on this! Currently RESTCONF hardcodes the top-level URL path "/restconf", which isn'= t in line with your BCP. Our thoughts are to put in text like that below= . Looking at rfc6570, I don't see how URI templates would help here. Can = you suggest a better way? - or were you thinking that we could use URI Tem= plates to define the structure of the RESTCONF API's URLs? Thanks, Kent =3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D RESTCONF Path Resolution In line 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] as follows: 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 access to a RESTCONF resource. For instance, using the "/api/restco= nf" path discovered above, the client can now determine the version of RESTCONF protocol as follows: Request ------- GET /api/restconf/version HTTP/1.1 Host: example.com Accept: application/yang.api+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 { "version": "1.0" } =3D=3D=3D=3D=3D STOP =3D=3D=3D=3D=3D From: Benoit Claise > Date: Thursday, May 15, 2014 at 12:16 AM To: Andy Bierman >, Kent Wats= en > Cc: NetConf >, 'Barry Leiba' >, Mark Nottingham > Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-= 04 (on the IESG telechat this week) Dear all, Discussing this issue with Barry: Yes, .well-known is a possible solution for netconf/restconf. Another poss= ibility is URI templates. The get-off-my-lawn document talks about both. = For restconf, Mark Nottingham could help advise which would be a better opt= ion for them. Regards, Benoit On Tue, May 13, 2014 at 11:53 AM, Kent Watsen > wrote: Andy writes: I think RESTCONF violates sec 2.3 wrt/ structure within the URI path. I agree with Andy that RESTCONF violates section 2.3. I also think that we= can remove that violation by supporting "well-known" URIs. Notice that th= e 2nd paragraph in section 2.3 says "The only exception to this requirement= is registered 'well-known' URIs, as specified by [RFC5785]." My reading = is, if we use a "well-known" URI, then our subtree can defined sub-structur= e per RESTCONF convention. We discussed using well-known URIs before. Appendix B.3. in the RESTCONF = draft ("Open Issues") regards ".well-known usage". This issue was closed w= ith the resolution "not needed in RESTCONF". We may need to revisit that = decision now. I agree we need to support .well-known to conform to this BCP. Thanks, Kent Andy --_000_CF9A4A3A71AEBkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <530886DE4157FB4198E3D08AC9044C42@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi Mark, thanks for looking in on this!

Currently RESTCONF hardcodes the top-level URL path "/restconf", = which isn't in line with your BCP.    Our thoughts are to put in = text like that below.  Looking at rfc6570, I don't see how URI templat= es would help here.  Can you suggest a better way?  - or were you thinking that we could use URI Templates to define the structure = of the RESTCONF API's URLs?

Thanks,
Kent

=3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D

RESTCONF Path Resolution

   In line the best practices defined by "get-off-my-lawn&qu= ot;, RESTCONF
   enables deployments to specify where the RESTCONF API is locat= ed.
   When first connecting to a RESTCONF server, a RESTCONF cl= ient MUST
   determine the root of the RESTCONF API.  The client disco= vers this
   by getting the ".well-known/host-meta" resource [RFC= 6415] as follows:

       Request
       -------
       GET /.wel= l-known/host-meta users HTTP/1.1
       Host: exa= mple.com
       Accept: a= pplication/xrd+xml

       Response<= /font>
       --------<= /font>
       HTTP/1.1 = 200 OK
       Content-T= ype: application/xrd+xml
       Content-L= ength: nnn

       <XRD x= mlns=3D'http://docs.oasis-open.org/ns/xri/xrd-1.0'>
          &= nbsp;<Link rel=3D'restconf' href=3D'/api/restconf'/>
       </XRD&= gt;


   Once discovering the RE= STCONF API root, the client MUST prepend it to
   any access to a RESTCON= F resource.  For instance, using the "/api/restconf"<= /div>
   path discovered above, = the client can now determine the version of 
   RESTCONF protocol as fo= llows:

       Request
       -------
       GET /api/= restconf/version  HTTP/1.1
       Host: exa= mple.com
       Accept: a= pplication/yang.api+json

       Response<= /font>
       --------<= /font>
       HTTP/1.1 = 200 OK
       Date: Mon= , 23 Apr 2012 17:01:00 GMT
       Server: e= xample-server
       Cache-Con= trol: no-cache
       Pragma: n= o-cache
       Last-Modi= fied: Sun, 22 Apr 2012 01:00:14 GMT
       Content-T= ype: application/yang.api+json

       { "v= ersion": "1.0" }


=3D=3D=3D=3D=3D STOP =3D=3D=3D=3D=3D



From: Benoit Claise <bclaise@cisco.com>
Date: Thursday, May 15, 2014 at 12:= 16 AM
To: Andy Bierman <andy@yumaworks.com>, Kent Watsen <kwatsen@juniper.net>
Cc: NetConf <netconf@ietf.org>, 'Barry Leiba' <barryleiba@computer.org>, Mark Nottingh= am <mnot@mnot.net>
Subject: Re: [Netconf] RESTCONF and= draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week)=

Dear all,

Discussing this issue with Barry:
Yes, .well-known is a possible solution for netconf/restconf. &= nbsp;Another possibility is URI templates.  The get-off-my-lawn docume= nt talks about both.  For restconf, Mark Nottingham could help advise = which would be a better option for them.
Regards, Benoit


On Tue, May 13, 2014 at 11:53 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Andy writes:
I think RESTCONF violates sec 2.3 wrt/ structure within the URI path.<= /div>
<snip/>

I agree with Andy that RESTCONF violates section 2.3.  I also thi= nk that we can remove that violation by supporting "well-known" U= RIs.  Notice that the 2nd paragraph in section 2.3 says "The only= exception to this requirement is registered 'well-known' URIs, as specified by [RFC5785]."   My reading is, if we use a &= quot;well-known" URI, then our subtree can defined sub-structure per R= ESTCONF convention.

We discussed using well-known URIs before.   Appendix B.3. in the= RESTCONF draft ("Open Issues") regards ".well-known usage&q= uot;.  This issue was closed with the resolution "not needed in R= ESTCONF".   We may need to revisit that decision now.


I agree we need to support .well-known to conform to this BCP.
 
Thanks,
Kent


Andy


 --_000_CF9A4A3A71AEBkwatsenjunipernet_-- From nobody Thu May 15 09:47:22 2014 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 A134E1A065A for ; Thu, 15 May 2014 09:47:21 -0700 (PDT) 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 mI3JKxUwV-K5 for ; Thu, 15 May 2014 09:47:20 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84161A0656 for ; Thu, 15 May 2014 09:47:19 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id w7so2228898qcr.20 for ; Thu, 15 May 2014 09:47:12 -0700 (PDT) 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=Y0lVq4IszT8YDyWwabBKumHahHfdTtxNPDQG7PYvlf0=; b=RpG/2g5ZsTUHPmv8FcPYhmE7U1nTlgw7Pfy3zK18oOrbL/tuGiPfPgadGJP96x3daF pMe7BQhHoIsxpFLG6WcYM3SpCckq+3VEYHdkpBRP/S4WOcp9JYJTx/lLbKfKJUGa8B7E H55nZ6xFpaLlAr/pO4l17SidrlEUE5zIFDHoOJUlbG0T2ccYqzeIrOhoY4Ntd37GkOHg Qw7aTHydufjER20+BIDel+JHiK6IIOje4x6GjF7tx9Fkpn2d+1wbWvphsX+pjqZCuC3g dFAffJDKDBQiZGhe/oJS1Hx8QfFgPUy4hVu0fC38jmDroNjQ3mAUjkoxWQqQY7t4TK6u KZmg== X-Gm-Message-State: ALoCoQm6eshy8nLYeluu/ORmpXznFjAi/2Guzo0z5vxb1QKPcI4Evupmk2gZE9fWlor7gnjzOnLP MIME-Version: 1.0 X-Received: by 10.140.27.245 with SMTP id 108mr16520982qgx.18.1400172432276; Thu, 15 May 2014 09:47:12 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Thu, 15 May 2014 09:47:12 -0700 (PDT) Date: Thu, 15 May 2014 09:47:12 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c1526073571104f9730c46 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/klsVrLqlBlyIpHe4roLhYNAuYDY Subject: [Netconf] kwatsen-netconf-server 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 May 2014 16:47:21 -0000 --001a11c1526073571104f9730c46 Content-Type: text/plain; charset=ISO-8859-1 Hi, It seems that some WG objects from draft-ietf-netconf-rfc5539bis are now objects in an "individual submission" draft. What are we doing here? Are the configuration objects punted out of the charter and now kwatsen-netconf-server has to be chartered? Is this draft decoupled from zerotouch? Do they both have to be chartered at the same time? If not, then when will this draft be republished as a WG I-D? Andy --001a11c1526073571104f9730c46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

It seems that some WG objects from = draft-ietf-netconf-rfc5539bis
are now objects in an "individ= ual submission" draft.
What are we doing here?
Are the configuration objects punted out of the charter
and now kwatsen-netconf-server has to be chartered?
Is this dra= ft decoupled from zerotouch? Do they both have to
be chartered at= the same time? If not, then when will this
draft be republished as a WG I-D?


<= div>Andy

--001a11c1526073571104f9730c46-- From nobody Thu May 15 10:32:49 2014 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 EEA811A02B9 for ; Thu, 15 May 2014 10:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlW1u2rxwjJs for ; Thu, 15 May 2014 10:32:45 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9F11A0075 for ; Thu, 15 May 2014 10:32:44 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id if17so4746831vcb.36 for ; Thu, 15 May 2014 10:32:37 -0700 (PDT) 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=yWTANibJbL0D7c8Q96ZU7jp2rhNb/9fgb9z2h2jlZhc=; b=ANAehOIKBNoXSo9DQyU0OWOsGfEW/NgWnmMT6YdkPl4epmp3y4RaKwfhFGdvKuua1i ejE9+DEZ1ePEkMV/apqHeYuK3rGfwFt/YcbN3rvbvm4bnZObGlSf7Af/Y5SED2ZJWdF9 wo60EmAqApbnnVOrEiUKyo//lsyZrSeR1eNFEcqplbELRj7kSJnSUNEORpF8xZVoJPDX Q3E1tfa4B9rT5g8WM5/4A1itAxIWOK/Y1CKz5hmhbCMtzFSTftwcvXOVRhg2316cmnQt J8ogQUho6KathFbip0rf90qq3Ov6d8TMuFyrzA02Z0/Y1jRsHkx95ctJjbgB/10OQts+ KDPQ== X-Gm-Message-State: ALoCoQlW71edB7KIdA7wiRAiop/znt24C5hJI4kzRlv0MUdThtWmZ/ARM2ath/h/Zqn7n82Vu/gF MIME-Version: 1.0 X-Received: by 10.58.29.76 with SMTP id i12mr126145veh.67.1400175157462; Thu, 15 May 2014 10:32:37 -0700 (PDT) Received: by 10.220.136.72 with HTTP; Thu, 15 May 2014 10:32:37 -0700 (PDT) Date: Thu, 15 May 2014 13:32:37 -0400 Message-ID: From: Andrew Stone To: Netconf Content-Type: multipart/alternative; boundary=047d7b6dc7f2e25c7c04f973aee1 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wCoGXcCs2i-fxL4Zst2k-euoy20 Subject: [Netconf] YANG and binary data blobs 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 May 2014 17:32:47 -0000 --047d7b6dc7f2e25c7c04f973aee1 Content-Type: text/plain; charset=UTF-8 Hi, I want to specify a blob of binary data -- for example, an image or an array of data points that the mgt app might present as a chart. Originally I formulated this as a leaf-list of a fundamental type (int). But I see now in RFC6020 that leaf-list is actually more like a set. That is, elements with the same value are not allowed. Next possibility (please excuse any typos I'm writing this right now) is list { key id; leaf id { type int; } leaf val { type int; } } This formulation has a few problems: 1. it is not clear that this is not a "sparse" list -- that a good underlying representation would be an array 2. it implicitly puts the key "id" as a member of the list element -- in "C": { int id; int val; }. But I suppose again a customized implementation could dispense with this. 3. inefficient Netconf XML. 4. unnecessary ability to reference individual elements. What do you use for binary data blobs? Regards, Andrew --047d7b6dc7f2e25c7c04f973aee1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=

I want to specify a blob of binary data -- for example, an image or= an array of data points that the mgt app might present as a chart.

Originally I formulated this as a leaf-list of a fundamental type (in= t).=C2=A0 But I see now in RFC6020 that leaf-list is actually more like a s= et.=C2=A0 That is, elements with the same value are not allowed.

Next possibility (please excuse any typos I'm writing this right now= ) is

list {
=C2=A0 key id;
=C2=A0 leaf id { typ= e int; }
=C2=A0 leaf val { type int; }
}

This form= ulation has a few problems:
1. it is not clear that this is not a = "sparse" list -- that a good underlying representation would be a= n array
2. it implicitly puts the key "id" as a member of the list = element -- in "C": { int id; int val; }.=C2=A0 But I suppose agai= n a customized implementation could dispense with this.
3. ineffic= ient Netconf XML.
4. unnecessary ability to reference individual elements.

What do you use for binary data blobs?

Regard= s,
Andrew
--047d7b6dc7f2e25c7c04f973aee1-- From nobody Thu May 15 10:43:05 2014 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 1B12E1A02D5 for ; Thu, 15 May 2014 10:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 aWr9Afp9pcQf for ; Thu, 15 May 2014 10:43:01 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073371A0127 for ; Thu, 15 May 2014 10:43:00 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id i17so2416825qcy.11 for ; Thu, 15 May 2014 10:42:53 -0700 (PDT) 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=pLSapQXZaPKMo/KtbsdWEvwUGE9Pw7C06SBK6hnoy1Q=; b=XmCEccE5Lly/Zk5TqVJP6J/KD8BesdolW2OlGUJsxwsvNj1/p5i5i/fBBrm4lasSgs ufW/pLs4V+JwqSVMVyP2+IcZZjTdIexwTz5vxF8TZHEmAcLNH83QR/eOD0rhDngFfp4j 91qswhCkYnWqW/rjVAsMIVQ0cP5yUfqJLE8LT9CLCbkxZPtokBoFwA7ocJNu2BMWjBVR Hvl6pC0tx9M13Bj/IQQLAQdNA4TStL22gqAEdB3gAYM5plF7HFPre3XzfUIR9RRx6xbb exbHwjpjF1DBSJ5PLM+MZifFaEEQWVOGnDw0EBgFGdWLhG+x/P9g7Dm7lH4y/xebNzPC jIVg== X-Gm-Message-State: ALoCoQmArSqU9YhneShObIhxAbONvvmmgyAP8/vs+nAEfAY5LbxNqGhsxg728cFN/T1uI2+R8MHT MIME-Version: 1.0 X-Received: by 10.224.55.6 with SMTP id s6mr15398326qag.7.1400175773335; Thu, 15 May 2014 10:42:53 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Thu, 15 May 2014 10:42:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 May 2014 10:42:53 -0700 Message-ID: From: Andy Bierman To: Andrew Stone Content-Type: multipart/alternative; boundary=089e0153705e97d71e04f973d3e2 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/iv8mxiBG5ztCnugTOsIdZhBUr0Q Cc: Netconf Subject: Re: [Netconf] YANG and binary data blobs 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 May 2014 17:43:03 -0000 --089e0153705e97d71e04f973d3e2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 15, 2014 at 10:32 AM, Andrew Stone wrote: > Hi, > > I want to specify a blob of binary data -- for example, an image or an > array of data points that the mgt app might present as a chart. > > Originally I formulated this as a leaf-list of a fundamental type (int). > But I see now in RFC6020 that leaf-list is actually more like a set. That > is, elements with the same value are not allowed. > > Next possibility (please excuse any typos I'm writing this right now) is > > list { > key id; > leaf id { type int; } > leaf val { type int; } > } > > This formulation has a few problems: > 1. it is not clear that this is not a "sparse" list -- that a good > underlying representation would be an array > 2. it implicitly puts the key "id" as a member of the list element -- in > "C": { int id; int val; }. But I suppose again a customized implementation > could dispense with this. > 3. inefficient Netconf XML. > 4. unnecessary ability to reference individual elements. > > What do you use for binary data blobs? > > How about the "binary" type defined in RFC 6020, sec. 9.8? > Regards, > Andrew > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --089e0153705e97d71e04f973d3e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 15, 2014 at 10:32 AM, Andrew Stone &l= t;stone@openclovi= s.com> wrote:
Hi,

I want to specify a blob of binary d= ata -- for example, an image or an array of data points that the mgt app mi= ght present as a chart.

Originally I formulated this as a leaf-list of a fundamental type (in= t).=A0 But I see now in RFC6020 that leaf-list is actually more like a set.= =A0 That is, elements with the same value are not allowed.

Nex= t possibility (please excuse any typos I'm writing this right now) is
list {
=A0 key id;
=A0 leaf id { type int;= }
=A0 leaf val { type int; }
}

This formulation h= as a few problems:
1. it is not clear that this is not a "spa= rse" list -- that a good underlying representation would be an array
2. it implicitly puts the key "id" as a member of the list = element -- in "C": { int id; int val; }.=A0 But I suppose again a= customized implementation could dispense with this.
3. inefficien= t Netconf XML.
4. unnecessary ability to reference individual elements.

What do you use for binary data blobs?

=

How about the "binary" type defi= ned in RFC 6020, sec. 9.8?

=A0
Regards,
Andrew


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


--089e0153705e97d71e04f973d3e2-- From nobody Thu May 15 10:47:59 2014 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 442421A02E6 for ; Thu, 15 May 2014 10:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PbjQ5aHMa4H6 for ; Thu, 15 May 2014 10:47:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A281A0127 for ; Thu, 15 May 2014 10:47:54 -0700 (PDT) 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.0.944.11; Thu, 15 May 2014 17:47:45 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) with mapi id 15.00.0944.000; Thu, 15 May 2014 17:47:45 +0000 From: Kent Watsen To: Andy Bierman , Netconf Thread-Topic: [Netconf] kwatsen-netconf-server Thread-Index: AQHPcF1ttT3QkShiakOtp9iuyYqoIZtBp8KA Date: Thu, 15 May 2014 17:47:44 +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.1.140326 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(377454003)(164054003)(189002)(199002)(50986999)(85852003)(76176999)(54356999)(99286001)(81542001)(99396002)(36756003)(101416001)(87936001)(2656002)(4396001)(83072002)(15202345003)(19580395003)(19580405001)(83322001)(79102001)(76482001)(46102001)(92566001)(80022001)(74662001)(31966008)(92726001)(64706001)(21056001)(74502001)(77982001)(20776003)(86362001)(16236675002)(83506001)(81342001)(15975445006); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: multipart/alternative; boundary="_000_CF9A747271C55kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/phQWX2_uzxvcjNMOGu9lo-T-BGU Subject: Re: [Netconf] kwatsen-netconf-server 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 May 2014 17:47:58 -0000 --_000_CF9A747271C55kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am planning to work on it today. There are a number of updates to be mad= e, but I should be able to get it out tomorrow. Per the 89 meeting (http://www.ietf.org/proceedings/89/minutes/minutes-89-n= etconf), I'll submit it as a WG draft called "draft-ietf-netconf-server-mod= el-00". Thanks, Kent From: Andy Bierman > Date: Thursday, May 15, 2014 at 12:47 PM To: NetConf > Subject: [Netconf] kwatsen-netconf-server Hi, It seems that some WG objects from draft-ietf-netconf-rfc5539bis are now objects in an "individual submission" draft. What are we doing here? Are the configuration objects punted out of the charter and now kwatsen-netconf-server has to be chartered? Is this draft decoupled from zerotouch? Do they both have to be chartered at the same time? If not, then when will this draft be republished as a WG I-D? Andy --_000_CF9A747271C55kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

I am planning to work on it today.  There are a number of updates= to be made, but I should be able to get it out tomorrow.

Per the 89 meeting (http://www.ietf.org/proceedings/89/minutes/minutes-= 89-netconf), I'll submit it as a WG draft called "draft-ietf-netco= nf-server-model-00".

Thanks,
Kent

From: Andy Bierman <andy@yumaworks.com>
Date: Thursday, May 15, 2014 at 12:= 47 PM
To: NetConf <netconf@ietf.org>
Subject: [Netconf] kwatsen-netconf-= server

Hi,

It seems that some WG objects from draft-ietf-netconf-rfc5539bis
are now objects in an "individual submission" draft.
What are we doing here?

Are the configuration objects punted out of the charter
and now kwatsen-netconf-server has to be chartered?
Is this draft decoupled from zerotouch? Do they both have to
be chartered at the same time? If not, then when will this
draft be republished as a WG I-D?


Andy

 --_000_CF9A747271C55kwatsenjunipernet_-- From nobody Fri May 16 00:28:26 2014 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 89CCF1A0194 for ; Fri, 16 May 2014 00:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTLeb1jPopjK for ; Fri, 16 May 2014 00:28:21 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0081.outbound.protection.outlook.com [213.199.154.81]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB3A1A0156 for ; Fri, 16 May 2014 00:28:21 -0700 (PDT) Received: from DBXPRD0610HT003.eurprd06.prod.outlook.com (157.56.252.181) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.0.944.11; Fri, 16 May 2014 07:28:12 +0000 Message-ID: <008401cf70d8$0aa0f040$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Netconf References: Date: Fri, 16 May 2014 08:25:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: AMXPR07CA006.eurprd07.prod.outlook.com (10.242.64.46) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) X-Forefront-PRVS: 02135EB356 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(377454003)(51704005)(13464003)(92566001)(50226001)(79102001)(62236002)(101416001)(92726001)(81342001)(86362001)(93916002)(44716002)(4396001)(23756003)(99396002)(81542001)(64706001)(31966008)(87976001)(74502001)(77156001)(77982001)(81816999)(21056001)(50986999)(81686999)(33646001)(76176999)(66066001)(87286001)(42186004)(80022001)(46102001)(83072002)(61296002)(83322001)(88136002)(85852003)(14496001)(74662001)(20776003)(47776003)(102836001)(50466002)(19580395003)(19580405001)(62966002)(89996001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR07MB051; H:DBXPRD0610HT003.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-yF6oAtkKj5_MHqSYG69CDDcsQc Subject: Re: [Netconf] kwatsen-netconf-server 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 May 2014 07:28:24 -0000 Andy For my part, I see reaching consensus on the questions relating to persistence, keep-alive and, perhaps, security as a prerequisite, so while I had some comments on the I-D, I parked them until the question of what to configure got resolved. Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "Netconf" Sent: Thursday, May 15, 2014 5:47 PM > Hi, > > It seems that some WG objects from draft-ietf-netconf-rfc5539bis > are now objects in an "individual submission" draft. > What are we doing here? > > Are the configuration objects punted out of the charter > and now kwatsen-netconf-server has to be chartered? > Is this draft decoupled from zerotouch? Do they both have to > be chartered at the same time? If not, then when will this > draft be republished as a WG I-D? > > > Andy > ------------------------------------------------------------------------ -------- > From nobody Fri May 16 07:35:43 2014 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 142E21A024A for ; Fri, 16 May 2014 07:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6F6lyS0_-le2 for ; Fri, 16 May 2014 07:35:33 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D1A1A0269 for ; Fri, 16 May 2014 07:35:30 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hq16so6248361vcb.23 for ; Fri, 16 May 2014 07:35:22 -0700 (PDT) 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=7Bit30I2mht32OeP/P+Y53PlFb7QtjluAyNphZav6/g=; b=AhcW/kfVsgDEE8CfxVT3cZ95bkDubqJV/QBFwa7uURebVgvH2fa5nKKZexYzh+EX2B sk+GFImcMq098Ys/dRS+UthQvHpkALI/nPFKkGnQR4fKBt6HnccoAtMyZlxEka7fdsCi XUbZQ3cJ6qKOWbhh/Hjxgo6UJ3gZxH9EyJ/pNhj0pVMhEx1nnaGjD6YDDg0aQMWSW+l5 AQGf8zHwbU4UzlKnCjSO4Kpi0ac/lEJMTDWycmVrdlWo6DsPxLZxB566DNDMKzC4zlMG EA+SPCkUNgC77ohQPUW3juLZTxmz7ziJujpknG5XsWzgl0arENkI7OCo0fEdcRBbnTnE 1RPw== X-Gm-Message-State: ALoCoQlAyGRewzOesvHT3srnlqOKD5d1X2tEt5bK0LMUzxEdROoCe+G4gy8ks+q5vngcjw5AKzu8 MIME-Version: 1.0 X-Received: by 10.221.30.14 with SMTP id sa14mr950838vcb.44.1400250922861; Fri, 16 May 2014 07:35:22 -0700 (PDT) Received: by 10.220.136.72 with HTTP; Fri, 16 May 2014 07:35:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 May 2014 10:35:22 -0400 Message-ID: From: Andrew Stone To: Andy Bierman Content-Type: multipart/alternative; boundary=001a11336a2eda9c1704f9855225 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6EIMTYsjKaQaJnAwM3lE8FasRW8 Cc: Netconf Subject: Re: [Netconf] YANG and binary data blobs 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 May 2014 14:35:38 -0000 --001a11336a2eda9c1704f9855225 Content-Type: text/plain; charset=UTF-8 How is it possible that I missed that!!! Anyway, thanks! On Thu, May 15, 2014 at 1:42 PM, Andy Bierman wrote: > > > > On Thu, May 15, 2014 at 10:32 AM, Andrew Stone wrote: > >> Hi, >> >> I want to specify a blob of binary data -- for example, an image or an >> array of data points that the mgt app might present as a chart. >> >> Originally I formulated this as a leaf-list of a fundamental type (int). >> But I see now in RFC6020 that leaf-list is actually more like a set. That >> is, elements with the same value are not allowed. >> >> Next possibility (please excuse any typos I'm writing this right now) is >> >> list { >> key id; >> leaf id { type int; } >> leaf val { type int; } >> } >> >> This formulation has a few problems: >> 1. it is not clear that this is not a "sparse" list -- that a good >> underlying representation would be an array >> 2. it implicitly puts the key "id" as a member of the list element -- in >> "C": { int id; int val; }. But I suppose again a customized implementation >> could dispense with this. >> 3. inefficient Netconf XML. >> 4. unnecessary ability to reference individual elements. >> >> What do you use for binary data blobs? >> >> > How about the "binary" type defined in RFC 6020, sec. 9.8? > > > >> Regards, >> Andrew >> >> > Andy > > >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > --001a11336a2eda9c1704f9855225 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How is it possible that I missed that!!!

Anyway, thanks!


On Thu, May 15, 2014 at 1:42 PM, Andy Bierman <andy@yumawor= ks.com> wrote:



On Thu, May 1= 5, 2014 at 10:32 AM, Andrew Stone <stone@openclovis.com> = wrote:
Hi,

I want to specify a blob of binary d= ata -- for example, an image or an array of data points that the mgt app mi= ght present as a chart.

Originally I formulated this as a leaf-list of a fundamental type (in= t).=C2=A0 But I see now in RFC6020 that leaf-list is actually more like a s= et.=C2=A0 That is, elements with the same value are not allowed.

Next possibility (please excuse any typos I'm writing this right now= ) is

list {
=C2=A0 key id;
=C2=A0 leaf id { typ= e int; }
=C2=A0 leaf val { type int; }
}

This form= ulation has a few problems:
1. it is not clear that this is not a = "sparse" list -- that a good underlying representation would be a= n array
2. it implicitly puts the key "id" as a member of the list = element -- in "C": { int id; int val; }.=C2=A0 But I suppose agai= n a customized implementation could dispense with this.
3. ineffic= ient Netconf XML.
4. unnecessary ability to reference individual elements.

What do you use for binary data blobs?

=

How about the "binary&quo= t; type defined in RFC 6020, sec. 9.8?

=C2=A0
Regards,
Andrew


Andy
=C2=A0
_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf



--001a11336a2eda9c1704f9855225-- From nobody Fri May 16 09:51:18 2014 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 9DDDC1A02B0 for ; Fri, 16 May 2014 09:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8UyfuEyCo45 for ; Fri, 16 May 2014 09:51:13 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180F41A02E6 for ; Fri, 16 May 2014 09:51:12 -0700 (PDT) Received: from DBXPRD0210HT002.eurprd02.prod.outlook.com (157.56.253.181) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.0.944.11; Fri, 16 May 2014 16:51:03 +0000 Message-ID: <008601cf7126$abc5da00$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , "Bert Wijnen (IETF)" References: <201403251517.LAA15291@adminfs.snmp.com> <533D47CF.30402@bwijnen.net> <01f401cf5342$4d48d740$4001a8c0@gateway.2wire.net> <032f01cf6524$71cb2340$4001a8c0@gateway.2wire.net> <5368C366.8070509@bwijnen.net> <023701cf69d5$abcfb320$4001a8c0@gateway.2wire.net> <007201cf6a9c$aa76f980$4001a8c0@gateway.2wire.net> <00da01cf6dd5$ce36e740$4001a8c0@gateway.2wire.net> <021c01cf6f54$e6ed96a0$4001a8c0@gateway.2wire.net> Date: Fri, 16 May 2014 17:38:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.181] X-ClientProxiedBy: DB3PR07CA010.eurprd07.prod.outlook.com (10.242.134.50) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) X-Forefront-PRVS: 02135EB356 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(164054003)(199002)(189002)(377454003)(101416001)(99396002)(87976001)(20776003)(23756003)(46102001)(89996001)(77982001)(14496001)(77156001)(76482001)(42186004)(4396001)(80022001)(66066001)(85852003)(64706001)(19300405004)(102836001)(33646001)(81542001)(50466002)(1941001)(79102001)(44716002)(81342001)(87286001)(92726001)(86362001)(81816999)(62966002)(81686999)(84392001)(76176999)(74502001)(50226001)(88136002)(83322001)(19580405001)(62236002)(19580395003)(50986999)(61296002)(21056001)(74416001)(7726001)(562404015); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB054; H:DBXPRD0210HT002.eurprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wftRNPksnIaapyXgBe9wmtqcuOI Cc: netconf@ietf.org Subject: Re: [Netconf] WG Last Call Comments ondraft-ietf-netconf-reverse-ssh-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 May 2014 16:51:16 -0000 ----- Original Message ----- From: "Kent Watsen" To: "t.petch" ; "Bert Wijnen (IETF)" Cc: Sent: Wednesday, May 14, 2014 10:30 PM Hi Tom, >No, we are still not meeting anywhere in the middle. On this we can agree, but hopefully we'll get there soon ;) >It seems to me that you are proposing that all devices share the same >private key and so the same public key (in which case the choice of CA >seems irrelevant). Of course not, each device must have unique private keys. The zero-touch draft goes into more specifics regarding certificate construction and use of PKI. >As >http://www.rfc-editor.org/rfc/rfc5592.txt >says "this requires the client > to know the host's public key a priori and to verify that the correct > key is being used." >which is the sort of thing I would expect to see, in the absence of >X.509 certificates. With certificates, then you know the subjectAltName >a priori. Either way, you configure the NMS for every device. The zero-touch draft touches on this as well: So what:-) Perhaps we are not agreeing because you have zero touch in mind, whereas I expect certificates to be used without zero touch (as they long have been with TLS). I expect this I-D to make sense when taken with its Normative references and, for me, at present, it does not. If you have 1000 devices, then the NMS needs configuring with 1000 identifiers, and if that does not scale for host keys, then I do not see it scaling for any other identifier, be it the subjectAlternateName in a certificate or anything else, so for me, the references to 'does not scale' do not make sense. There is no magic short cut to configuring the NMS once for 1000 devices, unless they share some property such as a private key. Likewise, if the identifier is embedded in the host key by some means, you still have 1000 identifiers to configure in the NMS I do not think it enough to leave it up to implementations. We should recommend something that is secure, and do it not just because a Security AD says so. My experience is that Security ADs usually ask for too much but equally, most WGs start out with too little and for me at present, we are too close to the latter. Tom Petch Section 3.5: The NMS SHOULD also validate that the unique identifier (e.g., serial number), within the "Common Name" field of the device's X.509 certificate, is an identity that the NMS is expecting, and not another device having the same device type. In order for the NMS to know the unique identifiers for devices shipped directly to their destinations, it may be necessary for the device manufacturer to provide the unique identifiers along with other shipping or billing information. This draft not specify a format for this information exchange. Section 4.1: The unique identifier MUST be something that is both known to the device and easily tracked through labels affixed to the device as well as the box it is packaged in. A device's serial number is commonly treated this way and would be suitable for this purpose. I guess my point is that we agree on how the solution can scale. The reverse-ssh draft leaves it up to deployments to decide what to do, while the zero-touch draft specifies a specific solution that satisfies all its particular use-cases. Thanks, Kent From nobody Tue May 20 12:07:20 2014 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 3A0C91A078D for ; Tue, 20 May 2014 12:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 ONhsSI6GvbWx for ; Tue, 20 May 2014 12:07:13 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBF11A078C for ; Tue, 20 May 2014 12:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17578; q=dns/txt; s=iport; t=1400612832; x=1401822432; h=from:to:subject:date:message-id:mime-version; bh=vLkBCZd10gVu3O4xu7ZZf4H9rhFEfrcw2tsES6DMQ+Y=; b=VIC26FQvHRskyS5e5eTjDa4WbMpZLnsEHyHqR7c+YjImO4vOHGy5m+tD BS/sw/lvske33oPSbmAV4Fo3/O1OSO3Cdsx+uKUWKctlNvBLAZTyO2jHn BQ5gDeUfJPzisZ+7u5f58e41Y9lzgJ94AsG2/imzLG6qDURdlndpwa7uw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAIAJ+me1OtJA2E/2dsb2JhbABZgkJEUVipYwEBAQEBAQUBmiyBHxZ0giyBCwEcZCcEiFQNoAazcxeFVYgMXIRYBJlogT2RY4M4gjA X-IronPort-AV: E=Sophos; i="4.98,875,1392163200"; d="scan'208,217"; a="45586830" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP; 20 May 2014 19:07:11 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s4KJ7B6V003390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 May 2014 19:07:11 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 20 May 2014 14:07:11 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: Netconf Thread-Topic: Restconf: rendering lists Thread-Index: AQHPdF6zlp+r3AnC40i47zqKoVK6Sw== Date: Tue, 20 May 2014 19:07:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.204.210] Content-Type: multipart/alternative; boundary="_000_CFA0F5DE6C646albertgociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zTZUJtnhxAUMobnoInV1lWiItP8 Subject: [Netconf] Restconf: rendering lists 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 May 2014 19:07:18 -0000 --_000_CFA0F5DE6C646albertgociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I have some questions on how a server must render lists. Looking at examples in the spec for getting data, I see that when rendering= (in json) lists with only one entry , the responses use two approaches: re= ndering it as an array or a singleton. (See snippets below). The requests are different in that the second one requests a list and the f= irst requests a container that contains a list. I am assuming this is not a= factor when rendering a list. Is it? Is the server free to choose between these two ways of encoding a list with= a single entry? GET /restconf/data/example-jukebox:jukebox?depth=3D3 HTTP/1.1 Host: example.com Accept: application/yang.data+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" : { "library" : { "artist" : [ null ] }, "playlist" : [ # 1 playlist encoded as an array { "name" : "Foo-One", "description" : "example playlist 1", "song" : [ null ] } ], "player" : { "gap" : 0.5 } } } GET /restconf/data/example-jukebox:jukebox/ library/artist/Foo%20Fighters/album HTTP/1.1 Host: example.com Accept: application/yang.data+json The server might respond: 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 { "album" : { # 1 album, no array encoding "name" : "Wasting Light", "genre" : "example-jukebox:alternative", "year" : 2011 } } Considering XML encoding now. The XML equivalent of the example above could be something like: Wasting Light example-jukebox:alternative 2011 Now, if there were more than one album, to have in the response a legal XML= doc (a single root), I understand we would need to include album's parent. Something like: (=85) (=85) Is this the case? If so, would it make sense encoding all lists (regardless the number of ent= ries in it) using the same structure? That is, rendering the example above as: (=85) Thanks, Alberto --_000_CFA0F5DE6C646albertgociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <60957A9E94556C45960D9C674B2B3786@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

I have some questions on how a server must render lists.
Looking at examples in the spec for getting data, I see that when rendering= (in json) lists with only one entry , the responses use two approache= s: rendering it as an array or a singleton.
(See snippets below).
The requests are different in that the second one requests a list and the f= irst requests a container that contains a list. I am assuming this is not a= factor when rendering a list. Is it?
Is the server free to choose between these two ways of encoding a list with= a single entry? 


GET /restconf/data/example-j=
ukebox:jukebox?depth=3D3 HTTP/1.1
      Host: example.com
      Accept: application/yang.data+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" : {
          "library" : {
            "artist" : [ null ]
          },
          "playlist" : [ # 1 playlist =
encoded as an array
            {
              "name" : "Foo-One",
              "description" : "example playlist 1",
              "song" : [ null ]
            }
          ],
          "player" : {
            "gap" : 0.5
          }
        }
      }




      G=
ET /restconf/data/example-jukebox:jukebox/
        library/artist/Foo%20Fighters/album  HTTP/1.1
      Host: example.com
      Accept: application/yang.data+json

   The server might respond:


      H=
TTP/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

      {
        "album" : {  # 1 album, no arr=
ay encoding
          "name" : "Wasting Light",
          "genre" : "example-jukebox:alternative",
          "year" : 2011
        }
      }












Considerin=
g XML encoding now.





T=
he XML equivalent of the example above could be something like:


<=
br>


      <album xmlns=3D"http://example.com=
/ns/example-jukebox">

=

Now, if there were more than one albu=
m, to have in the response a legal XML doc (a single root), I understand we would need to include album's paren=
t.
Something like:
=

<artist>
    <album>
=
        (=85)
    </album>=

    <album>
        (=85)
    </album>
</artist>

Is this the case? 
If so, would it make sense encoding all lists (regardless the number of entries in it) using <=
span style=3D"white-space: normal;">the same structure?
That is, rendering the example above as:


<artist>
    <album>
        (=85)
    </album>
<=
/artist>

Thanks,

Alberto



--_000_CFA0F5DE6C646albertgociscocom_-- From nobody Tue May 20 12:41:29 2014 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 263F31A0388 for ; Tue, 20 May 2014 12:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 c_AwOOv68afg for ; Tue, 20 May 2014 12:41:26 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D761A019B for ; Tue, 20 May 2014 12:41:26 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id z60so1542286qgd.37 for ; Tue, 20 May 2014 12:41:25 -0700 (PDT) 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=3thmTI1QwX/i76BNpcgiOKOF2sQGtwjEUIAKLYpREfs=; b=Hb99SxaVaVl6g/UjndGPmND5T6e7VyNOEJS4/fuOWYejtmScFGRyADOLQWLlVuCxQW SalIqi6P8XlIa/hDmWXDg7ZiHXjtEywxtroAZCcOQde7Xgvt47TxSQwi17MgvJuxtp/0 y7z7ILA0CjbV43hIT8Qp0B4JREI6FfyDxYWDz9oi8eglFjrHA5UNCvHckuyvuCpGYvlp 0vZOOJr0A4uAI7ifK/BR9+4MTXRn0Mwb6kxoPLl6XwhAJ4AejR+2ZnqyXN9jqHN7/bq9 6ATQjLrw1kXNqy1K/78P0JNBezKPV6/3ofak+qO1ZbpjpjOyMyTGl2sm2qfSAO1uGUtP PY3A== X-Gm-Message-State: ALoCoQnbwcVRVMECp88D+L4x83OnM1WROjTucC7wKe93FgV5YI2Zz4PocweFr2j+PbWbx8jKRdfe MIME-Version: 1.0 X-Received: by 10.224.125.74 with SMTP id x10mr57568640qar.99.1400614885191; Tue, 20 May 2014 12:41:25 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Tue, 20 May 2014 12:41:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 May 2014 12:41:25 -0700 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a11c30886b30b3c04f9da1013 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7FmtMh4m5xdH0KSIQ0hm3O8e3Z8 Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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 May 2014 19:41:28 -0000 --001a11c30886b30b3c04f9da1013 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 20, 2014 at 12:07 PM, Alberto Gonzalez Prieto (albertgo) < albertgo@cisco.com> wrote: > Hi, > > I have some questions on how a server must render lists. > Looking at examples in the spec for getting data, I see that when > rendering (in json) lists with only one entry , the responses use two > approaches: rendering it as an array or a singleton. > (See snippets below). > The requests are different in that the second one requests a list and the > first requests a container that contains a list. I am assuming this is not > a factor when rendering a list. Is it? > Is the server free to choose between these two ways of encoding a list > with a single entry? > > > The 2nd example is a bug. According to the JSON draft, all YANG lists are encoded as arrays. Andy > GET /restconf/data/example-jukebox:jukebox?depth=3 HTTP/1.1 > Host: example.com > Accept: application/yang.data+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" : { > "library" : { > "artist" : [ null ] > }, > *"playlist" : [ # 1 playlist encoded as an array > { > "name" : "Foo-One", > "description" : "example playlist 1", > "song" : [ null ] > } > ],* > "player" : { > "gap" : 0.5 > } > } > } > > > > > GET /restconf/data/example-jukebox:jukebox/ > library/artist/Foo%20Fighters/album HTTP/1.1 > Host: example.com > Accept: application/yang.data+json > > The server might respond: > > > 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 > > { > *"album" : { # 1 album, no array encoding > "name" : "Wasting Light", > "genre" : "example-jukebox:alternative", > "year" : 2011 > }* > } > > > > > > Considering XML encoding now. > > > The XML equivalent of the example above could be something like: > > > > > Wasting Light > example-jukebox:alternative > 2011 > > > > Now, if there were more than one album, to have in the response a legal XML doc (a single root), I understand we would need to include album's parent. > > Something like: > > > > > > > (...) > > > > > > (...) > > > > > > > Is this the case? > > If so, would it make sense encoding all lists (regardless the number of entries in it) using the same structure? > > That is, rendering the example above as: > > > > > > (...) > > > > > > > Thanks, > > Alberto > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c30886b30b3c04f9da1013 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, May 20, 2014 at 12:07 PM, Alberto Gonzalez Prieto (albertgo= ) <albertgo@cisco.com> wrote:
Hi,

I have some questions on how a server must render lists.
Looking at examples in the spec for getting data, I see that when rendering= (in json) lists with only one entry , the responses use two approache= s: rendering it as an array or a singleton.
(See snippets below).
The requests are different in that the second one requests a list and the f= irst requests a container that contains a list. I am assuming this is not a= factor when rendering a list. Is it?
Is the server free to choose between these two ways of encoding a list with= a single entry? 



The 2nd example is a bug.<= /div>
According to the JSON draft, all YANG lists are encoded as arrays= .

Andy
 



      GET /restconf/data/example-jukebox:jukebox/
        library/artist/Foo%20Fighters/album  HTTP/1.1
      Host: example.com
      Accept: application/yang.data+json

   The server might respond:


      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

      {
        "album" : {  # 1 album, no arr=
ay encoding
          "name" : "Wasting Light",
          "genre" : "example-jukebox:alternative",
          "year" : 2011
        }
      }




Considering XML encoding now.

The XML equivalent of the example above could be so=
mething like:

      <album xmlns=3D"http://example.com/ns/example=
-jukebox">


         <=
name>Wasting Light</name>
         <genre>example-jukebox:alternative</genre>
         <year>2011</year>
      </album>

Now, if there were more than one album, t=
o have in the response a legal XML doc (a single root), I understand we would need to include album's parent.


Something like:



<artist>
    <al=
bum>
        (<=
/font>…)
    </album>
    <album>
        (…)=



    </album>
&l=
t;/artist>



Is this the case? 


If so, would it make sense encoding a=
ll lists (regardless the num=
ber of entries=
 in it) using the same structure?


That is, rendering the example above=
 as:
<artist>
=

    <album>
        (…)


    </album>
</artist>
=



Thanks,


Alberto



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


--001a11c30886b30b3c04f9da1013-- From nobody Tue May 20 13:40:20 2014 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 ED4811A0791 for ; Tue, 20 May 2014 13:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 EqHpfM9Qy9FG for ; Tue, 20 May 2014 13:40:14 -0700 (PDT) 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 473741A0793 for ; Tue, 20 May 2014 13:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10087; q=dns/txt; s=iport; t=1400618414; x=1401828014; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=FYF4YMCPZSMYIshBrOhkfRkB07jBdk0517juYhfciWw=; b=ZZ4z2PYLzunDXv5VkSrVp8aEM1Ums1mb1lMoqareyzhOt91zTe1hjHBr 7oLyToWk9UXoHXW/Bj814+KoumCiuH84hys5T+O0IxelmLM05a075rnYC 9uN/nTf0el+OpkU3imX57/GQcUv2Kz2mS0Er3N/k/HKqrJ6OgtjPmHArv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkIAHm8e1OtJA2N/2dsb2JhbABZgkJEUVipZAEBAQEBAQUBknEBhmlRAYEeFnSCJwEEAQEBawsSAQg/LgsUEQIEDgWIQQ3ULBeFVYh1BAeEQASZaIE9kWODOIIw X-IronPort-AV: E=Sophos;i="4.98,875,1392163200"; d="scan'208,217";a="323428176" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 20 May 2014 20:40:13 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4KKeDJP028419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 May 2014 20:40:13 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 20 May 2014 15:40:12 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: Andy Bierman Thread-Topic: [Netconf] Restconf: rendering lists Thread-Index: AQHPdGN9iVsEON7Tu0Cj9Ilr/qXZVJtJzROA Date: Tue, 20 May 2014 20:40:12 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.204.210] Content-Type: multipart/alternative; boundary="_000_CFA10B446C725albertgociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ADxkNbxtaIiIGYBAwrhal2qZ_vQ Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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 May 2014 20:40:18 -0000 --_000_CFA10B446C725albertgociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Andy, I appreciate the prompt response. Can you comment on the XML encoding? Thanks, Alberto Considering XML encoding now. The XML equivalent of the example above could be something like: Wasting Light example-jukebox:alternative 2011 Now, if there were more than one album, to have in the response a legal XML= doc (a single root), I understand we would need to include album's parent. Something like: (=85) (=85) Is this the case? If so, would it make sense encoding all lists (regardless the number of ent= ries in it) using the same structure? That is, rendering the example above as: (=85) Thanks, Alberto _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_CFA10B446C725albertgociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <35326B2A9D6FD8429EBDF87455BB5F0E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Andy,

I appreciate the prompt response.

Can you comment on the XML encoding?

Thanks,

Alberto



Considering XML encoding now.

The XML equivalent of the example above could be so=
mething like:

      <album xmlns=3D"http://example.com/ns/example=
-jukebox">
         <name>Wasting Light</name>
         <genre>example-jukebox:alternative</genre>
         <year>2011</year>
      </album>

Now, if there were more than one album, t=
o have in the response a legal XML doc (a single root), I understand we would need to include album's parent.<=
/font>
Something like:
<=
span style=3D"font-size:1em;white-space:normal">
<artist>
    <album>
        (=85)
    </album>
    <album>
        (=85)
    </album>=

</artist>

Is=
 this the case? 
If so, would it make sense encoding all lists (regardless the number of entries in it) using the same structure?
That is, rendering the example above as:
<artist>
=

    <album>
<=
span style=3D"font-size:1em;white-space:normal">       =
 (=85)
&n=
bsp;   </album>
</artist>

=

Thanks,

Alberto




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


 --_000_CFA10B446C725albertgociscocom_-- From nobody Tue May 20 14:07:08 2014 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 B1D691A07AC for ; Tue, 20 May 2014 14:07:05 -0700 (PDT) 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 CCNpYb4pXGqD for ; Tue, 20 May 2014 14:07:03 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2979C1A07AF for ; Tue, 20 May 2014 14:07:03 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id r5so1721653qcx.7 for ; Tue, 20 May 2014 14:07:02 -0700 (PDT) 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=CfWI7fiYiy8fnigL4Q5tQZEq8oaxdoQ4echC+QEbQ70=; b=ackq7dbLxA7jFJfi/5nDe1aoyzox2id+FJNVPC3S+TmjBayW2VBwv59GCH1XdDuvLT baHfaFphEBT6TY1iVoK3k4+51xs2x/bBJX6uCs0zxpX/yAKeVZRBjtqU0C6OyhcK2SqU 1eRirjU/qInpnUN2m2lp+WDfeGBUMB+1mtcPLfoSI3Wuw1dU0kalU7Ma7CCMyYeKogxa dp8RBD5+DgPbA+CghIu3NOvytuAOlk+el7A07sFLTlg8MJHPugROFCHzzfD5wZ2LrzB6 ikMNE5m706lisjFTz74DlN8TX+ML/+m1B2dpMWBqVUeekJsX/pJ2kdQPz94bqVYoTC1r onig== X-Gm-Message-State: ALoCoQmJjwAMJ7F3QComnjSKB6ok2H1tF2qUZTO92aYgppAEB2rvw9i8gXSfToQ9lbU2cBGo1dMY MIME-Version: 1.0 X-Received: by 10.140.27.245 with SMTP id 108mr60204928qgx.18.1400620021978; Tue, 20 May 2014 14:07:01 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Tue, 20 May 2014 14:07:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 May 2014 14:07:01 -0700 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a11c15260e02f1504f9db42cf Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/S83RUg8bx375C88Cx5-j2zYY8JQ Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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 May 2014 21:07:06 -0000 --001a11c15260e02f1504f9db42cf Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertgo) < albertgo@cisco.com> wrote: > Thanks Andy, > > I appreciate the prompt response. > > Can you comment on the XML encoding? > > It is currently an open issue for the next draft. How should collections be handled? If the target resource is a list, then a wrapper element is needed in XML to return a valid XML instance document, The element or is being considered for this purpose. A side issue is whether the JSON encoding should also have this wrapper, so client applications can use the same code for both encodings, or should a JSON array should be returned instead, without the wrapper (just the target resource list)? The current proposal is to create a new "YANG collection" resource and return a top-level element if a list or leaf-list is the target resource. A wrapper for JSON will be used so the data matches the resource type (application/yang.collection has N child nodes that are type application/yang.data). > Thanks, > > Alberto > Andy > > >> >> Considering XML encoding now. >> >> >> The XML equivalent of the example above could be something like: >> >> >> >> >> Wasting Light >> example-jukebox:alternative >> 2011 >> >> >> >> Now, if there were more than one album, to have in the response a legal XML doc (a single root), I understand we would need to include album's parent. >> >> Something like: >> >> >> >> >> >> >> (...) >> >> >> >> >> >> (...) >> >> >> >> >> >> >> Is this the case? >> >> If so, would it make sense encoding all lists (regardless the number of entries in it) using the same structure? >> >> That is, rendering the example above as: >> >> >> >> >> >> (...) >> >> >> >> >> >> >> Thanks, >> >> Alberto >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > --001a11c15260e02f1504f9db42cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertgo)= <albertgo@cisco.com> wrote:
Thanks Andy,

I appreciate the prompt response.

Can you comment on the XML encoding?


It is currently an op= en issue for the next draft.
How should collections be handled?

If the target resource is a list, then a wrapper el= ement
is needed in XML to return a valid XML instance document,
Th= e element <data> or <collection> is being considered
= for this purpose.

A side issue is whether the JSON= encoding should also
have this wrapper, so client applications can use the
same c= ode for both encodings, or should a JSON array should
be returned= instead, without the wrapper (just the target resource list)?

The current proposal is to create a new "YANG collectio= n" resource
and return a top-level <data> element if a= list or leaf-list is the
target resource.  A wrapper for JS= ON will be used so the data
matches the resource type (application/yang.collection has N child nod= es that
are type application/yang.data).




 
Thanks,

Alberto


And= y
 



Considering XML encoding now.

The XML equivalent of the example above could be so=
mething like:

      <album xmlns=3D"http://example.com/ns/example=
-jukebox">


         <=
name>Wasting Light</name>
         <genre>example-jukebox:alternative</genre>
         <year>2011</year>
      </album>

Now, if there were more than one album, t=
o have in the response a legal XML doc (a single root), I understand we would need to include album's parent.


Something like:



<artist>
    <al=
bum>
        (<=
/font>…)
    </album>
    <album>
        (…)=



    </album>
&l=
t;/artist>



Is this the case? 


If so, would it make sense encoding a=
ll lists (regardless the num=
ber of entries=
 in it) using the same structure?


That is, rendering the example above=
 as:
<artist>
=

    <album>
        (…)


    </album>
</artist>
=



Thanks,


Alberto



_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--001a11c15260e02f1504f9db42cf-- From nobody Tue May 20 14:32:39 2014 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 9D3751A03E5 for ; Tue, 20 May 2014 14:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 VHzGAurULFiV for ; Tue, 20 May 2014 14:32:34 -0700 (PDT) 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 D38B41A03F9 for ; Tue, 20 May 2014 14:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15829; q=dns/txt; s=iport; t=1400621550; x=1401831150; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=/FZnBN8KK/PuTVtw2JXUGHydJOXYfwef8TrxlmbS8VI=; b=T/VmlJhxMyLn+shwF5u9GhqG8OU6kmGzu+dErha/kc/mO4BgQbEKhv8q YjWH3tjJE8pQ/wRM1sHrliqElTXf/8ZXbPklCBrh2eLrpvoao6xy9Pw4v Hg30TMBRfaN284CIVV2b0ebbjk+hHqupvhonigCmHLDmEgIuFR5KKfLBv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsIACLJe1OtJV2d/2dsb2JhbABZgkJEUVipZAEBAQEBAQUBknEBhmlRAYEeFnSCJQEBAQQBAQFrCxIBCBEDAQIoLgsUCQgCBA4FiEEN1EAXhVWIaA0EB4RABJlogT2RY4M4gjA X-IronPort-AV: E=Sophos;i="4.98,876,1392163200"; d="scan'208,217";a="326499676" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 20 May 2014 21:32:29 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4KLWSBm012109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 May 2014 21:32:28 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 20 May 2014 16:32:28 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: Andy Bierman Thread-Topic: [Netconf] Restconf: rendering lists Thread-Index: AQHPdGN9iVsEON7Tu0Cj9Ilr/qXZVJtJzROAgAB82oD//5G5gA== Date: Tue, 20 May 2014 21:32:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.204.210] Content-Type: multipart/alternative; boundary="_000_CFA1161D6C7B0albertgociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9dr6qJo_naySmDQeqcceLcYPwvc Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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 May 2014 21:32:36 -0000 --_000_CFA1161D6C7B0albertgociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Andy, For the root of the xml document, is the parent of the list being considere= d? A pro I see in this is that it would not require introducing nodes that are= not present in yang modules. On the "wrapper" for json. It would make sense to me aiming to keep content= s and their representation orthogonal. That is, if there is a wrapper for XML, also include it for JSON. Thanks, Alberto From: Andy Bierman > Date: Tuesday, May 20, 2014 2:07 PM To: Alberto Gonzalez Prieto > Cc: Netconf > Subject: Re: [Netconf] Restconf: rendering lists On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertgo) > wrote: Thanks Andy, I appreciate the prompt response. Can you comment on the XML encoding? It is currently an open issue for the next draft. How should collections be handled? If the target resource is a list, then a wrapper element is needed in XML to return a valid XML instance document, The element or is being considered for this purpose. A side issue is whether the JSON encoding should also have this wrapper, so client applications can use the same code for both encodings, or should a JSON array should be returned instead, without the wrapper (just the target resource list)? The current proposal is to create a new "YANG collection" resource and return a top-level element if a list or leaf-list is the target resource. A wrapper for JSON will be used so the data matches the resource type (application/yang.collection has N child nodes th= at are type application/yang.data). Thanks, Alberto Andy Considering XML encoding now. The XML equivalent of the example above could be something like: Wasting Light example-jukebox:alternative 2011 Now, if there were more than one album, to have in the response a legal XML= doc (a single root), I understand we would need to include album's parent. Something like: (=85) (=85) Is this the case? If so, would it make sense encoding all lists (regardless the number of ent= ries in it) using the same structure? That is, rendering the example above as: (=85) Thanks, Alberto _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_CFA1161D6C7B0albertgociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <399C515C328C474DB001EB0F169C0CAB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Andy,

For the root of the xml document, is the parent of the list being cons= idered?
A pro I see in this is that it would not require introducing nodes tha= t are not present in yang modules.

On the "wrapper" for json. It would make sense to me aiming = to keep contents and their representation orthogonal.
That is, if there is a wrapper for XML, also include it for JSON.

Thanks,

Alberto


From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, May 20, 2014 2:07 PM=
To: Alberto Gonzalez Prieto <albertgo@cisco.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Restconf: re= ndering lists




On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzale= z Prieto (albertgo) <albertgo@cisco.com> wrote:
Thanks Andy,

I appreciate the prompt response.

Can you comment on the XML encoding?


It is currently an open issue for the next draft.
How should collections be handled?

If the target resource is a list, then a wrapper element
is needed in XML to return a valid XML instance document,
The element <data> or <collection> is being considered
for this purpose.

A side issue is whether the JSON encoding should also
have this wrapper, so client applications can use the
same code for both encodings, or should a JSON array should
be returned instead, without the wrapper (just the target resource lis= t)?

The current proposal is to create a new "YANG collection" re= source
and return a top-level <data> element if a list or leaf-list is = the
target resource.  A wrapper for JSON will be used so the data
matches the resource type (application/yang.collection has N child nod= es that
are type application/yang.data).




 
Thanks,

Alberto


Andy
 



Considering XML encoding now.

The XML equivalent of the example above could be so=
mething like:

      <album xmlns=3D"http://example.com/ns/example=
-jukebox">
         <name>Wasting Light</name>
         <genre>example-jukebox:alternative</genre>
         <year>2011</year>
      </album>

Now, if there were more than one album, t=
o have in the response a legal XML doc (a single root), I understand we would need to include album's parent.<=
/font>
Something like:
<=
span style=3D"font-size:1em;white-space:normal">
<artist>
    <album>
        (=85)
    </album>
    <album>
        (=85)
    </album>=

</artist>

Is=
 this the case? 
If so, would it make sense encoding all lists (regardless the number of entries in it) using the same structure?
That is, rendering the example above as:
<artist>
=

    <album>
<=
span style=3D"font-size:1em;white-space:normal">       =
 (=85)
&n=
bsp;   </album>
</artist>

=

Thanks,

Alberto




_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf



 --_000_CFA1161D6C7B0albertgociscocom_-- From nobody Tue May 20 14:50:16 2014 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 15F101A03AB for ; Tue, 20 May 2014 14:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fhPcSwlPlofV for ; Tue, 20 May 2014 14:50:08 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A421A02BC for ; Tue, 20 May 2014 14:50:08 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id z60so1769516qgd.4 for ; Tue, 20 May 2014 14:50:07 -0700 (PDT) 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=SaZ/ciLSvRC7cchMvq/JArTGyP+V+87oNn355YswH6U=; b=hln8E296Zx1ab2qNZ24vlMSeyaA5HW8/FzXJEjVZAHDpjV0ILejJtsn2ksTNCmeui9 wVWApX978TqhqFcn13UH69LwZLsfczw0qFoYgWFV8JZO+5yjULDivJUU6vL/wy743+kr QBlXbQloyBEt/ICdrTw8FTQK79b4//GT6fWhblr0rP45aPFAF2oYI8UEzEI7SqBmDHap S1AX9+JCSzpIsxWUfYy2y3qEPlYK3zX6a9z8jSMRRm3rPFyRqFMY/Z/EQXBCi4O1p01G sLm425KljAG2QbcOm6TzX2czmtyzQx/sx8E0tcRfd6VvHHil3f8KHz0uc9oxOY2sEsgY GdQA== X-Gm-Message-State: ALoCoQnII18jELbe35kH7eXWS/9SNBIq5V/lgK4GvyKlYuXAm16E39sGxNF8/2osqOO3Jb3FJPEP MIME-Version: 1.0 X-Received: by 10.140.36.105 with SMTP id o96mr60452971qgo.25.1400622606920; Tue, 20 May 2014 14:50:06 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Tue, 20 May 2014 14:50:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 May 2014 14:50:06 -0700 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a11c17334f3438804f9dbdc80 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6XvijQsAZgy9H-9IAYsfS-EcYm8 Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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 May 2014 21:50:10 -0000 --001a11c17334f3438804f9dbdc80 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 20, 2014 at 2:32 PM, Alberto Gonzalez Prieto (albertgo) < albertgo@cisco.com> wrote: > Thanks Andy, > > For the root of the xml document, is the parent of the list being > considered? > A pro I see in this is that it would not require introducing nodes that > are not present in yang modules. > > Except for top-level nodes -- then the datastore parent would be returned. The co-authors agreed on a new resource type (collection) to identify this special case: * The 'select' parameter affects data returned in collections * The data returned may not represent a valid resource (because it is only a subset or depth altered) * The paging parameters being added (offset + limit) also only apply to collections. Note that you can use RESTCONF to get the parent and all instances of the list: container collection { list list { ... } } GET /restconf/datastore/collection?select=list On the "wrapper" for json. It would make sense to me aiming to keep > contents and their representation orthogonal. > That is, if there is a wrapper for XML, also include it for JSON. > > Agreed > Thanks, > > Alberto > > Andy > From: Andy Bierman > Date: Tuesday, May 20, 2014 2:07 PM > To: Alberto Gonzalez Prieto > Cc: Netconf > Subject: Re: [Netconf] Restconf: rendering lists > > > > > On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertgo) < > albertgo@cisco.com> wrote: > >> Thanks Andy, >> >> I appreciate the prompt response. >> >> Can you comment on the XML encoding? >> >> > It is currently an open issue for the next draft. > How should collections be handled? > > If the target resource is a list, then a wrapper element > is needed in XML to return a valid XML instance document, > The element or is being considered > for this purpose. > > A side issue is whether the JSON encoding should also > have this wrapper, so client applications can use the > same code for both encodings, or should a JSON array should > be returned instead, without the wrapper (just the target resource list)? > > The current proposal is to create a new "YANG collection" resource > and return a top-level element if a list or leaf-list is the > target resource. A wrapper for JSON will be used so the data > matches the resource type (application/yang.collection has N child nodes > that > are type application/yang.data). > > > > > > >> Thanks, >> >> Alberto >> > > > Andy > > >> >> >>> >>> Considering XML encoding now. >>> >>> >>> The XML equivalent of the example above could be something like: >>> >>> >>> >>> >>> Wasting Light >>> example-jukebox:alternative >>> 2011 >>> >>> >>> >>> Now, if there were more than one album, to have in the response a legal XML doc (a single root), I understand we would need to include album's parent. >>> >>> Something like: >>> >>> >>> >>> >>> >>> >>> (...) >>> >>> >>> >>> >>> >>> (...) >>> >>> >>> >>> >>> >>> >>> Is this the case? >>> >>> If so, would it make sense encoding all lists (regardless the number of entries in it) using the same structure? >>> >>> That is, rendering the example above as: >>> >>> >>> >>> >>> >>> (...) >>> >>> >>> >>> >>> >>> >>> Thanks, >>> >>> Alberto >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> > --001a11c17334f3438804f9dbdc80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, May 20, 2014 at 2:32 PM, Alberto Gonzalez Prieto (albertgo)= <albertgo@cisco.com> wrote:
Thanks Andy,

For the root of the xml document, is the parent of the list being cons= idered?
A pro I see in this is that it would not require introducing nodes tha= t are not present in yang modules.


Except for top-level = nodes -- then the datastore parent would be returned.
The co-auth= ors agreed on a new resource type (collection)
to identify this s= pecial case:
   *  The 'select' parameter affects data retur= ned in collections
   * The data returned may not repre= sent a valid resource
      (because it is only a = subset or depth altered)
   * The paging parameters bei= ng added (offset + limit) also only apply
     to collections.

Note that= you can use RESTCONF to get the parent and all instances
of the = list:

  container collection {
&nbs= p;    list list { ... }
  }


  GET /restconf/= datastore/collection?select=3Dlist


On the "wrapper" for json. It would make sense to me aiming = to keep contents and their representation orthogonal.
That is, if there is a wrapper for XML, also include it for JSON.


Agreed

=
 
Thanks,

Alberto


Andy

 



From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, May 20, 2014 2:07 PM=
To: Alberto Gonzalez Prieto <albertgo@cisco.com= >
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Restconf: re= ndering lists




On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzale= z Prieto (albertgo) <albertgo@cisco.com> wrote:
Thanks Andy,

I appreciate the prompt response.

Can you comment on the XML encoding?


It is currently an open issue for the next draft.
How should collections be handled?

If the target resource is a list, then a wrapper element
is needed in XML to return a valid XML instance document,
The element <data> or <collection> is being considered
for this purpose.

A side issue is whether the JSON encoding should also
have this wrapper, so client applications can use the
same code for both encodings, or should a JSON array should
be returned instead, without the wrapper (just the target resource lis= t)?

The current proposal is to create a new "YANG collection" re= source
and return a top-level <data> element if a list or leaf-list is = the
target resource.  A wrapper for JSON will be used so the data
matches the resource type (application/yang.collection has N child nod= es that
are type application/yang.data).




 
Thanks,

Alberto


Andy
 



Considering XML encoding now.

The XML equivalent of the example above could be so=
mething like:

      <album xmlns=3D"http://example.com/ns/example=
-jukebox">


         <=
name>Wasting Light</name>
         <genre>example-jukebox:alternative</genre>
         <year>2011</year>
      </album>

Now, if there were more than one album, t=
o have in the response a legal XML doc (a single root), I understand we would need to include album's parent.


Something like:



<artist>
    <al=
bum>
        (<=
/font>…)
    </album>
    <album>
        (…)=



    </album>
&l=
t;/artist>



Is this the case? 


If so, would it make sense encoding a=
ll lists (regardless the num=
ber of entries=
 in it) using the same structure?


That is, rendering the example above=
 as:
<artist>
=

    <album>
        (…)


    </album>
</artist>
=



Thanks,


Alberto



_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--001a11c17334f3438804f9dbdc80-- From nobody Wed May 21 04:43:25 2014 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 177C61A0341 for ; Wed, 21 May 2014 04:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ia_dRyZ6ZkBh for ; Wed, 21 May 2014 04:43:21 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DC21A0314 for ; Wed, 21 May 2014 04:43:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6ADB1540696; Wed, 21 May 2014 13:43:18 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV9++tIDSEqw; Wed, 21 May 2014 13:43:14 +0200 (CEST) Received: from localhost (unknown [217.31.205.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id F1323540171; Wed, 21 May 2014 13:43:12 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , "Alberto Gonzalez Prieto \(albertgo\)" In-Reply-To: References: User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 21 May 2014 13:43:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/X1VrnpI5a3PXcF6nr8kvbu9aNGw Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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 May 2014 11:43:23 -0000 Andy Bierman writes: > On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertgo) < > albertgo@cisco.com> wrote: > >> Thanks Andy, >> >> I appreciate the prompt response. >> >> Can you comment on the XML encoding? >> >> > It is currently an open issue for the next draft. > How should collections be handled? > > If the target resource is a list, then a wrapper element > is needed in XML to return a valid XML instance document, > The element or is being considered > for this purpose. > > A side issue is whether the JSON encoding should also > have this wrapper, so client applications can use the > same code for both encodings, or should a JSON array should > be returned instead, without the wrapper (just the target resource list)? In my view, this shouldn't be needed in JSON because it means unnecessary clutter there. Clients and servers should be able handle such differences in XML/JSON data encoding quite easily. Lada > > The current proposal is to create a new "YANG collection" resource > and return a top-level element if a list or leaf-list is the > target resource. A wrapper for JSON will be used so the data > matches the resource type (application/yang.collection has N child nodes > that > are type application/yang.data). > > > > > > >> Thanks, >> >> Alberto >> > > > Andy > > >> >> >>> >>> Considering XML encoding now. >>> >>> >>> The XML equivalent of the example above could be something like: >>> >>> >>> >>> >>> Wasting Light >>> example-jukebox:alternative >>> 2011 >>> >>> >>> >>> Now, if there were more than one album, to have in the response a legal XML doc (a single root), I understand we would need to include album's parent. >>> >>> Something like: >>> >>> >>> >>> >>> >>> >>> (...) >>> >>> >>> >>> >>> >>> (...) >>> >>> >>> >>> >>> >>> >>> Is this the case? >>> >>> If so, would it make sense encoding all lists (regardless the number of entries in it) using the same structure? >>> >>> That is, rendering the example above as: >>> >>> >>> >>> >>> >>> (...) >>> >>> >>> >>> >>> >>> >>> Thanks, >>> >>> Alberto >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed May 21 08:01:48 2014 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 90B141A06C3 for ; Wed, 21 May 2014 08:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VFbZSu12dMD5 for ; Wed, 21 May 2014 08:01:44 -0700 (PDT) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130AC1A0692 for ; Wed, 21 May 2014 08:01:43 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so3471908qgd.1 for ; Wed, 21 May 2014 08:01:42 -0700 (PDT) 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=4GydG17binaZx6Ys7E6+4MOuhUyIfc1AmMR5jMjB4ig=; b=RfDu+vdeBBdy1r06/Rj1lEMlC8fAkrNDXB4k4/4D7Y9bFbn0TmjaqQkX3Lov9Mk3Uy zmtXCzxeGPH9BbO9oeTMelOVdALByBxAFMV8BP/oA4ZuiSoZBH7w8ah8b7D+YRCfqJjl cydnVhUUbiLB1iA5ZPdd7vLXHDdSQG6/5mrNjknED0zA1+F7KfoBcMEB/IsiELmpPFWI CvScsowtgrqSGpnRcGUNKDpMIMVijTlPdDIZdsnLNb9nSv/U9plTl9fcD/hwSFhwUnbd 1p+s7fj+l2eNnhwfCRwUStQOr2tGj+Kiv1m+54u8HFT93yOvviyEWr82l8tdLcNLMvRI maVA== X-Gm-Message-State: ALoCoQnsYy79bvhcJGvxVK0Ru2O1zXTEx/1iHtkXkr5Dy4EJVDK4BAP4IrGrvCnfL9gHWE3CX7W2 MIME-Version: 1.0 X-Received: by 10.224.125.74 with SMTP id x10mr4588448qar.99.1400684502508; Wed, 21 May 2014 08:01:42 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 21 May 2014 08:01:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 08:01:42 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c3088637d6af04f9ea46df Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pvh6GSdWkWt1e42cs0GKc_N01Sw Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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 May 2014 15:01:45 -0000 --001a11c3088637d6af04f9ea46df Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 21, 2014 at 4:43 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertgo) < > > albertgo@cisco.com> wrote: > > > >> Thanks Andy, > >> > >> I appreciate the prompt response. > >> > >> Can you comment on the XML encoding? > >> > >> > > It is currently an open issue for the next draft. > > How should collections be handled? > > > > If the target resource is a list, then a wrapper element > > is needed in XML to return a valid XML instance document, > > The element or is being considered > > for this purpose. > > > > A side issue is whether the JSON encoding should also > > have this wrapper, so client applications can use the > > same code for both encodings, or should a JSON array should > > be returned instead, without the wrapper (just the target resource list)? > > In my view, this shouldn't be needed in JSON because it means unnecessary > clutter there. Clients and servers should be able handle such differences > in XML/JSON data encoding quite easily. > > If there was a wrapper in JSON then the exact same client code path expressions will work in both. It is a hassle to alter the schema for URI or message body parsing, based on encoding. There are also operations/query parameters that only apply to collections. Returning the same node sometimes as a data resource and other times as a collection resource would be confusing. Lada > > Andy > > > > The current proposal is to create a new "YANG collection" resource > > and return a top-level element if a list or leaf-list is the > > target resource. A wrapper for JSON will be used so the data > > matches the resource type (application/yang.collection has N child nodes > > that > > are type application/yang.data). > > > > > > > > > > > > > >> Thanks, > >> > >> Alberto > >> > > > > > > Andy > > > > > >> > >> > >>> > >>> Considering XML encoding now. > >>> > >>> > >>> The XML equivalent of the example above could be something like: > >>> > >>> > >>> > >>> > >>> Wasting Light > >>> example-jukebox:alternative > >>> 2011 > >>> > >>> > >>> > >>> Now, if there were more than one album, to have in the response a > legal XML doc (a single root), I understand we would need to include > album's parent. > >>> > >>> Something like: > >>> > >>> > >>> > >>> > >>> > >>> > >>> (...) > >>> > >>> > >>> > >>> > >>> > >>> (...) > >>> > >>> > >>> > >>> > >>> > >>> > >>> Is this the case? > >>> > >>> If so, would it make sense encoding all lists (regardless the number > of entries in it) using the same structure? > >>> > >>> That is, rendering the example above as: > >>> > >>> > >>> > >>> > >>> > >>> (...) > >>> > >>> > >>> > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Alberto > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >>> > >>> > >> > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c3088637d6af04f9ea46df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 21, 2014 at 4:43 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertgo) &l= t;
> albertgo@cisco.com> wrote= :
>
>> =A0Thanks Andy,
>>
>> =A0I appreciate the prompt response.
>>
>> =A0Can you comment on the XML encoding?
>>
>>
> It is currently an open issue for the next draft.
> How should collections be handled?
>
> If the target resource is a list, then a wrapper element
> is needed in XML to return a valid XML instance document,
> The element <data> or <collection> is being considered
> for this purpose.
>
> A side issue is whether the JSON encoding should also
> have this wrapper, so client applications can use the
> same code for both encodings, or should a JSON array should
> be returned instead, without the wrapper (just the target resource lis= t)?

In my view, this shouldn't be needed in JSON because it means unnecessa= ry clutter there. Clients and servers should be able handle such difference= s in XML/JSON data encoding quite easily.


If there was a wrapper in JSON then th= e exact same client code
path expressions will work in both. =A0I= t is a hassle to alter the schema
for URI or message body parsing= , based on encoding.

There are also operations/query parameters that only ap= ply
to collections. =A0Returning the same node sometimes as
=
a data resource and other times as a collection resource
wou= ld be confusing.


Lada



Andy

=A0
>
> The current proposal is to create a new "YANG collection" re= source
> and return a top-level <data> element if a list or leaf-list is = the
> target resource. =A0A wrapper for JSON will be used so the data
> matches the resource type (application/yang.collection has N child nod= es
> that
> are type application/yang.data).
>
>
>
>
>
>
>> =A0Thanks,
>>
>> =A0Alberto
>>
>
>
> Andy
>
>
>>
>>
>>>
>>> Considering XML encoding now.
>>>
>>>
>>> The XML equivalent of the example above could be something lik= e:
>>>
>>>
>>> =A0 =A0 =A0 <album xmlns=3D"http://example.com/ns/example-juk= ebox">
>>>
>>> =A0 =A0 =A0 =A0 =A0<name>Wasting Light</name>
>>> =A0 =A0 =A0 =A0 =A0<genre>example-jukebox:alternative<= ;/genre>
>>> =A0 =A0 =A0 =A0 =A0<year>2011</year>
>>> =A0 =A0 =A0 </album>
>>>
>>>
>>> Now, if there were more than one album, to have in the respons= e a legal XML doc (a single root), I understand we would need to include al= bum's parent.
>>>
>>> Something like:
>>>
>>>
>>> <artist>
>>>
>>> =A0 =A0 <album>
>>>
>>> =A0 =A0 =A0 =A0 (...)
>>>
>>> =A0 =A0 </album>
>>>
>>> =A0 =A0 <album>
>>>
>>> =A0 =A0 =A0 =A0 (...)
>>>
>>> =A0 =A0 </album>
>>>
>>> </artist>
>>>
>>>
>>> Is this the case?
>>>
>>> If so, would it make sense encoding all lists (regardless the = number of entries in it) using the same structure?
>>>
>>> That is, rendering the example above as:
>>>
>>> =A0<artist>
>>>
>>> =A0 =A0 <album>
>>>
>>> =A0 =A0 =A0 =A0 (...)
>>>
>>> =A0 =A0 </album>
>>>
>>> </artist>
>>>
>>>
>>> Thanks,
>>>
>>> Alberto
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>>>
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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

--001a11c3088637d6af04f9ea46df-- From nobody Wed May 21 09:11:55 2014 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 4CC4A1A0845 for ; Wed, 21 May 2014 09:11:52 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] 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 WeCu8zjjgSTK for ; Wed, 21 May 2014 09:11:50 -0700 (PDT) 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 76FFA1A0346 for ; Wed, 21 May 2014 09:11:50 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7C18513FE2E; Wed, 21 May 2014 18:11:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1400688707; bh=ZZNA89hZS+jt9g/UAfsuWDkBnLqvNv0aAqsYSwDB7AA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sXTjJmlUfhEYcjcp0A2nVKlzdViCDaN0nGRT5cgQ7cvRzqyni2GiYP28OW06RYDvS 5lWlaD2Sa9EO73PsWM0tm6RDMQ+ctjKJfS6Avn7+hl+oJr148dS8LDAAWastYAY00a l9d2Zq2NgK81VUBVU8JCoWApKeJRCmB0ojRgKn+I= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 21 May 2014 18:11:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/fc4dZYJuyOqYm6LJKnjeMyWELvE Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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 May 2014 16:11:52 -0000 On 21 May 2014, at 17:01, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, May 21, 2014 at 4:43 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertgo) = < > > albertgo@cisco.com> wrote: > > > >> Thanks Andy, > >> > >> I appreciate the prompt response. > >> > >> Can you comment on the XML encoding? > >> > >> > > It is currently an open issue for the next draft. > > How should collections be handled? > > > > If the target resource is a list, then a wrapper element > > is needed in XML to return a valid XML instance document, > > The element or is being considered > > for this purpose. > > > > A side issue is whether the JSON encoding should also > > have this wrapper, so client applications can use the > > same code for both encodings, or should a JSON array should > > be returned instead, without the wrapper (just the target resource = list)? >=20 > In my view, this shouldn't be needed in JSON because it means = unnecessary clutter there. Clients and servers should be able handle = such differences in XML/JSON data encoding quite easily. >=20 >=20 > If there was a wrapper in JSON then the exact same client code > path expressions will work in both. It is a hassle to alter the = schema > for URI or message body parsing, based on encoding. Hmm=85 The dummy container should never appear in an URI, right? And as = for message body parsing, it is just a simple matter of adding (or removing) the extra container = after the payload has been parsed. =20 >=20 > There are also operations/query parameters that only apply > to collections. Returning the same node sometimes as > a data resource and other times as a collection resource > would be confusing. The data model says whether it is a collection or not. Lada >=20 >=20 > Lada >=20 >=20 >=20 > Andy >=20 > =20 > > > > The current proposal is to create a new "YANG collection" resource > > and return a top-level element if a list or leaf-list is the > > target resource. A wrapper for JSON will be used so the data > > matches the resource type (application/yang.collection has N child = nodes > > that > > are type application/yang.data). > > > > > > > > > > > > > >> Thanks, > >> > >> Alberto > >> > > > > > > Andy > > > > > >> > >> > >>> > >>> Considering XML encoding now. > >>> > >>> > >>> The XML equivalent of the example above could be something like: > >>> > >>> > >>> > >>> > >>> Wasting Light > >>> example-jukebox:alternative > >>> 2011 > >>> > >>> > >>> > >>> Now, if there were more than one album, to have in the response a = legal XML doc (a single root), I understand we would need to include = album's parent. > >>> > >>> Something like: > >>> > >>> > >>> > >>> > >>> > >>> > >>> (...) > >>> > >>> > >>> > >>> > >>> > >>> (...) > >>> > >>> > >>> > >>> > >>> > >>> > >>> Is this the case? > >>> > >>> If so, would it make sense encoding all lists (regardless the = number of entries in it) using the same structure? > >>> > >>> That is, rendering the example above as: > >>> > >>> > >>> > >>> > >>> > >>> (...) > >>> > >>> > >>> > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Alberto > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >>> > >>> > >> > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed May 21 12:18:54 2014 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 5B7251A052E for ; Wed, 21 May 2014 12:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Exadscd5TPwW for ; Wed, 21 May 2014 12:18:49 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADADA1A0765 for ; Wed, 21 May 2014 12:18:48 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id a108so4028239qge.11 for ; Wed, 21 May 2014 12:18:47 -0700 (PDT) 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=lPctOCDPpC79Vkf3tqQdOeS0adtPLk+ZKirG4PpaM10=; b=QTSRyk0iu4kUY/jX0Dkq7SLEztL+DVRHHFS+uXY32dAGKmdjYkROkkXDGu78h04PZE nuUyOH/m10NlyPpkNuEdY67Ovpw4OHlepGkOK5vrNAJYVTZ6dn8R1wyoP6hCaMLAwLfK g+/vUyyLRAU04zZM3Bymq3YjSA0TTp0yCUcEumeG1ZrNc0YCvaI5ANDbQy59g+6ei4eO qTHqriwnlfe9Zn6hiBRKYLCbBTC55mRwrEQhzzltNw9g8bLNYv/ixAw0FuJJf4QxRoUb 16SINP6zp3+u7XAhHZj5vr+kqQycNaIGifuA4YIbfZOZ1EJVUtjevTlWCrhTQBxPHUpx DeAA== X-Gm-Message-State: ALoCoQmWPwbEoK5SBJT1lc9B+zb67czbyxs2v4ISdVAwGpQxk59piWoZVWugSBns09q5vV7/q8KB MIME-Version: 1.0 X-Received: by 10.224.24.134 with SMTP id v6mr7354158qab.88.1400699927277; Wed, 21 May 2014 12:18:47 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 21 May 2014 12:18:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 12:18:47 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c252c69a666b04f9eddd71 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/JlOjKmCatcyBPvXzHyzkGXq6Aps Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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 May 2014 19:18:51 -0000 --001a11c252c69a666b04f9eddd71 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 21, 2014 at 9:11 AM, Ladislav Lhotka wrote: > > On 21 May 2014, at 17:01, Andy Bierman wrote: > > > > > > > > > On Wed, May 21, 2014 at 4:43 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertgo) < > > > albertgo@cisco.com> wrote: > > > > > >> Thanks Andy, > > >> > > >> I appreciate the prompt response. > > >> > > >> Can you comment on the XML encoding? > > >> > > >> > > > It is currently an open issue for the next draft. > > > How should collections be handled? > > > > > > If the target resource is a list, then a wrapper element > > > is needed in XML to return a valid XML instance document, > > > The element or is being considered > > > for this purpose. > > > > > > A side issue is whether the JSON encoding should also > > > have this wrapper, so client applications can use the > > > same code for both encodings, or should a JSON array should > > > be returned instead, without the wrapper (just the target resource > list)? > > > > In my view, this shouldn't be needed in JSON because it means > unnecessary clutter there. Clients and servers should be able handle such > differences in XML/JSON data encoding quite easily. > > > > > > If there was a wrapper in JSON then the exact same client code > > path expressions will work in both. It is a hassle to alter the schema > > for URI or message body parsing, based on encoding. > > Hmm... The dummy container should never appear in an URI, right? And as for > message body parsing, > it is just a simple matter of adding (or removing) the extra container > after the payload has been parsed. > > True -- it is just message body processing. JSON and XML are consistent except XML does not allow top-level arrays. It is not just parsing. The conceptual model requires a single instance of a top-level element. I actually like the "parent node" solution better than returning different structures for JSON and XML. > > > There are also operations/query parameters that only apply > > to collections. Returning the same node sometimes as > > a data resource and other times as a collection resource > > would be confusing. > > The data model says whether it is a collection or not. > > Only partly. Retrieving a collection is a protocol operation. list foo { key bar; leaf bar { type string; } container foo { leaf bar { type int32; } } } GET /restconf/data/foo?select=bar;foo/bar What is returned? { "foo" : [ { "bar": [ "fred", 42 ] }, { "bar": [ "barney", 64 ] } ] } What happens when 2 different "bar" nodes are combined? They have the same module name and same local name. Lada > > Andy > > > > > > Lada > > > > > > > > Andy > > > > > > > > > > The current proposal is to create a new "YANG collection" resource > > > and return a top-level element if a list or leaf-list is the > > > target resource. A wrapper for JSON will be used so the data > > > matches the resource type (application/yang.collection has N child > nodes > > > that > > > are type application/yang.data). > > > > > > > > > > > > > > > > > > > > >> Thanks, > > >> > > >> Alberto > > >> > > > > > > > > > Andy > > > > > > > > >> > > >> > > >>> > > >>> Considering XML encoding now. > > >>> > > >>> > > >>> The XML equivalent of the example above could be something like: > > >>> > > >>> > > >>> > > >>> > > >>> Wasting Light > > >>> example-jukebox:alternative > > >>> 2011 > > >>> > > >>> > > >>> > > >>> Now, if there were more than one album, to have in the response a > legal XML doc (a single root), I understand we would need to include > album's parent. > > >>> > > >>> Something like: > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> (...) > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> (...) > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Is this the case? > > >>> > > >>> If so, would it make sense encoding all lists (regardless the number > of entries in it) using the same structure? > > >>> > > >>> That is, rendering the example above as: > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> (...) > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Thanks, > > >>> > > >>> Alberto > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Netconf mailing list > > >>> Netconf@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netconf > > >>> > > >>> > > >> > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c252c69a666b04f9eddd71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 21, 2014 at 9:11 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 21 May 2014, at 17:01, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Wed, May 21, 2014 at 4:43 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.com> writes:
>
> > On Tue, May 20, 2014 at 1:40 PM, Alberto Gonzalez Prieto (albertg= o) <
> > albertgo@= cisco.com> wrote:
> >
> >>  Thanks Andy,
> >>
> >>  I appreciate the prompt response.
> >>
> >>  Can you comment on the XML encoding?
> >>
> >>
> > It is currently an open issue for the next draft.
> > How should collections be handled?
> >
> > If the target resource is a list, then a wrapper element
> > is needed in XML to return a valid XML instance document,
> > The element <data> or <collection> is being considere= d
> > for this purpose.
> >
> > A side issue is whether the JSON encoding should also
> > have this wrapper, so client applications can use the
> > same code for both encodings, or should a JSON array should
> > be returned instead, without the wrapper (just the target resourc= e list)?
>
> In my view, this shouldn't be needed in JSON because it means unne= cessary clutter there. Clients and servers should be able handle such diffe= rences in XML/JSON data encoding quite easily.
>
>
> If there was a wrapper in JSON then the exact same client code
> path expressions will work in both.  It is a hassle to alter the = schema
> for URI or message body parsing, based on encoding.

Hmm… The dummy container should never appear in an URI, right? And a= s for message body parsing,
it is just a simple matter of adding (or removing) the extra container afte= r the payload has been parsed.


True -- it is just message body proces= sing.
JSON and XML are consistent except XML
does not a= llow top-level arrays.

It is not just parsing. The= conceptual model requires a single
instance of a top-level element.

I actually l= ike the "parent node" solution better than returning
di= fferent structures for JSON and XML.

>
> There are also operations/query parameters that only apply
> to collections.  Returning the same node sometimes as
> a data resource and other times as a collection resource
> would be confusing.

The data model says whether it is a collection or not.


Only partly. Retrieving a collection i= s a protocol operation.


  &nbs= p;  list foo {
         key bar;
         leaf bar { type string; }
         container foo {
  &nb= sp;         leaf bar { type int32; }
  &= nbsp;      }
     }

<= /div>

  GET /restconf/data/foo?select=3Dbar;foo/bar=

What is returned?


  { &qu= ot;foo" : [
     { "bar": [ "f= red", 42 ] },
     { "bar": [ "= ;barney", 64 ] }
    ]
  }

What happens wh= en 2 different "bar" nodes are combined?
They have the = same module name and same local name.



Lada


Andy
 
>
>
> Lada
>
>
>
> Andy
>
>
> >
> > The current proposal is to create a new "YANG collection&quo= t; resource
> > and return a top-level <data> element if a list or leaf-lis= t is the
> > target resource.  A wrapper for JSON will be used so the dat= a
> > matches the resource type (application/yang.collection has N chil= d nodes
> > that
> > are type application/yang.data).
> >
> >
> >
> >
> >
> >
> >>  Thanks,
> >>
> >>  Alberto
> >>
> >
> >
> > Andy
> >
> >
> >>
> >>
> >>>
> >>> Considering XML encoding now.
> >>>
> >>>
> >>> The XML equivalent of the example above could be somethin= g like:
> >>>
> >>>
> >>>       <album xmlns=3D"http://example.com/= ns/example-jukebox">
> >>>
> >>>          <name>Wasting Lig= ht</name>
> >>>          <genre>example-ju= kebox:alternative</genre>
> >>>          <year>2011</ye= ar>
> >>>       </album>
> >>>
> >>>
> >>> Now, if there were more than one album, to have in the re= sponse a legal XML doc (a single root), I understand we would need to inclu= de album's parent.
> >>>
> >>> Something like:
> >>>
> >>>
> >>> <artist>
> >>>
> >>>     <album>
> >>>
> >>>         (...)
> >>>
> >>>     </album>
> >>>
> >>>     <album>
> >>>
> >>>         (...)
> >>>
> >>>     </album>
> >>>
> >>> </artist>
> >>>
> >>>
> >>> Is this the case?
> >>>
> >>> If so, would it make sense encoding all lists (regardless= the number of entries in it) using the same structure?
> >>>
> >>> That is, rendering the example above as:
> >>>
> >>>  <artist>
> >>>
> >>>     <album>
> >>>
> >>>         (...)
> >>>
> >>>     </album>
> >>>
> >>> </artist>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Alberto
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> Net= conf@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >>>
> >>>
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

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





--001a11c252c69a666b04f9eddd71-- From nobody Thu May 22 09:35:12 2014 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 80AC01A021A for ; Thu, 22 May 2014 09:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 8zV0CpwWZMgP for ; Thu, 22 May 2014 09:35:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAD21A0217 for ; Thu, 22 May 2014 09:35:03 -0700 (PDT) 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.0.944.11; Thu, 22 May 2014 16:35:01 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.51]) with mapi id 15.00.0944.000; Thu, 22 May 2014 16:35:01 +0000 From: Kent Watsen To: Andy Bierman , Ladislav Lhotka Thread-Topic: [Netconf] Restconf: rendering lists Thread-Index: AQHPdF6zlp+r3AnC40i47zqKoVK6S5tJ3jqAgAAQbQCAAAd+gIAA9MyAgAA3dwCAABOVgIAAND+AgAEhfoA= Date: Thu, 22 May 2014 16:35:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.11] x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(199002)(189002)(74502001)(74662001)(66066001)(80022001)(92566001)(31966008)(4396001)(16236675002)(86362001)(50986999)(92726001)(64706001)(85852003)(87936001)(101416001)(99286001)(81542001)(36756003)(21056001)(99396002)(77982001)(83322001)(83506001)(81342001)(76482001)(54356999)(20776003)(76176999)(2656002)(83072002)(46102001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: multipart/alternative; boundary="_000_CFA39CD57286Ekwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/LKDJxM6Dm8CjcVJfPB-lury7T3A Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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, 22 May 2014 16:35:10 -0000 --_000_CFA39CD57286Ekwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > > A side issue is whether the JSON encoding should also > > have this wrapper, so client applications can use the > > same code for both encodings, or should a JSON array should > > be returned instead, without the wrapper (just the target resource list= )? > > In my view, this shouldn't be needed in JSON because it means unnecessary= clutter there. Clients and servers should be able handle such differences = in XML/JSON data encoding quite easily. > > I actually like the "parent node" solution better than returning different structures for JSON and XML. [KENT] From the client's perspective, I think it's OK to return two differe= nt structures, because I don't expect a given client to flip between XML an= d JSON within some block of code. On the server side, sending two differen= t structures may or may not be trivial, depending if the json/xml encoders= are separate or if its a single encoder with a parameter passed into it. = What's easier for the RESTCONF server? --_000_CFA39CD57286Ekwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <4F442E281B29CF459F59980CD318652A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

> > A side issue is whether the JSON encoding should also
> > have this wrapper, so client applications can use the
> > same code for both encodings, or should a JSON array should
> > be returned instead, without the wrapper (just the target resourc= e list)?
>
> In my view, this shouldn't be needed in JSON because it means unnecess= ary clutter there. Clients and servers should be able handle such differenc= es in XML/JSON data encoding quite easily.
>
>

I actually like the "parent node" solution better than retur= ning
different structures for JSON and XML.

[KENT] From the client's perspective, I think it's OK to return two di= fferent structures, because I don't expect a given client to flip between X= ML and JSON within some block of code.  On the server side, sending tw= o different structures  may or may not be trivial, depending if the json/xml encoders are separate or if its a si= ngle encoder with a parameter passed into it.   What's easier for the = RESTCONF server?


 --_000_CFA39CD57286Ekwatsenjunipernet_-- From nobody Thu May 22 10:08:56 2014 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 C40661A026A for ; Thu, 22 May 2014 10:08:52 -0700 (PDT) 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 X1B466yJW6up for ; Thu, 22 May 2014 10:08:50 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7E01A0252 for ; Thu, 22 May 2014 10:08:50 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so6176454qcv.38 for ; Thu, 22 May 2014 10:08:48 -0700 (PDT) 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=tpoTxwSakR+LxY655nkESq5w9iFAVuid28Xg441fiM0=; b=HFa5s4nEoWzho/uyUxSE8JzD+NlLP2hAHJO5hyyEmuL3vTmcawzQc0Lc0GRO/tNFDC NcwE5wxhQnGLe8md+WCx07xevAirDx5Ru+kbDaAvrIDMnGdF/DQQl9BwGTjHlyk9sJGI TtJQv2ufM+yLMBeoLEzY82WpevtNXEeBVNgiVrcpenURpmeqqF6FdchniE8QWxtNGH6S /RalL3AyLsbHeo3TEu9sZgCfF8eUO1++zTYWDbq0UHkHt7U8ovhvcBXNZjKwYvxzji39 as8O698efdkSL/baHUOCYM+A99WEqubLdkUx4Mtfsajd3BOjXyxFdXis9c87ROqNDf+S CymQ== X-Gm-Message-State: ALoCoQkSHPsBLujuUKwqXMDUSbcaEerPMJy0FPvHY0qgKFPrxBt6BpKzm9/THrvr6Qww3ymegPI1 MIME-Version: 1.0 X-Received: by 10.224.125.74 with SMTP id x10mr16154051qar.99.1400778528838; Thu, 22 May 2014 10:08:48 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Thu, 22 May 2014 10:08:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 10:08:48 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c308869ef4c004fa002a72 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/39y9Jc6rDdu4J7ZtGPIxOb7dTq0 Cc: Netconf Subject: Re: [Netconf] Restconf: rendering lists 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, 22 May 2014 17:08:52 -0000 --001a11c308869ef4c004fa002a72 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 22, 2014 at 9:35 AM, Kent Watsen wrote: > >> > > A side issue is whether the JSON encoding should also >> > > have this wrapper, so client applications can use the >> > > same code for both encodings, or should a JSON array should >> > > be returned instead, without the wrapper (just the target resource >> list)? >> > >> > In my view, this shouldn't be needed in JSON because it means >> unnecessary clutter there. Clients and servers should be able handle such >> differences in XML/JSON data encoding quite easily. >> > >> > >> > > I actually like the "parent node" solution better than returning > different structures for JSON and XML. > > [KENT] From the client's perspective, I think it's OK to return two > different structures, because I don't expect a given client to flip between > XML and JSON within some block of code. On the server side, sending two > different structures may or may not be trivial, depending if the json/xml > encoders are separate or if its a single encoder with a parameter passed > into it. What's easier for the RESTCONF server? > > > The server knows which format it is going to send so always using a wrapper for XML and never using it for JSON is trivial. Streaming is not trivial. I cannot over-state how much easier it is to stream XML than JSON. By streaming, I do not just mean that the data is transmitted on the fly, and not rendered from a static representation in memory. That is hard enough in JSON. On real servers, the instrumentation can be distributed. The filtering implementation can be complicated. The access control can be implemented inline. All of which make it impossible to know when the headers are generated whether any data will actually be returned for a given or GET. For NETCONF, the wrapper is always sent, and there is no problem for . But in RESTCONF, the server needs to generate the status code header line before possibly knowing if there will be any data to return, so it cannot always send 204 No Content instead of 200 OK. That's why we always return a wrapper object (in XML or JSON) if the query can possibly match some data. The client must be prepared to get back an empty element or in JSON: { "data" : null }. A message body has to be sent and it is critical in XML to return a valid instance document if the search matches multiple nodes. Andy --001a11c308869ef4c004fa002a72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 22, 2014 at 9:35 AM, Kent Watsen <= kwatsen@juniper.ne= t> wrote:

> > A side issue is whether the JSON encoding should also
> > have this wrapper, so client applications can use the
> > same code for both encodings, or should a JSON array should
> > be returned instead, without the wrapper (just the target resourc= e list)?
>
> In my view, this shouldn't be needed in JSON because it means unne= cessary clutter there. Clients and servers should be able handle such diffe= rences in XML/JSON data encoding quite easily.
>
>

I actually like the "parent node" solution better than retur= ning
different structures for JSON and XML.

[KENT] From the client's perspective, I think it's OK to retur= n two different structures, because I don't expect a given client to fl= ip between XML and JSON within some block of code. =A0On the server side, s= ending two different structures =A0may or may not be trivial, depending if the json/xml encoders are separate or if its a si= ngle encoder with a parameter passed into it. =A0 What's easier for the= RESTCONF server?



<= div>
The server knows which format it is going to send so alw= ays
using a wrapper for XML and never using it for JSON is trivia= l.

Streaming is not trivial. =A0I cannot over-state how mu= ch easier it
is to stream XML than JSON. =A0By streaming, I do no= t just mean
that the data is transmitted on the fly, and not rend= ered from
a static representation in memory. =A0That is hard enough in JSON.

On real servers, the instrumentation can be distribut= ed.
The filtering implementation can be complicated. =A0The acces= s control
can be implemented inline. =A0All of which make it impossible to
=
know when the headers are generated whether any data will actually
be returned for a given <get> or GET.

For NETCONF, the <data> wrapper is always sent, and there
i= s no problem for <get>. =A0But in RESTCONF, the server needs
to generate the status code header line before possibly knowing if
there will be any data to return, so it cannot always send 204 No Cont= ent
instead of 200 OK.

That's why we= always return a <data> wrapper object (in XML or JSON)
if the query can possibly match some data.
The client must be pre= pared to get back an empty <data/> element
or in JSON: =A0{= "data" : null }. =A0A message body has to be sent and it
is critical in XML to return a valid instance document if the search
<= div>matches multiple nodes.
=A0

Andy

--001a11c308869ef4c004fa002a72-- From nobody Thu May 22 21:02:39 2014 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 754091A0087 for ; Thu, 22 May 2014 21:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 BJ3dcJbut-Tb for ; Thu, 22 May 2014 21:02:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AA751A0084 for ; Thu, 22 May 2014 21:02:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEL27240; Fri, 23 May 2014 04:02:28 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 May 2014 05:02:12 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 May 2014 05:02:26 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 23 May 2014 12:02:16 +0800 From: "Liubing (Leo)" To: Netconf Thread-Topic: Netconf running state indication-//RE: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) Thread-Index: AQHPayputtSOgj4VdkiXgRxlAPzJHps3nddwgABbRC7//7urgIAAYAWAgAAKXACAAY/xsf//wEQAgBQdlYA= Date: Fri, 23 May 2014 04:02:16 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B359C@nkgeml506-mbx.china.huawei.com> References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B359Cnkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/DRV9QpT8SF16f959cR8qN8cCyGA Cc: Zhengguangying , Yangang Subject: [Netconf] Netconf running state indication-//RE: Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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 May 2014 04:02:36 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B359Cnkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This mail is regarding to the keep-alive discussion recently. Following the discussion, I noticed there might be two different things tha= t I mixed them together. Let me try to distinguish them as the following. 1) To keep an idle session alive, so that a persistent connection coul= d be retained. This should be the common understanding of keep-alive. In th= is case, basically I agree with what Andy said in the below mail, that re-u= sing SSH keep-alive might be sufficient for Netconf. 2) To make an active session indicating the Netconf running state inst= antly. For example, as the case I described in the previous mail, the NMS r= equests a search operation which might cost the router a long time to proce= ss or even make the router suspend. Then it would be good for the NMS to le= arn the state of the router through a periodic message. In the simplest cas= e, the state is just about whether the router is still alive on the operati= on. The second one is just the actual topic I intended to discuss. I called suc= h message as "keep-alive", which might not be very proper. Right or wrong, = the point is about the running state indication, just similar as the real-t= ime feedbacks in CLI when the operation time is long. If there is such a message mechanism, the Netconf server could indicate the= client something like: - it is still processing the operation ("keep-alive") - the rate of progress - some key processing information - ...etc. Do you think it is good to have such a feature in Netconf? Regards, Bing From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Saturday, May 10, 2014 11:39 PM To: t.petch Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartb= eats, reconnection, timeout) ... SSH has its own keep-alive. NETCONF uses that. In implementation, the NETCONF layer has access to an SSH channel, not directly to a TCP socket. If the TCP connection is lost, then NETCONF relies on the SSH session and channels getting closed. If SSH cannot detect the loss of TCP, then how would NETCONF be able to do so? The SSH keep-alives are essentially the same thing as if NETCONF used the channel periodically to send a keep-alive message, so why bother replicating that functionality at the application layer? --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B359Cnkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 = ;

This mail = is regarding to the keep-alive discussion recently.

Following = the discussion, I noticed there might be two different things that I mixed = them together. Let me try to distinguish them as the following.<= /span>

 = ;

1)      To= keep an idle session alive, so that a persistent connection could be retai= ned. This should be the common understanding of keep-alive. In this case, basically I agree with what Andy said in the below mail, tha= t re-using SSH keep-alive might be sufficient for Netconf.

2)      To= make an active session indicating the Netconf running state instantly. For= example, as the case I described in the previous mail, the NMS requests a search operation which might cost the router a long tim= e to process or even make the router suspend. Then it would be good for the= NMS to learn the state of the router through a periodic message. In the si= mplest case, the state is just about whether the router is still alive on the operation.

 = ;

The second= one is just the actual topic I intended to discuss. I called such message = as “keep-alive”, which might not be very proper. Right or wrong, the point is about the running state indication, just similar as th= e real-time feedbacks in CLI when the operation time is long.  

If there i= s such a message mechanism, the Netconf server could indicate the client so= mething like:

-it= is still processing the operation (“keep-alive”)

-th= e rate of progress

-so= me key processing information

-..= .etc.

 = ;

Do you thi= nk it is good to have such a feature in Netconf?

 = ;

 = ;

Regards,

Bing<= /o:p>

 = ;

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Saturday, May 10, 2014 11:39 PM
To: t.petch
Cc: Netconf
Subject: Re: [Netconf] Netconf keep-alive (was periodic connections,= heartbeats, reconnection, timeout)

...

SSH has its own keep-alive. NET= CONF uses that.

In implementation, the NETCONF = layer has access to

an SSH channel, not directly to= a TCP socket.  If the

TCP connection is lost, then NE= TCONF relies on the SSH session

and channels getting closed. &n= bsp;If SSH cannot detect the loss of TCP,

then how would NETCONF be able = to do so? 

 

The SSH keep-alives are essenti= ally the same thing as if NETCONF

used the channel periodically t= o send a keep-alive message, so why

bother replicating that functio= nality at the application layer?

 

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B359Cnkgeml506mbxchi_-- From nobody Fri May 23 02:57:35 2014 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 783BC1A03DA for ; Fri, 23 May 2014 02:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwiDNeCcHT0P for ; Fri, 23 May 2014 02:57:32 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0011.outbound.protection.outlook.com [213.199.154.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F4A1A015F for ; Fri, 23 May 2014 02:57:31 -0700 (PDT) Received: from DB3PRD0210HT005.eurprd02.prod.outlook.com (157.56.253.69) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 23 May 2014 09:57:27 +0000 Message-ID: <012401cf766d$0866c760$4001a8c0@gateway.2wire.net> From: t.petch To: "Liubing (Leo)" , Netconf References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B359C@nkgeml506-mbx.china.huawei.com> Date: Fri, 23 May 2014 10:52:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.69] X-ClientProxiedBy: AM3PR07CA010.eurprd07.prod.outlook.com (10.242.16.50) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) X-Forefront-PRVS: 0220D4B98D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(377454003)(25584003)(199002)(189002)(13464003)(77982001)(101416001)(44736004)(85852003)(50226001)(66066001)(84392001)(102836001)(81342001)(47776003)(20776003)(61296002)(81542001)(64706001)(23756003)(33646001)(76482001)(92726001)(89996001)(92566001)(83072002)(4396001)(74662001)(74502001)(50466002)(21056001)(14496001)(87976001)(77156001)(87286001)(31966008)(88136002)(81686999)(80022001)(93916002)(86362001)(81816999)(99396002)(79102001)(42186004)(44716002)(46102001)(19580405001)(19580395003)(83322001)(62966002)(50986999)(62236002)(76176999)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR07MB064; H:DB3PRD0210HT005.eurprd02.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XzoABEwhIHw4OO6h30pxnVWYzQs Cc: Zhengguangying , Yangang Subject: Re: [Netconf] Netconf running state indication-//RE: Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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 May 2014 09:57:34 -0000 ---- Original Message ----- From: "Liubing (Leo)" To: "Netconf" Cc: "Andy Bierman" ; "t.petch" ; "Yangang" ; "Zhengguangying" Sent: Friday, May 23, 2014 5:02 AM This mail is regarding to the keep-alive discussion recently. Following the discussion, I noticed there might be two different things that I mixed them together. Let me try to distinguish them as the following. 1) To keep an idle session alive, so that a persistent connection could be retained. This should be the common understanding of keep-alive. In this case, basically I agree with what Andy said in the below mail, that re-using SSH keep-alive might be sufficient for Netconf. 2) To make an active session indicating the Netconf running state instantly. For example, as the case I described in the previous mail, the NMS requests a search operation which might cost the router a long time to process or even make the router suspend. Then it would be good for the NMS to learn the state of the router through a periodic message. In the simplest case, the state is just about whether the router is still alive on the operation. The second one is just the actual topic I intended to discuss. I called such message as "keep-alive", which might not be very proper. Right or wrong, the point is about the running state indication, just similar as the real-time feedbacks in CLI when the operation time is long. If there is such a message mechanism, the Netconf server could indicate the client something like: - it is still processing the operation ("keep-alive") - the rate of progress - some key processing information - ...etc. Do you think it is good to have such a feature in Netconf? No:-( I think that such progress reports are lovely in theory but practically meaningless; they are just too hard to implement reliably. I see them for file downloads and similar operations where the estimated time to completion goes up and down like a yoyo, or an e-mail download yesterday, from an (antisocial:-) participant on an IETF list who posted a megagbyte of mostly nothingness and I got a progress report up to the point where it alleged that about half the e-mail had been downloaded and then - the download report vanished. Had the download succeeded, had it been terminated by the server (a common occurrence) or what? I am still wondering. I see the underlying issue that any long running task is going to be a background task, running as and when, so forecasts of how long it will take are forecasts of what higher priority task will preempt it, and that is unpredictable, so the forecasts are bad. Is a bad forecast better than no forecast? Judging by the questions and comments from my non-technical friends and colleagues, I say no forecast. So a keepalive to say that the link is up is good news, because it tends to be small and reliable and a reliable indicator. If the keepalive comes from the application layer, then that is better because it is reporting more of the stack's liveliness, but if the keepalive is tied into a background task in any way, then no, it defeats the concept of a keepalive and becomes as meaningless as my file download progress reports. Tom Petch Regards, Bing From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Saturday, May 10, 2014 11:39 PM To: t.petch Cc: Netconf Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) ... SSH has its own keep-alive. NETCONF uses that. In implementation, the NETCONF layer has access to an SSH channel, not directly to a TCP socket. If the TCP connection is lost, then NETCONF relies on the SSH session and channels getting closed. If SSH cannot detect the loss of TCP, then how would NETCONF be able to do so? The SSH keep-alives are essentially the same thing as if NETCONF used the channel periodically to send a keep-alive message, so why bother replicating that functionality at the application layer? From nobody Fri May 23 03:26:21 2014 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 D2DDF1A0167 for ; Fri, 23 May 2014 03:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ARw5BNx4L3CG for ; Fri, 23 May 2014 03:26:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5AF61A03E5 for ; Fri, 23 May 2014 03:26:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEL58110; Fri, 23 May 2014 10:26:14 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 May 2014 11:25:59 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 May 2014 11:26:13 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 23 May 2014 18:26:03 +0800 From: "Liubing (Leo)" To: "t.petch" , Netconf Thread-Topic: Netconf running state indication-//RE: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) Thread-Index: AQHPayputtSOgj4VdkiXgRxlAPzJHps3nddwgABbRC7//7urgIAAYAWAgAAKXACAAY/xsf//wEQAgBQdlYCAAHeruIAAAcZA Date: Fri, 23 May 2014 10:26:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B3695@nkgeml506-mbx.china.huawei.com> References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B359C@nkgeml506-mbx.china.huawei.com> <012401cf766d$0866c760$4001a8c0@gateway.2wire.net> In-Reply-To: <012401cf766d$0866c760$4001a8c0@gateway.2wire.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6uHL-P5Y0ldIw3NN29_WZADuscU Cc: Zhengguangying , Yangang Subject: Re: [Netconf] Netconf running state indication-//RE: Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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 May 2014 10:26:20 -0000 Hi Tom, Thanks for your comments. The cases listed below are just some rough divergent thinking. Our basic id= ea is just to inform the Netconf client that the processing is going on, pl= ease wait. And if there's no indication messages, the client could judge th= e server are down or suspend.=20 However, if we have such a messaging mechanism, then we could indicate more= things than just Netconf-level keep-alive. But the "more things" might nee= d further discussion. May I ask are you opposing the whole idea of running state indication, or j= ust the specific "progress of rate" use case? Regards, Bing > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Friday, May 23, 2014 5:53 PM > To: Liubing (Leo); Netconf > Cc: Andy Bierman; Yangang; Zhengguangying > Subject: Re: Netconf running state indication-//RE: [Netconf] Netconf > keep-alive (was periodic connections, heartbeats, reconnection, timeout) >=20 > ---- Original Message ----- > From: "Liubing (Leo)" > To: "Netconf" > Cc: "Andy Bierman" ; "t.petch" > ; "Yangang" ; > "Zhengguangying" > > Sent: Friday, May 23, 2014 5:02 AM >=20 > This mail is regarding to the keep-alive discussion recently. > Following the discussion, I noticed there might be two different things t= hat I > mixed them together. Let me try to distinguish them as the following. >=20 > 1) To keep an idle session alive, so that a persistent connection > could be retained. This should be the common understanding of keep-alive. > In this case, basically I agree with what Andy said in the below mail, th= at > re-using SSH keep-alive might be sufficient for Netconf. >=20 > 2) To make an active session indicating the Netconf running state > instantly. For example, as the case I described in the previous mail, the= NMS > requests a search operation which might cost the router a long time to > process or even make the router suspend. Then it would be good for the > NMS to learn the state of the router through a periodic message. > In the simplest case, the state is just about whether the router is still= alive on > the operation. >=20 > The second one is just the actual topic I intended to discuss. I called s= uch > message as "keep-alive", which might not be very proper. Right or wrong, > the point is about the running state indication, just similar as the real= -time > feedbacks in CLI when the operation time is long. > If there is such a message mechanism, the Netconf server could indicate t= he > client something like: >=20 > - it is still processing the operation ("keep-alive") >=20 > - the rate of progress >=20 > - some key processing information >=20 > - ...etc. >=20 > Do you think it is good to have such a feature in Netconf? >=20 > > No:-( I think that such progress reports are lovely in theory but practi= cally > meaningless; they are just too hard to implement reliably. > I see them for file downloads and similar operations where the estimated > time to completion goes up and down like a yoyo, or an e-mail download > yesterday, from an (antisocial:-) participant on an IETF list who posted = a > megagbyte of mostly nothingness and I got a progress report up to the > point where it alleged that about half the e-mail had been downloaded and > then - the download report vanished. Had the download succeeded, had it > been terminated by the server (a common occurrence) or what? I am still > wondering. >=20 > I see the underlying issue that any long running task is going to be a > background task, running as and when, so forecasts of how long it will ta= ke > are forecasts of what higher priority task will preempt it, and that is > unpredictable, so the forecasts are bad. Is a bad forecast better than n= o > forecast? Judging by the questions and comments from my non-technical > friends and colleagues, I say no forecast. >=20 > So a keepalive to say that the link is up is good news, because it tends = to be > small and reliable and a reliable indicator. If the keepalive comes from= the > application layer, then that is better because it is reporting more of th= e > stack's liveliness, but if the keepalive is tied into a background task i= n any > way, then no, it defeats the concept of a keepalive and becomes as > meaningless as my file download progress reports. >=20 > Tom Petch >=20 >=20 >=20 >=20 >=20 > Regards, > Bing >=20 > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy > Bierman > Sent: Saturday, May 10, 2014 11:39 PM > To: t.petch > Cc: Netconf > Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, > heartbeats, reconnection, timeout) ... > SSH has its own keep-alive. NETCONF uses that. > In implementation, the NETCONF layer has access to an SSH channel, not > directly to a TCP socket. If the TCP connection is lost, then NETCONF re= lies > on the SSH session and channels getting closed. If SSH cannot detect the > loss of TCP, then how would NETCONF be able to do so? >=20 > The SSH keep-alives are essentially the same thing as if NETCONF used the > channel periodically to send a keep-alive message, so why bother replicat= ing > that functionality at the application layer? >=20 >=20 From nobody Fri May 23 07:28:28 2014 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 7B5921A05D3 for ; Fri, 23 May 2014 07:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPgw3cMZTcRo for ; Fri, 23 May 2014 07:28:08 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8131A05C0 for ; Fri, 23 May 2014 07:27:51 -0700 (PDT) Received: from DBXPRD0610HT003.eurprd06.prod.outlook.com (157.56.252.181) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 23 May 2014 14:27:48 +0000 Message-ID: <005701cf7692$cc8f9b60$4001a8c0@gateway.2wire.net> From: t.petch To: "Liubing (Leo)" , Netconf References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B359C@nkgeml506-mbx.china.huawei.com> <012401cf766d$0866c760$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B3695@nkgeml506-mbx.china.huawei.com> Date: Fri, 23 May 2014 15:25:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DBXPR07CA007.eurprd07.prod.outlook.com (10.255.191.165) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Forefront-PRVS: 0220D4B98D X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(25584003)(13464003)(377454003)(51444003)(51704005)(189002)(199002)(83072002)(74502001)(44716002)(89996001)(74662001)(85852003)(87976001)(31966008)(88136002)(44736004)(62236002)(79102001)(80022001)(20776003)(66066001)(64706001)(4396001)(77156001)(102836001)(101416001)(92566001)(19580405001)(87286001)(92726001)(83322001)(19580395003)(84392001)(86362001)(93916002)(61296002)(62966002)(81542001)(14496001)(81342001)(50466002)(42186004)(46102001)(77982001)(76482001)(21056001)(33646001)(99396002)(23756003)(76176999)(47776003)(50986999)(81686999)(81816999)(50226001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR07MB061; H:DBXPRD0610HT003.eurprd06.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/JI2D1qdoYvQJN3ce-p3Da6FCvQc Cc: Zhengguangying , Yangang Subject: Re: [Netconf] Netconf running state indication-//RE: Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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 May 2014 14:28:16 -0000 ----- Original Message ----- From: "Liubing (Leo)" To: "t.petch" ; "Netconf" Cc: "Andy Bierman" ; "Yangang" ; "Zhengguangying" Sent: Friday, May 23, 2014 11:26 AM Subject: RE: Netconf running state indication-//RE: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) Hi Tom, Thanks for your comments. The cases listed below are just some rough divergent thinking. Our basic idea is just to inform the Netconf client that the processing is going on, please wait. And if there's no indication messages, the client could judge the server are down or suspend. However, if we have such a messaging mechanism, then we could indicate more things than just Netconf-level keep-alive. But the "more things" might need further discussion. May I ask are you opposing the whole idea of running state indication, or just the specific "progress of rate" use case? I am against progress indicators unless they can be accurate and I doubt that they can be accurate for long running (and hence background) tasks. I do like liveness indicators and notice how they have gone from nowhere to widespread in the time I have been involved with the IETF, so with almost any protocol, I ask 'where is the keepalive?'. And the higher up the stack it is the better, as long as it does not get tied into a low priority activity! So if you wanted to tell the client that this request had not been lost - I don't know how common an occurrence this is at this time - then how would you identify the request or requests - like an interim response, perhaps, a well-formed rpc reply with the right ID in it? but then how do you ensure that that does not get tied up with the outstanding request that may or may not still be running? You seem to be positing a server processing one request, whereas I think of servers doing many things, so that, at least with other protocols, I perform my own liveness check by asking something very simple - e.g. SNMP get sysUpTime - over a parallel session. Which my client might already be doing for me. There is a background philosophy which SNMP articulates, that you need this most when things are going badly, so make it such that it is most likely to succeed, ie Simple. Tom Petch Regards, Bing > -----Original Message----- > From: t.petch [mailto:ietfc@btconnect.com] > Sent: Friday, May 23, 2014 5:53 PM > To: Liubing (Leo); Netconf > Cc: Andy Bierman; Yangang; Zhengguangying > Subject: Re: Netconf running state indication-//RE: [Netconf] Netconf > keep-alive (was periodic connections, heartbeats, reconnection, timeout) > > ---- Original Message ----- > From: "Liubing (Leo)" > To: "Netconf" > Cc: "Andy Bierman" ; "t.petch" > ; "Yangang" ; > "Zhengguangying" > > Sent: Friday, May 23, 2014 5:02 AM > > This mail is regarding to the keep-alive discussion recently. > Following the discussion, I noticed there might be two different things that I > mixed them together. Let me try to distinguish them as the following. > > 1) To keep an idle session alive, so that a persistent connection > could be retained. This should be the common understanding of keep-alive. > In this case, basically I agree with what Andy said in the below mail, that > re-using SSH keep-alive might be sufficient for Netconf. > > 2) To make an active session indicating the Netconf running state > instantly. For example, as the case I described in the previous mail, the NMS > requests a search operation which might cost the router a long time to > process or even make the router suspend. Then it would be good for the > NMS to learn the state of the router through a periodic message. > In the simplest case, the state is just about whether the router is still alive on > the operation. > > The second one is just the actual topic I intended to discuss. I called such > message as "keep-alive", which might not be very proper. Right or wrong, > the point is about the running state indication, just similar as the real-time > feedbacks in CLI when the operation time is long. > If there is such a message mechanism, the Netconf server could indicate the > client something like: > > - it is still processing the operation ("keep-alive") > > - the rate of progress > > - some key processing information > > - ...etc. > > Do you think it is good to have such a feature in Netconf? > > > No:-( I think that such progress reports are lovely in theory but practically > meaningless; they are just too hard to implement reliably. > I see them for file downloads and similar operations where the estimated > time to completion goes up and down like a yoyo, or an e-mail download > yesterday, from an (antisocial:-) participant on an IETF list who posted a > megagbyte of mostly nothingness and I got a progress report up to the > point where it alleged that about half the e-mail had been downloaded and > then - the download report vanished. Had the download succeeded, had it > been terminated by the server (a common occurrence) or what? I am still > wondering. > > I see the underlying issue that any long running task is going to be a > background task, running as and when, so forecasts of how long it will take > are forecasts of what higher priority task will preempt it, and that is > unpredictable, so the forecasts are bad. Is a bad forecast better than no > forecast? Judging by the questions and comments from my non-technical > friends and colleagues, I say no forecast. > > So a keepalive to say that the link is up is good news, because it tends to be > small and reliable and a reliable indicator. If the keepalive comes from the > application layer, then that is better because it is reporting more of the > stack's liveliness, but if the keepalive is tied into a background task in any > way, then no, it defeats the concept of a keepalive and becomes as > meaningless as my file download progress reports. > > Tom Petch > > > > > > Regards, > Bing > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy > Bierman > Sent: Saturday, May 10, 2014 11:39 PM > To: t.petch > Cc: Netconf > Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, > heartbeats, reconnection, timeout) ... > SSH has its own keep-alive. NETCONF uses that. > In implementation, the NETCONF layer has access to an SSH channel, not > directly to a TCP socket. If the TCP connection is lost, then NETCONF relies > on the SSH session and channels getting closed. If SSH cannot detect the > loss of TCP, then how would NETCONF be able to do so? > > The SSH keep-alives are essentially the same thing as if NETCONF used the > channel periodically to send a keep-alive message, so why bother replicating > that functionality at the application layer? > > From nobody Mon May 26 01:24:08 2014 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 D3E551A0051 for ; Mon, 26 May 2014 01:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.498 X-Spam-Level: * X-Spam-Status: No, score=1.498 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] 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 QG23gjgzzMN8 for ; Mon, 26 May 2014 01:24:03 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFC41A004A for ; Mon, 26 May 2014 01:24:03 -0700 (PDT) Received: from krejci.liberouter.org (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 44F36ECF676; Mon, 26 May 2014 10:23:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1401092638; bh=FnIOZ9WzSdTPsr+9LQSCUDzrnqhiYHEkZF6MIhPdZag=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=uGHLDGas7bEY/Kdj4mz6uEavnm2soqncfZtljZ90wsN2vbPpa8ctUqvuC7vjW6LV+ vQwplU/GLXpeEizRnluaJXjL+vM53shxt6cA7v2Sa+dCwrcm9My7gRcV+uRlKrloU9 MuO4nDm8xGTR1zwEqq7oR0Uzo7mrf/BOeSEkDfz4= Message-ID: <5382F9ED.9060407@cesnet.cz> Date: Mon, 26 May 2014 10:23:09 +0200 From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Liubing (Leo)" , Netconf References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B359C@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B359C@nkgeml506-mbx.china.huawei.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------060303050107080209060904" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HI-FjqWKY1NVykKGh15zne_LfyE Cc: Zhengguangying , Yangang Subject: Re: [Netconf] Netconf running state indication-//RE: Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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 May 2014 08:24:06 -0000 This is a multi-part message in MIME format. --------------060303050107080209060904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, IMO the NETCONF Event Notifications mechanism can already work as keep-alive/heartbeat - what if a server has an event stream named keepalive or heartbeat (or whatever) and in this stream the server sends the keep-alive notification to the interested clients. keep-alive period can be configurable. Of course, there is no sense for replay feature in this event stream. I don't like operation keep alive (possibly with a progress info). Tom already stated some reasons. From my point of view, it needlessly complicates the keep-alive mechanism in NETCONF. I don't think that it is a good idea to send progress information or even operation processing info to _all_ clients - it should be received only by the client that invoked the operation. In that case we have different keep-alive messages sent to different clients. And, as I said, it needlessly complicates implementation. I think that (if we need NETCONF keep-alive) we just need it to say "NETCONF server is alive". I believe, that, as Kent stated, SSH keep-alives are good enough for saying "NETCONF session is alive" - just, please, Keep It Simple, Stupid. Regards, Radek Dne 23.5.2014 06:02, Liubing (Leo) napsal(a): > > Hi all, > > > > This mail is regarding to the keep-alive discussion recently. > > Following the discussion, I noticed there might be two different > things that I mixed them together. Let me try to distinguish them as > the following. > > > > 1) To keep an idle session alive, so that a persistent connection > could be retained. This should be the common understanding of > keep-alive. In this case, basically I agree with what Andy said in the > below mail, that re-using SSH keep-alive might be sufficient for Netconf. > > 2) To make an active session indicating the Netconf running state > instantly. For example, as the case I described in the previous mail, > the NMS requests a search operation which might cost the router a long > time to process or even make the router suspend. Then it would be good > for the NMS to learn the state of the router through a periodic > message. In the simplest case, the state is just about whether the > router is still alive on the operation. > > > > The second one is just the actual topic I intended to discuss. I > called such message as “keep-alive”, which might not be very proper. > Right or wrong, the point is about the running state indication, just > similar as the real-time feedbacks in CLI when the operation time is > long. > > If there is such a message mechanism, the Netconf server could > indicate the client something like: > > - it is still processing the operation (“keep-alive”) > > - the rate of progress > > - some key processing information > > - ...etc. > > > > Do you think it is good to have such a feature in Netconf? > > > > > > Regards, > > Bing > > > > *From:*Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Saturday, May 10, 2014 11:39 PM > *To:* t.petch > *Cc:* Netconf > *Subject:* Re: [Netconf] Netconf keep-alive (was periodic connections, > heartbeats, reconnection, timeout) > > ... > > SSH has its own keep-alive. NETCONF uses that. > > In implementation, the NETCONF layer has access to > > an SSH channel, not directly to a TCP socket. If the > > TCP connection is lost, then NETCONF relies on the SSH session > > and channels getting closed. If SSH cannot detect the loss of TCP, > > then how would NETCONF be able to do so? > > > > The SSH keep-alives are essentially the same thing as if NETCONF > > used the channel periodically to send a keep-alive message, so why > > bother replicating that functionality at the application layer? > > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Radek Krejci mobile: +420 732 212 714 office: +420 234 680 256 e-mail: rkrejci@cesnet.cz CESNET Association of Legal Entities 160 00 Praha 6, Zikova 4 Czech Republic --------------060303050107080209060904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,

IMO the NETCONF Event Notifications mechanism can already work as keep-alive/heartbeat - what if a server has an event stream named keepalive or heartbeat (or whatever) and in this stream the server sends the keep-alive notification to the interested clients. keep-alive period can be configurable. Of course, there is no sense for replay feature in this event stream.

I don't like operation keep alive (possibly with a progress info). Tom already stated some reasons. From my point of view, it needlessly complicates the keep-alive mechanism in NETCONF. I don't think that it is a good idea to send progress information or even operation processing info to _all_ clients - it should be received only by the client that invoked the operation. In that case we have different keep-alive messages sent to different clients. And, as I said, it needlessly complicates implementation.

I think that (if we need NETCONF keep-alive) we just need it to say "NETCONF server is alive". I believe, that, as Kent stated, SSH keep-alives are good enough for saying "NETCONF session is alive" - just, please, Keep It Simple, Stupid.

Regards,
Radek
Dne 23.5.2014 06:02, Liubing (Leo) napsal(a):

Hi all,

 

This mail is regarding to the keep-alive discussion recently.

Following the discussion, I noticed there might be two different things that I mixed them together. Let me try to distinguish them as the following.

 

1)      To keep an idle session alive, so that a persistent connection could be retained. This should be the common understanding of keep-alive. In this case, basically I agree with what Andy said in the below mail, that re-using SSH keep-alive might be sufficient for Netconf.

2)      To make an active session indicating the Netconf running state instantly. For example, as the case I described in the previous mail, the NMS requests a search operation which might cost the router a long time to process or even make the router suspend. Then it would be good for the NMS to learn the state of the router through a periodic message. In the simplest case, the state is just about whether the router is still alive on the operation.

 

The second one is just the actual topic I intended to discuss. I called such message as “keep-alive”, which might not be very proper. Right or wrong, the point is about the running state indication, just similar as the real-time feedbacks in CLI when the operation time is long.  

If there is such a message mechanism, the Netconf server could indicate the client something like:

-        it is still processing the operation (“keep-alive”)

-        the rate of progress

-        some key processing information

-        ...etc.

 

Do you think it is good to have such a feature in Netconf?

 

 

Regards,

Bing

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Saturday, May 10, 2014 11:39 PM
To: t.petch
Cc: Netconf
Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout)

...

SSH has its own keep-alive. NETCONF uses that.

In implementation, the NETCONF layer has access to

an SSH channel, not directly to a TCP socket.  If the

TCP connection is lost, then NETCONF relies on the SSH session

and channels getting closed.  If SSH cannot detect the loss of TCP,

then how would NETCONF be able to do so? 

 

The SSH keep-alives are essentially the same thing as if NETCONF

used the channel periodically to send a keep-alive message, so why

bother replicating that functionality at the application layer?

 

 



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


-- 
Radek Krejci
mobile: +420 732 212 714
office: +420 234 680 256
e-mail: rkrejci@cesnet.cz

CESNET
Association of Legal Entities
160 00 Praha 6, Zikova 4
Czech Republic
--------------060303050107080209060904-- From nobody Mon May 26 03:01:50 2014 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 3BA501A00AF for ; Mon, 26 May 2014 03:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 iCjPxl6-Pj-O for ; Mon, 26 May 2014 03:01:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2988A1A0092 for ; Mon, 26 May 2014 03:01:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEN64702; Mon, 26 May 2014 10:01:42 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 11:00:55 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 11:01:19 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 26 May 2014 18:01:08 +0800 From: "Liubing (Leo)" To: "t.petch" , Netconf Thread-Topic: Netconf running state indication-//RE: [Netconf] Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) Thread-Index: AQHPayputtSOgj4VdkiXgRxlAPzJHps3nddwgABbRC7//7urgIAAYAWAgAAKXACAAY/xsf//wEQAgBQdlYCAAHeruIAAAcZAgABJuHCABGF68A== Date: Mon, 26 May 2014 10:01:08 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6AE8@nkgeml506-mbx.china.huawei.com> References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B359C@nkgeml506-mbx.china.huawei.com> <012401cf766d$0866c760$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B3695@nkgeml506-mbx.china.huawei.com> <005701cf7692$cc8f9b60$4001a8c0@gateway.2wire.net> In-Reply-To: <005701cf7692$cc8f9b60$4001a8c0@gateway.2wire.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dZAy2m2rI-Ic86q27y0d_LJ0iFE Cc: Zhengguangying , Yangang Subject: Re: [Netconf] Netconf running state indication-//RE: Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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 May 2014 10:01:49 -0000 Hi Tom, > > I am against progress indicators unless they can be accurate and I doubt = that > they can be accurate for long running (and hence background) tasks. >=20 > I do like liveness indicators and notice how they have gone from nowhere = to > widespread in the time I have been involved with the IETF, so with almost > any protocol, I ask 'where is the keepalive?'. And the higher up the sta= ck it > is the better, as long as it does not get tied into a low priority activi= ty! >=20 > So if you wanted to tell the client that this request had not been lost -= I don't > know how common an occurrence this is at this time - then how would you > identify the request or requests - like an interim response, perhaps, a > well-formed rpc reply with the right ID in it? but then how do you ensur= e > that that does not get tied up with the outstanding request that may or m= ay > not still be running? [Bing] I haven't started the specific design, but the rough idea in my mind= is kind of , which is just in the band of the specific Netconf = session.=20 =20 > You seem to be positing a server processing one request, whereas I think = of > servers doing many things, so that, at least with other protocols, I perf= orm > my own liveness check by asking something very simple - e.g. > SNMP get sysUpTime - over a parallel session. Which my client might > already be doing for me. [Bing] I agree sometimes trick methods in implementation are simple and eff= ective. But after all these methods cannot be guaranteed to be available. A= standardize way would be much reliable. However, maybe it is a lit earlier to discuss the solution. It seems we hav= en't agreed on the requirement of such running state indication. We might n= eed more work on the use cases. =20 Regards, Bing >=20 > There is a background philosophy which SNMP articulates, that you need th= is > most when things are going badly, so make it such that it is most likely = to > succeed, ie Simple. >=20 > Tom Petch >=20 > Regards, > Bing >=20 > > -----Original Message----- > > From: t.petch [mailto:ietfc@btconnect.com] > > Sent: Friday, May 23, 2014 5:53 PM > > To: Liubing (Leo); Netconf > > Cc: Andy Bierman; Yangang; Zhengguangying > > Subject: Re: Netconf running state indication-//RE: [Netconf] Netconf > > keep-alive (was periodic connections, heartbeats, reconnection, > timeout) > > > > ---- Original Message ----- > > From: "Liubing (Leo)" > > To: "Netconf" > > Cc: "Andy Bierman" ; "t.petch" > > ; "Yangang" ; > > "Zhengguangying" > > > > Sent: Friday, May 23, 2014 5:02 AM > > > > This mail is regarding to the keep-alive discussion recently. > > Following the discussion, I noticed there might be two different > things that I > > mixed them together. Let me try to distinguish them as the following. > > > > 1) To keep an idle session alive, so that a persistent connection > > could be retained. This should be the common understanding of > keep-alive. > > In this case, basically I agree with what Andy said in the below mail, > that > > re-using SSH keep-alive might be sufficient for Netconf. > > > > 2) To make an active session indicating the Netconf running state > > instantly. For example, as the case I described in the previous mail, > the NMS > > requests a search operation which might cost the router a long time to > > process or even make the router suspend. Then it would be good for the > > NMS to learn the state of the router through a periodic message. > > In the simplest case, the state is just about whether the router is > still alive on > > the operation. > > > > The second one is just the actual topic I intended to discuss. I > called such > > message as "keep-alive", which might not be very proper. Right or > wrong, > > the point is about the running state indication, just similar as the > real-time > > feedbacks in CLI when the operation time is long. > > If there is such a message mechanism, the Netconf server could > indicate the > > client something like: > > > > - it is still processing the operation ("keep-alive") > > > > - the rate of progress > > > > - some key processing information > > > > - ...etc. > > > > Do you think it is good to have such a feature in Netconf? > > > > > > No:-( I think that such progress reports are lovely in theory but > practically > > meaningless; they are just too hard to implement reliably. > > I see them for file downloads and similar operations where the > estimated > > time to completion goes up and down like a yoyo, or an e-mail download > > yesterday, from an (antisocial:-) participant on an IETF list who > posted a > > megagbyte of mostly nothingness and I got a progress report up to > the > > point where it alleged that about half the e-mail had been downloaded > and > > then - the download report vanished. Had the download succeeded, had > it > > been terminated by the server (a common occurrence) or what? I am > still > > wondering. > > > > I see the underlying issue that any long running task is going to be a > > background task, running as and when, so forecasts of how long it will > take > > are forecasts of what higher priority task will preempt it, and that > is > > unpredictable, so the forecasts are bad. Is a bad forecast better > than no > > forecast? Judging by the questions and comments from my non-technical > > friends and colleagues, I say no forecast. > > > > So a keepalive to say that the link is up is good news, because it > tends to be > > small and reliable and a reliable indicator. If the keepalive comes > from the > > application layer, then that is better because it is reporting more of > the > > stack's liveliness, but if the keepalive is tied into a background > task in any > > way, then no, it defeats the concept of a keepalive and becomes as > > meaningless as my file download progress reports. > > > > Tom Petch > > > > > > > > > > > > Regards, > > Bing > > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy > > Bierman > > Sent: Saturday, May 10, 2014 11:39 PM > > To: t.petch > > Cc: Netconf > > Subject: Re: [Netconf] Netconf keep-alive (was periodic connections, > > heartbeats, reconnection, timeout) ... > > SSH has its own keep-alive. NETCONF uses that. > > In implementation, the NETCONF layer has access to an SSH channel, not > > directly to a TCP socket. If the TCP connection is lost, then NETCONF > relies > > on the SSH session and channels getting closed. If SSH cannot detect > the > > loss of TCP, then how would NETCONF be able to do so? > > > > The SSH keep-alives are essentially the same thing as if NETCONF used > the > > channel periodically to send a keep-alive message, so why bother > replicating > > that functionality at the application layer? > > > > From nobody Mon May 26 05:08:52 2014 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 A2EF41A00F6 for ; Mon, 26 May 2014 05:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 YGFrjl-sTgFl for ; Mon, 26 May 2014 05:08:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA911A012D for ; Mon, 26 May 2014 05:08:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHG09582; Mon, 26 May 2014 12:08:34 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 13:08:10 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 26 May 2014 13:08:32 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.207]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 26 May 2014 20:08:24 +0800 From: "Liubing (Leo)" To: =?utf-8?B?UmFkZWsgS3JlasSNw60=?= , Netconf Thread-Topic: [Netconf] Netconf running state indication-//RE: Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) Thread-Index: AQHPeL0r5wtHAzvwA0GucbKhnVaBgZtSoWEw Date: Mon, 26 May 2014 12:08:22 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B4A@nkgeml506-mbx.china.huawei.com> References: <201405091935.s49JZEPt067551@idle.juniper.net> <00b401cf6c42$59c8b1c0$4001a8c0@gateway.2wire.net> <8AE0F17B87264D4CAC7DE0AA6C406F453D8B359C@nkgeml506-mbx.china.huawei.com> <5382F9ED.9060407@cesnet.cz> In-Reply-To: <5382F9ED.9060407@cesnet.cz> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B4Ankgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WKvoamh01GYvQUA38vZbsXLhCFM Cc: Zhengguangying , Yangang Subject: Re: [Netconf] Netconf running state indication-//RE: Netconf keep-alive (was periodic connections, heartbeats, reconnection, timeout) 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 May 2014 12:08:48 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B4Ankgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFkZWssDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50LCBwbGVhc2Ugc2VlIGlubGluZS4N Cg0KRnJvbTogUmFkZWsgS3JlasSNw60gW21haWx0bzpya3JlamNpQGNlc25ldC5jel0NClNlbnQ6 IE1vbmRheSwgTWF5IDI2LCAyMDE0IDQ6MjMgUE0NClRvOiBMaXViaW5nIChMZW8pOyBOZXRjb25m DQpDYzogWmhlbmdndWFuZ3lpbmc7IFlhbmdhbmcNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gTmV0 Y29uZiBydW5uaW5nIHN0YXRlIGluZGljYXRpb24tLy9SRTogTmV0Y29uZiBrZWVwLWFsaXZlICh3 YXMgcGVyaW9kaWMgY29ubmVjdGlvbnMsIGhlYXJ0YmVhdHMsIHJlY29ubmVjdGlvbiwgdGltZW91 dCkNCg0KSGksDQoNCklNTyB0aGUgTkVUQ09ORiBFdmVudCBOb3RpZmljYXRpb25zIG1lY2hhbmlz bSBjYW4gYWxyZWFkeSB3b3JrIGFzIGtlZXAtYWxpdmUvaGVhcnRiZWF0IC0gd2hhdCBpZiBhIHNl cnZlciBoYXMgYW4gZXZlbnQgc3RyZWFtIG5hbWVkIGtlZXBhbGl2ZSBvciBoZWFydGJlYXQgKG9y IHdoYXRldmVyKSBhbmQgaW4gdGhpcyBzdHJlYW0gdGhlIHNlcnZlciBzZW5kcyB0aGUga2VlcC1h bGl2ZSBub3RpZmljYXRpb24gdG8gdGhlIGludGVyZXN0ZWQgY2xpZW50cy4ga2VlcC1hbGl2ZSBw ZXJpb2QgY2FuIGJlIGNvbmZpZ3VyYWJsZS4gT2YgY291cnNlLCB0aGVyZSBpcyBubyBzZW5zZSBm b3IgcmVwbGF5IGZlYXR1cmUgaW4gdGhpcyBldmVudCBzdHJlYW0uDQpbQmluZ10gRXZlbnQgTm90 aWZpY2F0aW9uIG1pZ2h0IGJlIHRvbyBoZWF2eSB0byBkbyB0aGUgcnVubmluZyBzdGF0ZSBpbmRp Y2F0aW9uLiBNeSByb3VnaCBpZGVhIGlzIHRoYXQgYSBtZXNzYWdpbmcgbWVjaGFuaXNtIHdpdGhp biB0aGUgb3BlcmF0aW9uIHNlc3Npb24gd291bGQgYmUgZ29vZC4NCg0KSSBkb24ndCBsaWtlIG9w ZXJhdGlvbiBrZWVwIGFsaXZlIChwb3NzaWJseSB3aXRoIGEgcHJvZ3Jlc3MgaW5mbykuIFRvbSBh bHJlYWR5IHN0YXRlZCBzb21lIHJlYXNvbnMuIEZyb20gbXkgcG9pbnQgb2YgdmlldywgaXQgbmVl ZGxlc3NseSBjb21wbGljYXRlcyB0aGUga2VlcC1hbGl2ZSBtZWNoYW5pc20gaW4gTkVUQ09ORi4g SSBkb24ndCB0aGluayB0aGF0IGl0IGlzIGEgZ29vZCBpZGVhIHRvIHNlbmQgcHJvZ3Jlc3MgaW5m b3JtYXRpb24gb3IgZXZlbiBvcGVyYXRpb24gcHJvY2Vzc2luZyBpbmZvIHRvIF9hbGxfIGNsaWVu dHMgLSBpdCBzaG91bGQgYmUgcmVjZWl2ZWQgb25seSBieSB0aGUgY2xpZW50IHRoYXQgaW52b2tl ZCB0aGUgb3BlcmF0aW9uLg0KW0JpbmddIE15IHByb3Bvc2FsIGlzIE5PVCB0byBzZW5kIHRoZSBp bmZvcm1hdGlvbiB0byBfYWxsLWNsaWVudHMuIEl0IG9ubHkgaW5kaWNhdGUgdGhlIGNsaWVudCB3 aG8gc2VudCB0aGUgPHJwYz4gcmVxZXN0LCBpdCBpcyBvbmx5IHdpdGhpbiB0aGUgcmVsZXZhbnQg b3BlcmF0aW9uLiBJIHRoaW5rIHdlIGFjdHVhbGx5IHNoYXJlIHRoZSBzYW1lIG9waW5pb24gb24g dGhpcyBpc3N1ZS4NCkluIHRoYXQgY2FzZSB3ZSBoYXZlIGRpZmZlcmVudCBrZWVwLWFsaXZlIG1l c3NhZ2VzIHNlbnQgdG8gZGlmZmVyZW50IGNsaWVudHMuIEFuZCwgYXMgSSBzYWlkLCBpdCBuZWVk bGVzc2x5IGNvbXBsaWNhdGVzIGltcGxlbWVudGF0aW9uLg0KDQpJIHRoaW5rIHRoYXQgKGlmIHdl IG5lZWQgTkVUQ09ORiBrZWVwLWFsaXZlKSB3ZSBqdXN0IG5lZWQgaXQgdG8gc2F5ICJORVRDT05G IHNlcnZlciBpcyBhbGl2ZSIuIEkgYmVsaWV2ZSwgdGhhdCwgYXMgS2VudCBzdGF0ZWQsIFNTSCBr ZWVwLWFsaXZlcyBhcmUgZ29vZCBlbm91Z2ggZm9yIHNheWluZyAiTkVUQ09ORiBzZXNzaW9uIGlz IGFsaXZlIiAtIGp1c3QsIHBsZWFzZSwgS2VlcCBJdCBTaW1wbGUsIFN0dXBpZC4NCltCaW5nXSBB cyByZXBsaWVkIHRvIFRvbSwgaXQgbWlnaHQgZGVwZW5kIG9uIHRoZSB1c2UgY2FzZXMuIFdlIG5l ZWQgdG8gd29yayBtb3JlIG9uIHVzZSBjYXNlcy4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQoN ClJlZ2FyZHMsDQpSYWRlaw0KRG5lIDIzLjUuMjAxNCAwNjowMiwgTGl1YmluZyAoTGVvKSBuYXBz YWwoYSk6DQpIaSBhbGwsDQoNClRoaXMgbWFpbCBpcyByZWdhcmRpbmcgdG8gdGhlIGtlZXAtYWxp dmUgZGlzY3Vzc2lvbiByZWNlbnRseS4NCkZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiwgSSBub3Rp Y2VkIHRoZXJlIG1pZ2h0IGJlIHR3byBkaWZmZXJlbnQgdGhpbmdzIHRoYXQgSSBtaXhlZCB0aGVt IHRvZ2V0aGVyLiBMZXQgbWUgdHJ5IHRvIGRpc3Rpbmd1aXNoIHRoZW0gYXMgdGhlIGZvbGxvd2lu Zy4NCg0KDQoxKSAgICAgVG8ga2VlcCBhbiBpZGxlIHNlc3Npb24gYWxpdmUsIHNvIHRoYXQgYSBw ZXJzaXN0ZW50IGNvbm5lY3Rpb24gY291bGQgYmUgcmV0YWluZWQuIFRoaXMgc2hvdWxkIGJlIHRo ZSBjb21tb24gdW5kZXJzdGFuZGluZyBvZiBrZWVwLWFsaXZlLiBJbiB0aGlzIGNhc2UsIGJhc2lj YWxseSBJIGFncmVlIHdpdGggd2hhdCBBbmR5IHNhaWQgaW4gdGhlIGJlbG93IG1haWwsIHRoYXQg cmUtdXNpbmcgU1NIIGtlZXAtYWxpdmUgbWlnaHQgYmUgc3VmZmljaWVudCBmb3IgTmV0Y29uZi4N Cg0KMikgICAgIFRvIG1ha2UgYW4gYWN0aXZlIHNlc3Npb24gaW5kaWNhdGluZyB0aGUgTmV0Y29u ZiBydW5uaW5nIHN0YXRlIGluc3RhbnRseS4gRm9yIGV4YW1wbGUsIGFzIHRoZSBjYXNlIEkgZGVz Y3JpYmVkIGluIHRoZSBwcmV2aW91cyBtYWlsLCB0aGUgTk1TIHJlcXVlc3RzIGEgc2VhcmNoIG9w ZXJhdGlvbiB3aGljaCBtaWdodCBjb3N0IHRoZSByb3V0ZXIgYSBsb25nIHRpbWUgdG8gcHJvY2Vz cyBvciBldmVuIG1ha2UgdGhlIHJvdXRlciBzdXNwZW5kLiBUaGVuIGl0IHdvdWxkIGJlIGdvb2Qg Zm9yIHRoZSBOTVMgdG8gbGVhcm4gdGhlIHN0YXRlIG9mIHRoZSByb3V0ZXIgdGhyb3VnaCBhIHBl cmlvZGljIG1lc3NhZ2UuIEluIHRoZSBzaW1wbGVzdCBjYXNlLCB0aGUgc3RhdGUgaXMganVzdCBh Ym91dCB3aGV0aGVyIHRoZSByb3V0ZXIgaXMgc3RpbGwgYWxpdmUgb24gdGhlIG9wZXJhdGlvbi4N Cg0KVGhlIHNlY29uZCBvbmUgaXMganVzdCB0aGUgYWN0dWFsIHRvcGljIEkgaW50ZW5kZWQgdG8g ZGlzY3Vzcy4gSSBjYWxsZWQgc3VjaCBtZXNzYWdlIGFzIOKAnGtlZXAtYWxpdmXigJ0sIHdoaWNo IG1pZ2h0IG5vdCBiZSB2ZXJ5IHByb3Blci4gUmlnaHQgb3Igd3JvbmcsIHRoZSBwb2ludCBpcyBh Ym91dCB0aGUgcnVubmluZyBzdGF0ZSBpbmRpY2F0aW9uLCBqdXN0IHNpbWlsYXIgYXMgdGhlIHJl YWwtdGltZSBmZWVkYmFja3MgaW4gQ0xJIHdoZW4gdGhlIG9wZXJhdGlvbiB0aW1lIGlzIGxvbmcu DQpJZiB0aGVyZSBpcyBzdWNoIGEgbWVzc2FnZSBtZWNoYW5pc20sIHRoZSBOZXRjb25mIHNlcnZl ciBjb3VsZCBpbmRpY2F0ZSB0aGUgY2xpZW50IHNvbWV0aGluZyBsaWtlOg0KDQotICAgICAgICBp dCBpcyBzdGlsbCBwcm9jZXNzaW5nIHRoZSBvcGVyYXRpb24gKOKAnGtlZXAtYWxpdmXigJ0pDQoN Ci0gICAgICAgIHRoZSByYXRlIG9mIHByb2dyZXNzDQoNCi0gICAgICAgIHNvbWUga2V5IHByb2Nl c3NpbmcgaW5mb3JtYXRpb24NCg0KLSAgICAgICAgLi4uZXRjLg0KDQpEbyB5b3UgdGhpbmsgaXQg aXMgZ29vZCB0byBoYXZlIHN1Y2ggYSBmZWF0dXJlIGluIE5ldGNvbmY/DQoNCg0KUmVnYXJkcywN CkJpbmcNCg0KRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogU2F0dXJkYXksIE1heSAxMCwgMjAxNCAx MTozOSBQTQ0KVG86IHQucGV0Y2gNCkNjOiBOZXRjb25mDQpTdWJqZWN0OiBSZTogW05ldGNvbmZd IE5ldGNvbmYga2VlcC1hbGl2ZSAod2FzIHBlcmlvZGljIGNvbm5lY3Rpb25zLCBoZWFydGJlYXRz LCByZWNvbm5lY3Rpb24sIHRpbWVvdXQpDQouLi4NClNTSCBoYXMgaXRzIG93biBrZWVwLWFsaXZl LiBORVRDT05GIHVzZXMgdGhhdC4NCkluIGltcGxlbWVudGF0aW9uLCB0aGUgTkVUQ09ORiBsYXll ciBoYXMgYWNjZXNzIHRvDQphbiBTU0ggY2hhbm5lbCwgbm90IGRpcmVjdGx5IHRvIGEgVENQIHNv Y2tldC4gIElmIHRoZQ0KVENQIGNvbm5lY3Rpb24gaXMgbG9zdCwgdGhlbiBORVRDT05GIHJlbGll cyBvbiB0aGUgU1NIIHNlc3Npb24NCmFuZCBjaGFubmVscyBnZXR0aW5nIGNsb3NlZC4gIElmIFNT SCBjYW5ub3QgZGV0ZWN0IHRoZSBsb3NzIG9mIFRDUCwNCnRoZW4gaG93IHdvdWxkIE5FVENPTkYg YmUgYWJsZSB0byBkbyBzbz8NCg0KVGhlIFNTSCBrZWVwLWFsaXZlcyBhcmUgZXNzZW50aWFsbHkg dGhlIHNhbWUgdGhpbmcgYXMgaWYgTkVUQ09ORg0KdXNlZCB0aGUgY2hhbm5lbCBwZXJpb2RpY2Fs bHkgdG8gc2VuZCBhIGtlZXAtYWxpdmUgbWVzc2FnZSwgc28gd2h5DQpib3RoZXIgcmVwbGljYXRp bmcgdGhhdCBmdW5jdGlvbmFsaXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllcj8NCg0KDQoNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk5l dGNvbmYgbWFpbGluZyBsaXN0DQoNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0 Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K DQoNCg0KLS0NCg0KUmFkZWsgS3JlamNpDQoNCm1vYmlsZTogKzQyMCA3MzIgMjEyIDcxNA0KDQpv ZmZpY2U6ICs0MjAgMjM0IDY4MCAyNTYNCg0KZS1tYWlsOiBya3JlamNpQGNlc25ldC5jejxtYWls dG86cmtyZWpjaUBjZXNuZXQuY3o+DQoNCg0KDQpDRVNORVQNCg0KQXNzb2NpYXRpb24gb2YgTGVn YWwgRW50aXRpZXMNCg0KMTYwIDAwIFByYWhhIDYsIFppa292YSA0DQoNCkN6ZWNoIFJlcHVibGlj DQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B4Ankgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRh dGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50 OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1l OiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+ 5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNw YW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6NzM2NjczNzk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xMjU5NTc2MjI2IDE1OTc5MTgwOTggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OuWui+S9kzt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6OTE3MTM2MzQ4Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo4NjM0MjAzNTAgMTg1MjA4MTE4NCA2NzY5 ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIx Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg Ymdjb2xvcj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJhZGVr LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgY29t bWVudCwgcGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3 aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBSYWRlayBLcmVqxI3DrSBbbWFpbHRvOnJrcmVq Y2lAY2VzbmV0LmN6XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDI2LCAyMDE0IDQ6 MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IExpdWJpbmcgKExlbyk7IE5ldGNvbmY8YnI+DQo8Yj5DYzo8 L2I+IFpoZW5nZ3Vhbmd5aW5nOyBZYW5nYW5nPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0 Y29uZl0gTmV0Y29uZiBydW5uaW5nIHN0YXRlIGluZGljYXRpb24tLy9SRTogTmV0Y29uZiBrZWVw LWFsaXZlICh3YXMgcGVyaW9kaWMgY29ubmVjdGlvbnMsIGhlYXJ0YmVhdHMsIHJlY29ubmVjdGlv biwgdGltZW91dCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHR0PjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyI+ PGJyPg0KPGJyPg0KPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTi1VUyI+SU1PIHRoZSBORVRDT05G IEV2ZW50IE5vdGlmaWNhdGlvbnMgbWVjaGFuaXNtIGNhbiBhbHJlYWR5IHdvcmsgYXMga2VlcC1h bGl2ZS9oZWFydGJlYXQgLSB3aGF0IGlmIGEgc2VydmVyIGhhcyBhbiBldmVudCBzdHJlYW0gbmFt ZWQga2VlcGFsaXZlIG9yIGhlYXJ0YmVhdCAob3Igd2hhdGV2ZXIpIGFuZCBpbiB0aGlzIHN0cmVh bSB0aGUgc2VydmVyIHNlbmRzIHRoZSBrZWVwLWFsaXZlIG5vdGlmaWNhdGlvbg0KIHRvIHRoZSBp bnRlcmVzdGVkIGNsaWVudHMuIGtlZXAtYWxpdmUgcGVyaW9kIGNhbiBiZSBjb25maWd1cmFibGUu IE9mIGNvdXJzZSwgdGhlcmUgaXMgbm8gc2Vuc2UgZm9yIHJlcGxheSBmZWF0dXJlIGluIHRoaXMg ZXZlbnQgc3RyZWFtLjwvc3Bhbj48L3R0Pjx0dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvdHQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBFdmVudCBOb3RpZmljYXRp b24gbWlnaHQgYmUgdG9vIGhlYXZ5IHRvIGRvIHRoZSBydW5uaW5nIHN0YXRlIGluZGljYXRpb24u IE15IHJvdWdoIGlkZWEgaXMgdGhhdCBhIG1lc3NhZ2luZw0KIG1lY2hhbmlzbSB3aXRoaW4gdGhl IG9wZXJhdGlvbiBzZXNzaW9uIHdvdWxkIGJlIGdvb2QuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZG9uJ3Qg bGlrZSBvcGVyYXRpb24ga2VlcCBhbGl2ZSAocG9zc2libHkgd2l0aCBhIHByb2dyZXNzIGluZm8p LiBUb20gYWxyZWFkeSBzdGF0ZWQgc29tZSByZWFzb25zLiBGcm9tIG15IHBvaW50IG9mIHZpZXcs IGl0IG5lZWRsZXNzbHkgY29tcGxpY2F0ZXMgdGhlIGtlZXAtYWxpdmUgbWVjaGFuaXNtIGluIE5F VENPTkYuIEkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBpcyBhIGdvb2QgaWRlYSB0byBzZW5kDQogcHJv Z3Jlc3MgaW5mb3JtYXRpb24gb3IgZXZlbiBvcGVyYXRpb24gcHJvY2Vzc2luZyBpbmZvIHRvIF9h bGxfIGNsaWVudHMgLSBpdCBzaG91bGQgYmUgcmVjZWl2ZWQgb25seSBieSB0aGUgY2xpZW50IHRo YXQgaW52b2tlZCB0aGUgb3BlcmF0aW9uLg0KPC9zcGFuPjwvdHQ+PHR0PjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC90dD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjx0dD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5n XSBNeSBwcm9wb3NhbCBpcyBOT1QgdG8gc2VuZCB0aGUgaW5mb3JtYXRpb24gdG8gX2FsbC1jbGll bnRzLiBJdCBvbmx5IGluZGljYXRlIHRoZSBjbGllbnQgd2hvIHNlbnQgdGhlICZsdDtycGMmZ3Q7 DQogcmVxZXN0LCBpdCBpcyBvbmx5IHdpdGhpbiB0aGUgcmVsZXZhbnQgb3BlcmF0aW9uLiBJIHRo aW5rIHdlIGFjdHVhbGx5IHNoYXJlIHRoZSBzYW1lIG9waW5pb24gb24gdGhpcyBpc3N1ZS48bzpw PjwvbzpwPjwvc3Bhbj48L3R0PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHR0PjxzcGFuIGxhbmc9IkVOLVVTIj5JbiB0aGF0IGNhc2Ugd2Ug aGF2ZSBkaWZmZXJlbnQga2VlcC1hbGl2ZSBtZXNzYWdlcyBzZW50IHRvIGRpZmZlcmVudCBjbGll bnRzLiBBbmQsIGFzIEkgc2FpZCwgaXQgbmVlZGxlc3NseSBjb21wbGljYXRlcyBpbXBsZW1lbnRh dGlvbi48L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPC9zcGFuPjx0 dD48c3BhbiBsYW5nPSJFTi1VUyI+SSB0aGluayB0aGF0IChpZiB3ZSBuZWVkIE5FVENPTkYga2Vl cC1hbGl2ZSkgd2UganVzdCBuZWVkIGl0IHRvIHNheSAmcXVvdDtORVRDT05GIHNlcnZlciBpcyBh bGl2ZSZxdW90Oy4gSSBiZWxpZXZlLCB0aGF0LCBhcyBLZW50IHN0YXRlZCwgU1NIIGtlZXAtYWxp dmVzIGFyZSBnb29kIGVub3VnaCBmb3Igc2F5aW5nICZxdW90O05FVENPTkYgc2Vzc2lvbiBpcyBh bGl2ZSZxdW90OyAtIGp1c3QsIHBsZWFzZSwgS2VlcCBJdCBTaW1wbGUsDQogU3R1cGlkLjwvc3Bh bj48L3R0PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bQmluZ10gQXMgcmVwbGllZCB0byBUb20sIGl0IG1pZ2h0 IGRlcGVuZCBvbiB0aGUgdXNlIGNhc2VzLiBXZSBuZWVkIHRvIHdvcmsgbW9yZSBvbiB1c2UgY2Fz ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBsYW5n PSJFTi1VUyI+UmVnYXJkcyw8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPC9z cGFuPjx0dD48c3BhbiBsYW5nPSJFTi1VUyI+UmFkZWs8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjx0dD48c3BhbiBsYW5nPSJFTi1VUyI+RG5lIDIzLjUuMjAxNCAwNjowMiwgTGl1YmluZyAoTGVv KSBuYXBzYWwoYSk6PC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgbWFpbCBpcyByZWdhcmRpbmcgdG8gdGhlIGtlZXAt YWxpdmUgZGlzY3Vzc2lvbiByZWNlbnRseS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9sbG93aW5nIHRoZSBkaXNj dXNzaW9uLCBJIG5vdGljZWQgdGhlcmUgbWlnaHQgYmUgdHdvIGRpZmZlcmVudCB0aGluZ3MgdGhh dCBJIG1peGVkIHRoZW0gdG9nZXRoZXIuIExldCBtZSB0cnkgdG8gZGlzdGluZ3Vpc2ggdGhlbSBh cyB0aGUgZm9sbG93aW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRvIGtlZXAgYW4gaWRsZSBzZXNzaW9uIGFsaXZlLCBz byB0aGF0IGEgcGVyc2lzdGVudCBjb25uZWN0aW9uIGNvdWxkIGJlIHJldGFpbmVkLiBUaGlzIHNo b3VsZCBiZSB0aGUgY29tbW9uIHVuZGVyc3RhbmRpbmcgb2Yga2VlcC1hbGl2ZS4NCiBJbiB0aGlz IGNhc2UsIGJhc2ljYWxseSBJIGFncmVlIHdpdGggd2hhdCBBbmR5IHNhaWQgaW4gdGhlIGJlbG93 IG1haWwsIHRoYXQgcmUtdXNpbmcgU1NIIGtlZXAtYWxpdmUgbWlnaHQgYmUgc3VmZmljaWVudCBm b3IgTmV0Y29uZi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRvIG1ha2UgYW4gYWN0aXZlIHNlc3Npb24gaW5kaWNhdGluZyB0aGUgTmV0Y29uZiBydW5uaW5n IHN0YXRlIGluc3RhbnRseS4gRm9yIGV4YW1wbGUsIGFzIHRoZSBjYXNlIEkgZGVzY3JpYmVkIGlu IHRoZSBwcmV2aW91cyBtYWlsLA0KIHRoZSBOTVMgcmVxdWVzdHMgYSBzZWFyY2ggb3BlcmF0aW9u IHdoaWNoIG1pZ2h0IGNvc3QgdGhlIHJvdXRlciBhIGxvbmcgdGltZSB0byBwcm9jZXNzIG9yIGV2 ZW4gbWFrZSB0aGUgcm91dGVyIHN1c3BlbmQuIFRoZW4gaXQgd291bGQgYmUgZ29vZCBmb3IgdGhl IE5NUyB0byBsZWFybiB0aGUgc3RhdGUgb2YgdGhlIHJvdXRlciB0aHJvdWdoIGEgcGVyaW9kaWMg bWVzc2FnZS4gSW4gdGhlIHNpbXBsZXN0IGNhc2UsIHRoZSBzdGF0ZSBpcyBqdXN0IGFib3V0DQog d2hldGhlciB0aGUgcm91dGVyIGlzIHN0aWxsIGFsaXZlIG9uIHRoZSBvcGVyYXRpb24uPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgc2Vjb25kIG9uZSBpcyBqdXN0IHRoZSBhY3R1 YWwgdG9waWMgSSBpbnRlbmRlZCB0byBkaXNjdXNzLiBJIGNhbGxlZCBzdWNoIG1lc3NhZ2UgYXMg 4oCca2VlcC1hbGl2ZeKAnSwgd2hpY2ggbWlnaHQgbm90IGJlIHZlcnkgcHJvcGVyLiBSaWdodCBv cg0KIHdyb25nLCB0aGUgcG9pbnQgaXMgYWJvdXQgdGhlIHJ1bm5pbmcgc3RhdGUgaW5kaWNhdGlv biwganVzdCBzaW1pbGFyIGFzIHRoZSByZWFsLXRpbWUgZmVlZGJhY2tzIGluIENMSSB3aGVuIHRo ZSBvcGVyYXRpb24gdGltZSBpcyBsb25nLiAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhlcmUgaXMg c3VjaCBhIG1lc3NhZ2UgbWVjaGFuaXNtLCB0aGUgTmV0Y29uZiBzZXJ2ZXIgY291bGQgaW5kaWNh dGUgdGhlIGNsaWVudCBzb21ldGhpbmcgbGlrZToNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5pdCBpcyBzdGlsbCBw cm9jZXNzaW5nIHRoZSBvcGVyYXRpb24gKOKAnGtlZXAtYWxpdmXigJ0pPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRo ZSByYXRlIG9mIHByb2dyZXNzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm80Ij4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnNvbWUga2V5IHByb2Nlc3NpbmcgaW5mb3Jt YXRpb248L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Li4uZXRjLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ RG8geW91IHRoaW5rIGl0IGlzIGdvb2QgdG8gaGF2ZSBzdWNoIGEgZmVhdHVyZSBpbiBOZXRjb25m Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkJpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5ldGNvbmYgWzxhIGhy ZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48YnI+DQo8 Yj5TZW50OjwvYj4gU2F0dXJkYXksIE1heSAxMCwgMjAxNCAxMTozOSBQTTxicj4NCjxiPlRvOjwv Yj4gdC5wZXRjaDxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW05ldGNvbmZdIE5ldGNvbmYga2VlcC1hbGl2ZSAod2FzIHBlcmlvZGljIGNvbm5lY3Rpb25z LCBoZWFydGJlYXRzLCByZWNvbm5lY3Rpb24sIHRpbWVvdXQpPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Li4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+U1NIIGhhcyBpdHMgb3duIGtlZXAtYWxpdmUuIE5FVENPTkYgdXNlcyB0 aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBpbXBsZW1lbnRhdGlvbiwgdGhlIE5FVENPTkYg bGF5ZXIgaGFzIGFjY2VzcyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hbiBTU0ggY2hhbm5lbCwg bm90IGRpcmVjdGx5IHRvIGEgVENQIHNvY2tldC4gJm5ic3A7SWYgdGhlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlRDUCBjb25uZWN0aW9uIGlzIGxvc3QsIHRoZW4gTkVUQ09ORiByZWxpZXMgb24gdGhl IFNTSCBzZXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFuZCBjaGFubmVscyBnZXR0aW5nIGNs b3NlZC4gJm5ic3A7SWYgU1NIIGNhbm5vdCBkZXRlY3QgdGhlIGxvc3Mgb2YgVENQLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj50aGVuIGhvdyB3b3VsZCBORVRDT05GIGJlIGFibGUgdG8gZG8gc28/Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg U1NIIGtlZXAtYWxpdmVzIGFyZSBlc3NlbnRpYWxseSB0aGUgc2FtZSB0aGluZyBhcyBpZiBORVRD T05GPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnVzZWQgdGhlIGNoYW5uZWwgcGVyaW9kaWNhbGx5IHRv IHNlbmQgYSBrZWVwLWFsaXZlIG1lc3NhZ2UsIHNvIHdoeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5i b3RoZXIgcmVwbGljYXRpbmcgdGhhdCBmdW5jdGlvbmFsaXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBs YXllcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OuWui+S9kyI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiPk5ldGNvbmYgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9y ZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMi Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+ UmFkZWsgS3JlamNpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj5tb2JpbGU6ICYjNDM7NDIwIDczMiAyMTIgNzE0PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5vZmZpY2U6ICYjNDM7NDIwIDIzNCA2ODAgMjU2PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5lLW1haWw6IDxh IGhyZWY9Im1haWx0bzpya3JlamNpQGNlc25ldC5jeiI+cmtyZWpjaUBjZXNuZXQuY3o8L2E+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkNFU05FVDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+QXNzb2NpYXRpb24g b2YgTGVnYWwgRW50aXRpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4tVVMiPjE2MCAwMCBQcmFoYSA2LCBaaWtvdmEgNDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Q3plY2ggUmVwdWJsaWM8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8B6B4Ankgeml506mbxchi_-- From nobody Tue May 27 14:30:21 2014 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 786641A0781 for ; Tue, 27 May 2014 14:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 F0oSW6cM7YQ7 for ; Tue, 27 May 2014 14:30:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12751A0428 for ; Tue, 27 May 2014 14:30:17 -0700 (PDT) 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.0.949.11; Tue, 27 May 2014 21:30:08 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.75]) with mapi id 15.00.0949.001; Tue, 27 May 2014 21:30:08 +0000 From: Kent Watsen To: Benoit Claise , NETCONF Thread-Topic: [Netconf] draft-ietf-netconf-reverse-ssh: MUST only be used for a NETCONF server Thread-Index: AQHPN7qRbEntuwYggEq2TH81C6tQ8ptVMyIA Date: Tue, 27 May 2014 21:30:06 +0000 Message-ID: References: <5315AA7F.6080006@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.1.140326 x-originating-ip: [66.129.241.11] x-forefront-prvs: 02243C58C6 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(377454003)(199002)(189002)(164054003)(66066001)(79102001)(99286001)(80022001)(99396002)(50986999)(64706001)(83506001)(83322001)(76176999)(83072002)(20776003)(36756003)(19580395003)(92726001)(92566001)(16236675002)(87936001)(21056001)(86362001)(54356999)(101416001)(31966008)(74662001)(4396001)(19580405001)(76482001)(81342001)(74502001)(77982001)(85852003)(2656002)(81542001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; Content-Type: multipart/alternative; boundary="_000_CFAA7A4472CFEkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Di0VyA_oiZsdl2cR34YmjHdQMUo Subject: Re: [Netconf] draft-ietf-netconf-reverse-ssh: MUST only be used for a NETCONF server 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 May 2014 21:30:20 -0000 --_000_CFAA7A4472CFEkwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just reviewing list mail while putting the finishing touches on the netconf= -server-model draft and noticed this one. Unfortunately, this change did NOT make it into the -06 draft. I just mad= e this change to my working copy, as the first change that will go into -07= , which I'll hold off posting for now... Thanks, Kent From: Kent Watsen > Date: Tuesday, March 4, 2014 at 4:01 PM To: Benoit Claise >, NetConf > Cc: Stephen Hanna > Subject: Re: [Netconf] draft-ietf-netconf-reverse-ssh: MUST only be used fo= r a NETCONF server CC-ing Steve, who wrote the Applicability Statement. Kent From: Benoit Claise > Date: Tuesday, March 4, 2014 5:27 AM To: NetConf > Subject: [Netconf] draft-ietf-netconf-reverse-ssh: MUST only be used for a = NETCONF server Dear all, Yesterday, Andy asked how this MUST could be enforced in draft-ietf-netconf= -reverse-ssh However, these techniques MUST only be used for a NETCONF server to initiate a connection to a NETCONF client, as described in this document. The way I understood this statement: the security experts wanted us to rest= rict the scope to only NETCONF. Fine. However, that "MUST" can't be enforced, at least with RFC 2119 keyword. This should be changed to "must". We should obviously validate this with the security experts. Regards, Benoit --_000_CFAA7A4472CFEkwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Just reviewing list mail while putting the finishing touches on the ne= tconf-server-model draft and noticed this one.

Unfortunately, this change did NOT make it into the -06 draft.   = I just made this change to my working copy, as the first change that will g= o into –07, which I'll hold off posting for now...

Thanks,
Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Tuesday, March 4, 2014 at 4:0= 1 PM
To: Benoit Claise <bclaise@cisco.com>, NetConf <netconf@ietf.org>
Cc: Stephen Hanna <shanna@juniper.net>
Subject: Re: [Netconf] draft-ietf-n= etconf-reverse-ssh: MUST only be used for a NETCONF server



CC-ing Steve, who wrote the Applicability Statement.

Kent


From: Benoit Claise <bclaise@cisco.com>
Date: Tuesday, March 4, 2014 5:27 A= M
To: NetConf <netconf@ietf.org>
Subject: [Netconf] draft-ietf-netco= nf-reverse-ssh: MUST only be used for a NETCONF server

Dear all,

Yesterday, Andy asked how this MUST could be enforced in draft-ietf-netconf= -reverse-ssh
   However, these techniques MUST only be used for a = NETCONF server to
    initiate a connection to a NETCONF client, as described = in this
    document.
The way I understood this statement: the security experts wanted us to rest= rict the scope to only NETCONF. Fine.
However, that "MUST" can't be enforced, at least with RFC 2119 ke= yword.
This should be changed to "must".

We should obviously validate this with the security experts.

Regards, Benoit


 --_000_CFAA7A4472CFEkwatsenjunipernet_-- From nobody Wed May 28 16:39:17 2014 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 36E611A02B5 for ; Wed, 28 May 2014 16:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 9ueXOwp3hlpo for ; Wed, 28 May 2014 16:39:14 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8951A02B0 for ; Wed, 28 May 2014 16:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10999; q=dns/txt; s=iport; t=1401320350; x=1402529950; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=HyEye0h4znKAFHMe7WlCNUQe3PQrfygWYAGojh1ZgUw=; b=U0dX2XFla0DXdB6Fmr3hnadnMoKArsKjuapr/1IczAjtxUpUCnXPJ00c HJbRb/wmdF2SP/VNLPU+gWH+3zgbjH5Ap4Qd65AsPWg8U61tf9zzTMRHN pLolzFPNPdPoQkQtwZE3lqmp22CngrIRRX4rF83fKZrob2QACQKaRBoCq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4GAEJyhlOtJV2d/2dsb2JhbABagkJFgSqqDwEBAQEBAQUBmB0BgQ8WdIIsgQsBgQAlAgSIVaNOtEAXhVWJBIRABJl1kyeDOIIv X-IronPort-AV: E=Sophos;i="4.98,931,1392163200"; d="scan'208,217";a="328687793" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 28 May 2014 23:39:10 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4SNd95N011259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 May 2014 23:39:09 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 28 May 2014 18:39:09 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: Netconf Thread-Topic: Restconf: rendering the response to a GET on a list entry in json Thread-Index: AQHPerwKLqqLC2/pFUuoXJex4oDl8ZtWhQgA Date: Wed, 28 May 2014 23:39:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.204.237] Content-Type: multipart/alternative; boundary="_000_CFABC0BA6D8BFalbertgociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-BMiBCCD73gNlPsk0cMQt8JD7L4 Subject: [Netconf] Restconf: rendering the response to a GET on a list entry in json 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 May 2014 23:39:15 -0000 --_000_CFABC0BA6D8BFalbertgociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I would appreciate clarification on how to render the response to a GET fo= r a list entry. More specifically, should it be rendered as a list or differently (say lik= e a container) ? E.g., GET /restconf/data/example-jukebox:jukebox/ library/artist/Foo%20Fighters I understand that in XML, the response would be Foo Fighters (=85) How would that be rendered in json? Should it be rendered as list? I.e., { "artist" : [ { "name" : "Foo Fighters", "album " : [ (=85) ] } ] } Or render it as containers are? I.e., { "artist" : { "name" : "Foo Fighters", "album " : [ (=85) ] } } Thanks, Alberto --_000_CFABC0BA6D8BFalbertgociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I would appreciate clarification on how to render the response to  a G= ET for a list entry.
More specifically, should  it be rendered as a list or differently (sa= y like a container) ?

E.g.,
GET /restconf/data/example-jukebox:jukebox/
        library/artist/Foo%20Fighters

I understand that in XML, the response would be

<artist>
    <name> Foo Fighters </name>
    <album> 
     (=85)
    </album>
</artist>


How would that be rendered in json? Should it be rendere=
d as list? I.e.,

{
    "artist" : [
     {
      "name" : "Foo=
 Fighters",
      "album " : [=

                      (=85)
                  ]
             }
    ]
}


Or render it as containers are? I.e., 

{
    "artist" :  {
   "name=
" : "Foo Fighters",
 =
  "album " : [
                 =
     (=85)
        ]
     }
}


Thanks,<=
/font>

Alberto

 --_000_CFABC0BA6D8BFalbertgociscocom_-- From nobody Wed May 28 17:55:37 2014 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 C19AB1A0310 for ; Wed, 28 May 2014 17:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gFak9JhH3fEI for ; Wed, 28 May 2014 17:55:34 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC7F1A07D0 for ; Wed, 28 May 2014 17:55:34 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so19731764qgd.5 for ; Wed, 28 May 2014 17:55:29 -0700 (PDT) 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=QYHxYwb1D1p0wlgPZ9k3a2KnLecVySG0kIRXgnXmEGY=; b=Wlu/Z5FHt9o5vgLFM7exoq7XYqLHYcXwPxWOq3oJrMVxjXuHPiK3NwxsleQrjtbfl1 0hVNy+mxUPm1+WxcHq+eaAaDvvid8tSxBbIWXvyyFyaQTdLakxgFiAqPyi0Se6qBO+90 2ejDE6SemH1F0XUF9hz6jW0k6uPHUeARytTtuE2YJy++pyL+l8eZrquCHIJzylZmghux uY4lsodkDTVEBzEvmzq6eU18jMExXRLWy1fK2URxKrM1D4MLuFtbeRoqdF7LkO7+O6BJ La3HlnkutFr24TSc5EMd/h3QYKbUeXAQFkERRPmfamX+DL7S/F/NKvsh4/YVKxDCZa6X IHqQ== X-Gm-Message-State: ALoCoQmZS13GO/TEFGB4qKveyx3IAUuPlWyWfdl8RyYEF6Kyp6YSwSvuXzzQAiilpOtkLEmY3twy MIME-Version: 1.0 X-Received: by 10.224.165.70 with SMTP id h6mr4994488qay.78.1401324929821; Wed, 28 May 2014 17:55:29 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 28 May 2014 17:55:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 May 2014 17:55:29 -0700 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=089e0149c3a4a8b6ed04fa7f62dc Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4qa2_Z8arwEr4_GWB3S7gBJqNTU Cc: Netconf Subject: Re: [Netconf] Restconf: rendering the response to a GET on a list entry in json 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 May 2014 00:55:35 -0000 --089e0149c3a4a8b6ed04fa7f62dc Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 28, 2014 at 4:39 PM, Alberto Gonzalez Prieto (albertgo) < albertgo@cisco.com> wrote: > Hi, > > I would appreciate clarification on how to render the response to a GET > for a list entry. > More specifically, should it be rendered as a list or differently (say > like a container) ? > > E.g., > > GET /restconf/data/example-jukebox:jukebox/ > library/artist/Foo%20Fighters > > > I understand that in XML, the response would be > > > > > Foo Fighters > > > > (...) > > > > > > > > How would that be rendered in json? Should it be rendered as list? I.e., > > > { > > "artist" : [ > > { > > "name" : "Foo Fighters", > > "album " : [ > > (...) > > ] > > } > > ] > > } > > > yes. http://www.ietf.org/id/draft-ietf-netmod-yang-json-00.txt see sec. 3.2.4 Andy > > Or render it as containers are? I.e., > > > { > > "artist" : { > > "name" : "Foo Fighters", > > "album " : [ > > (...) > > ] > > } > > } > > > > Thanks, > > Alberto > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --089e0149c3a4a8b6ed04fa7f62dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 28, 2014 at 4:39 PM, Alberto Gonzalez Prieto (albertgo)= <albertgo@cisco.com> wrote:
Hi,

I would appreciate clarification on how to render the response to  a G= ET for a list entry.
More specifically, should  it be rendered as a list or differently (sa= y like a container) ?

E.g.,
GET /restconf/data/example-jukebox:jukeb=
ox/
        library/artist/Foo%20Fighters

I understand that in XML, the response w=
ould be

<artist>
    <name> Foo Fighters </name&=
gt;
    <album> 
     (…)
    </album>
</artist>


How would that be rendered in json? Shou=
ld it be rendered as list? I.e.,

{
    "artist" : [
     {
      "name&q=
uot; : "Foo Fighters",
      "album<=
/font> =
" : [
                      (<=
/span>&hel=
lip;)
                  ]

             }


    ]


}



yes.


see sec. 3.2.4


Andy
 





Or render it as containers are? I.e., 




{
    "artist" :  {
   "name" =
: "Foo Fighters",


   "album " : [<=
/pre>
              =
        (…)
        ]


     }
<=
font face=3D"Calibri,sans-serif">}




<=
font face=3D"Calibri,sans-serif">Thanks,

Al=
berto















_______________________________________________

Netconf mailing list

Netconf@ietf.org

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





--089e0149c3a4a8b6ed04fa7f62dc--


From nobody Wed May 28 23:40:50 2014
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 433371A0359 for ; Wed, 28 May 2014 23:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6GxudsW0eLk for ; Wed, 28 May 2014 23:40:46 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069481A0330 for ; Wed, 28 May 2014 23:40:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AC9905405BE; Thu, 29 May 2014 08:40:38 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI72J4+8joiq; Thu, 29 May 2014 08:40:34 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 0481E540200; Thu, 29 May 2014 08:40:33 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman , "Alberto Gonzalez Prieto \(albertgo\)" 
In-Reply-To: 
References:   
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 29 May 2014 08:40:32 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/LpOeQAiCbvA57HoodOUP7-1p82Y
Cc: Netconf 
Subject: Re: [Netconf] Restconf: rendering the response to a GET on a list entry in json
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 May 2014 06:40:48 -0000

Andy Bierman  writes:

> On Wed, May 28, 2014 at 4:39 PM, Alberto Gonzalez Prieto (albertgo) <
> albertgo@cisco.com> wrote:
>
>>   Hi,
>>
>>  I would appreciate clarification on how to render the response to  a GET
>> for a list entry.
>>  More specifically, should  it be rendered as a list or differently (say
>> like a container) ?
>>
>>  E.g.,
>>
>> GET /restconf/data/example-jukebox:jukebox/
>>         library/artist/Foo%20Fighters
>>
>>
>> I understand that in XML, the response would be
>>
>>
>> 
>>
>>      Foo Fighters 
>>
>>     
>>
>>      (...)
>>
>>     
>>
>> 
>>
>>
>>
>> How would that be rendered in json? Should it be rendered as list? I.e.,
>>
>>
>> {
>>
>>     "artist" : [
>>
>>      {
>>
>>       "name" : "Foo Fighters",
>>
>>       "album " : [
>>
>>                       (...)
>>
>>                   ]
>>
>>              }
>>
>>     ]
>>
>> }
>>
>>
>>
>
> yes.
>
> http://www.ietf.org/id/draft-ietf-netmod-yang-json-00.txt
>
> see sec. 3.2.4

Well, that section defines the JSON encoding for a list but here the GET query asks for a single list entry, which clearly is an object.

I think it is up to the RESTCONF spec to define the contents of protocol messages, the cited draft deals with JSON encoding of repository contents. I can imagine that RESTCONF defines a special "response object" so that only the requested value is returned (without the name of the list), e.g.:

"data" :
  {
    "name": "Foo Fighters",
    "album": [ ...]
  }

Lada

>
>
> Andy
>
>
>>
>> Or render it as containers are? I.e.,
>>
>>
>> {
>>
>>     "artist" :  {
>>
>>    "name" : "Foo Fighters",
>>
>>    "album " : [
>>
>>                       (...)
>>
>>         ]
>>
>>      }
>>
>> }
>>
>>
>>
>> Thanks,
>>
>> Alberto
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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


From nobody Thu May 29 00:15:04 2014
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 2BA491A0793 for ; Thu, 29 May 2014 00:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bVGPUD1PRtcB for ; Thu, 29 May 2014 00:15:00 -0700 (PDT)
Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702701A031C for ; Thu, 29 May 2014 00:15:00 -0700 (PDT)
Received: by mail-qg0-f41.google.com with SMTP id j5so21236757qga.14 for ; Thu, 29 May 2014 00:14:56 -0700 (PDT)
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=LAVwJ6FjcJl6F8SwLAF7jr4HkQtwEpj+HZkXm25Lhxs=; b=IrSP1GBHSXwqCX57U0U9gZIYl4Mm2Y935V0cUCwzfPDqip388o3UFKtthjOOWooad+ 3d9A3KU/yvvyFx9N1Z0MdMe/FAqtrOjo34tdgBd2vs0DZfqpOHEwfXIoFaz/hFBN6+eN 3Jb+nk5BGJ7CtvU8yvxuX1JbxEDyGSF8PJfCBSqPE57/viBSLaWJKyxwuIiyF7zHpJXC YpXhLIiDXMHq+WF7U8S/wIHYAr0vQ1/+hgzYARi4NYR4n5/ey1JmVUYTnkZ16ScJakVK OHr7a4zCY6QjEnpGecFSjqhfWSxbNwxyRsN8qia4pAfGdc5O+1Cq6Ob6xTCAiKw2x61M IT2A==
X-Gm-Message-State: ALoCoQmhz/ylQWTP/Hg0aO18Z+TDILVEzlggZopAT+pGWTCzoF8xRZvsEqTAKsQxC8loqiwSFAGJ
MIME-Version: 1.0
X-Received: by 10.224.64.132 with SMTP id e4mr7204103qai.16.1401347696083; Thu, 29 May 2014 00:14:56 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 29 May 2014 00:14:55 -0700 (PDT)
In-Reply-To: 
References:    
Date: Thu, 29 May 2014 00:14:55 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c20e7aa1dd9304fa84af03
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/18_mdd9Jnvel_yse2AF6x4K8XU4
Cc: Netconf 
Subject: Re: [Netconf] Restconf: rendering the response to a GET on a list entry in json
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 May 2014 07:15:02 -0000

--001a11c20e7aa1dd9304fa84af03
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 28, 2014 at 11:40 PM, Ladislav Lhotka  wrote:

> Andy Bierman  writes:
>
> > On Wed, May 28, 2014 at 4:39 PM, Alberto Gonzalez Prieto (albertgo) <
> > albertgo@cisco.com> wrote:
> >
> >>   Hi,
> >>
> >>  I would appreciate clarification on how to render the response to  a
> GET
> >> for a list entry.
> >>  More specifically, should  it be rendered as a list or differently (say
> >> like a container) ?
> >>
> >>  E.g.,
> >>
> >> GET /restconf/data/example-jukebox:jukebox/
> >>         library/artist/Foo%20Fighters
> >>
> >>
> >> I understand that in XML, the response would be
> >>
> >>
> >> 
> >>
> >>      Foo Fighters 
> >>
> >>     
> >>
> >>      (...)
> >>
> >>     
> >>
> >> 
> >>
> >>
> >>
> >> How would that be rendered in json? Should it be rendered as list? I.e.,
> >>
> >>
> >> {
> >>
> >>     "artist" : [
> >>
> >>      {
> >>
> >>       "name" : "Foo Fighters",
> >>
> >>       "album " : [
> >>
> >>                       (...)
> >>
> >>                   ]
> >>
> >>              }
> >>
> >>     ]
> >>
> >> }
> >>
> >>
> >>
> >
> > yes.
> >
> > http://www.ietf.org/id/draft-ietf-netmod-yang-json-00.txt
> >
> > see sec. 3.2.4
>
> Well, that section defines the JSON encoding for a list but here the GET
> query asks for a single list entry, which clearly is an object.
>
> I think it is up to the RESTCONF spec to define the contents of protocol
> messages, the cited draft deals with JSON encoding of repository contents.
> I can imagine that RESTCONF defines a special "response object" so that
> only the requested value is returned (without the name of the list), e.g.:
>
> "data" :
>   {
>     "name": "Foo Fighters",
>     "album": [ ...]
>   }
>
>
No -- this has been discussed before.  A YANG list is encoded as an array
even if
there is only 1 of them. There is no need for special corner cases.



> Lada
>

Andy



>
> >
> >
> > Andy
> >
> >
> >>
> >> Or render it as containers are? I.e.,
> >>
> >>
> >> {
> >>
> >>     "artist" :  {
> >>
> >>    "name" : "Foo Fighters",
> >>
> >>    "album " : [
> >>
> >>                       (...)
> >>
> >>         ]
> >>
> >>      }
> >>
> >> }
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Alberto
> >>
> >>
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> >>
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

--001a11c20e7aa1dd9304fa84af03
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Wed, May 28, 2014 at 11:40 PM, Ladislav Lhotka <lhotka@nic.cz&g=
t; wrote:


Andy Bierman <andy@yumaworks.com> writes:



> On Wed, May 28, 2014 at 4:39 PM, Alberto Gonzalez Prieto (albertgo) &l=
t;

> albertgo@cisco.com> wrote=
:

>

>> =A0 Hi,

>>

>> =A0I would appreciate clarification on how to render the response =
to =A0a GET

>> for a list entry.

>> =A0More specifically, should =A0it be rendered as a list or differ=
ently (say

>> like a container) ?

>>

>> =A0E.g.,

>>

>> GET /restconf/data/example-jukebox:jukebox/

>> =A0 =A0 =A0 =A0 library/artist/Foo%20Fighters

>>

>>

>> I understand that in XML, the response would be

>>

>>

>> <artist>

>>

>> =A0 =A0 <name> Foo Fighters </name>

>>

>> =A0 =A0 <album>

>>

>> =A0 =A0 =A0(...)

>>

>> =A0 =A0 </album>

>>

>> </artist>

>>

>>

>>

>> How would that be rendered in json? Should it be rendered as list?=
 I.e.,

>>

>>

>> {

>>

>> =A0 =A0 "artist" : [

>>

>> =A0 =A0 =A0{

>>

>> =A0 =A0 =A0 "name" : "Foo Fighters",

>>

>> =A0 =A0 =A0 "album " : [

>>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (...)

>>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ]

>>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0}

>>

>> =A0 =A0 ]

>>

>> }

>>

>>

>>

>

> yes.

>

> http://www.ietf.org/id/draft-ietf-netmod-yang-json-00.txt=


>

> see sec. 3.2.4



Well, that section defines the JSON encoding for a list but here the GET qu=
ery asks for a single list entry, which clearly is an object.



I think it is up to the RESTCONF spec to define the contents of protocol me=
ssages, the cited draft deals with JSON encoding of repository contents. I =
can imagine that RESTCONF defines a special "response object" so =
that only the requested value is returned (without the name of the list), e=
.g.:




"data" :

=A0 {

=A0 =A0 "name": "Foo Fighters",

=A0 =A0 "album": [ ...]

=A0 }



No -- this has been discussed before. =
=A0A YANG list is encoded as an array even if
there is only 1 of =
them. There is no need for special corner cases.


=A0

Lada

Andy

=A0<=
/div>



>

>

> Andy

>

>

>>

>> Or render it as containers are? I.e.,

>>

>>

>> {

>>

>> =A0 =A0 "artist" : =A0{

>>

>> =A0 =A0"name" : "Foo Fighters",

>>

>> =A0 =A0"album " : [

>>

>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (...)

>>

>> =A0 =A0 =A0 =A0 ]

>>

>> =A0 =A0 =A0}

>>

>> }

>>

>>

>>

>> Thanks,

>>

>> Alberto

>>

>>

>>

>> _______________________________________________

>> Netconf mailing list

>> Netconf@ietf.org

>> https://www.ietf.org/mailman/listinfo/netconf

>>

>>

> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org

> https://www.ietf.org/mailman/listinfo/netconf



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C





--001a11c20e7aa1dd9304fa84af03--


From nobody Thu May 29 00:24:58 2014
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 390AE1A0351 for ; Thu, 29 May 2014 00:24:55 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] 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 UuDhc9eyMO9G for ; Thu, 29 May 2014 00:24:53 -0700 (PDT)
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 313E71A02CE for ; Thu, 29 May 2014 00:24:53 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id EBD3913F97C; Thu, 29 May 2014 09:24:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401348288; bh=VYWG35LTFA9Tydun1i/CiJTxLcJdoKgM3VRQE+d14t8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nvekZXwlxD94dyVggveFzm+sx1lr3P9U5pQ6zbQ063DDdkO3ROj8XC28XW4NppEcI VGUpLYMEZw1UQI2ikr+D5Hx8C1a4vUen2HJtXuis/Gxo/5hs40uOy6ooUSZ/ZxmXf1 lJDYAtVciqW6Dze/D+uavh62FQ/lU5cV4DQwGvQE=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 29 May 2014 09:24:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <246B672D-1E2C-48DE-B736-9DAF9C05A3ED@nic.cz>
References:     
To: Andy Bierman 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/W5zwUN99AIMYY0Q-v59ZC-bO5yQ
Cc: Netconf 
Subject: Re: [Netconf] Restconf: rendering the response to a GET on a list entry in json
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 May 2014 07:24:55 -0000

On 29 May 2014, at 09:14, Andy Bierman  wrote:

>=20
>=20
>=20
> On Wed, May 28, 2014 at 11:40 PM, Ladislav Lhotka  =
wrote:
> Andy Bierman  writes:
>=20
> > On Wed, May 28, 2014 at 4:39 PM, Alberto Gonzalez Prieto (albertgo) =
<
> > albertgo@cisco.com> wrote:
> >
> >>   Hi,
> >>
> >>  I would appreciate clarification on how to render the response to  =
a GET
> >> for a list entry.
> >>  More specifically, should  it be rendered as a list or differently =
(say
> >> like a container) ?
> >>
> >>  E.g.,
> >>
> >> GET /restconf/data/example-jukebox:jukebox/
> >>         library/artist/Foo%20Fighters
> >>
> >>
> >> I understand that in XML, the response would be
> >>
> >>
> >> 
> >>
> >>      Foo Fighters 
> >>
> >>     
> >>
> >>      (...)
> >>
> >>     
> >>
> >> 
> >>
> >>
> >>
> >> How would that be rendered in json? Should it be rendered as list? =
I.e.,
> >>
> >>
> >> {
> >>
> >>     "artist" : [
> >>
> >>      {
> >>
> >>       "name" : "Foo Fighters",
> >>
> >>       "album " : [
> >>
> >>                       (...)
> >>
> >>                   ]
> >>
> >>              }
> >>
> >>     ]
> >>
> >> }
> >>
> >>
> >>
> >
> > yes.
> >
> > http://www.ietf.org/id/draft-ietf-netmod-yang-json-00.txt
> >
> > see sec. 3.2.4
>=20
> Well, that section defines the JSON encoding for a list but here the =
GET query asks for a single list entry, which clearly is an object.
>=20
> I think it is up to the RESTCONF spec to define the contents of =
protocol messages, the cited draft deals with JSON encoding of =
repository contents. I can imagine that RESTCONF defines a special =
"response object" so that only the requested value is returned (without =
the name of the list), e.g.:
>=20
> "data" :
>   {
>     "name": "Foo Fighters",
>     "album": [ ...]
>   }
>=20
>=20
> No -- this has been discussed before.  A YANG list is encoded as an =
array even if
> there is only 1 of them. There is no need for special corner cases.

If the query was

GET /restconf/data/example-jukebox:jukebox/library/artist

(asking for the entire list), an array should be sent even if it =
contains only a single entry. But the original GET already asked for a =
specific entry, and this is IMO different.

Lada=20

>=20
> =20
> Lada
>=20
> Andy
>=20
> =20
>=20
> >
> >
> > Andy
> >
> >
> >>
> >> Or render it as containers are? I.e.,
> >>
> >>
> >> {
> >>
> >>     "artist" :  {
> >>
> >>    "name" : "Foo Fighters",
> >>
> >>    "album " : [
> >>
> >>                       (...)
> >>
> >>         ]
> >>
> >>      }
> >>
> >> }
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Alberto
> >>
> >>
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> >>
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20

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





From nobody Thu May 29 04:37:48 2014
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 5B8541A008A for ; Thu, 29 May 2014 04:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFfVREyh8bI3 for ; Thu, 29 May 2014 04:37:42 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25941A009E for ; Thu, 29 May 2014 04:37:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A355B540878 for ; Thu, 29 May 2014 13:37:36 +0200 (CEST)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i40rtRJX2fiO for ; Thu, 29 May 2014 13:37:31 +0200 (CEST)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 14AF8540200 for ; Thu, 29 May 2014 13:37:30 +0200 (CEST)
From: Ladislav Lhotka 
To: Netconf 
In-Reply-To: 
References: 
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 29 May 2014 13:37:29 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/h3Lhroi1Tx1l6wLR2aM8ca8skcw
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 11:37:45 -0000

Hi,

I am moving this discussion to the NETCONF mailing list.

Andy Bierman  writes:
...
>
> I don't agree NETCONF/YANG persistence is ill-defined.
> It is not uniform. There are a few variants, identified by
> capability URIs.

I'd say persistence is at least under-defined. For example, it doesn't seem to be clear from 6241 whether candidate is persistent.

Lada

>
> The XMLCONF design team (pre-4741) tried very hard to
> get the router vendors to agree on a single transaction model
> but it was way too big a change, and (of course) each vendor
> thought their way was better, so the standard should use that.
> We ended up with 3 configuration datastores (candidate, running, startup).
> The transaction models that can be used with these datastores
> are compatible with specific router CLI architectures.
>
> Two particular vendors do not agree on how to recover
> from the "unreachable" problem.  If the operator makes
> config changes that break the connectivity to the device,
> then the device has to recover somehow.
>
>   M1: do not persist the changes until they are proven to
>         be correct.  Force the device to reboot with the saved
>         (known good) config if things go bad.
>
>   M2: persist the changes right away.  Pick some timeout
>         and if the client does not follow up with a confirmation
>         before the timeout, automatically revert to the version
>         that was running before the transaction started.
>
> RFC 6241 could be more clear on the motivation for the
> capabilities and operations that support various transaction models.
> Maybe that is what you meant by 'ill-defined'.
>
>
> Andy
>
> So the two objects controlling Notifications seem clearly configuration,
>> whether or not the setting of them persists or is lost on reboot.  You
>> could create a YANG module which controls the setting of these two
>> objects for SNMP usage but I think that even the IESG might see that
>> that is an unusual approach, as opposed to making them read-write in
>> SMI!
>>
>> When I first read the draft IESG statement, it was unclear to me whether
>> or not the authors fully understood what they had written.
>>
>> Tom Petch
>>
>> > (*1) http://www.ietf.org/iesg/statement/writable-mib-module.html
>> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
>> >
>> > Hirochika
>> >
>> >
>> > On May 27, 2014, at 3:55 AM, joel jaeggli  wrote:
>> >
>> > > yeah if you want to discuss it with the ops/management ADs and the
>> > > chairs that's fine.
>> > >
>> > > I don't think there's a reason to involve the whole iesg.
>> > >
>> > > Thanks
>> > > joel
>> > >
>> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
>> > >> js and Joel,
>> > >>
>> > >> Thank you for your comments.
>> > >>
>> > >> I agree that the IESG statement seems to be talking about
>> configuration,
>> > >> but I cannot definitely say that the objects I listed in my
>> previous E-mail
>> > >> are out of the IESG statement's scope.
>> > >>
>> > >> I think it would be better to move this issue to the IESG, but I
>> don't keep
>> > >> up the procedure.  May I, as an author of the draft, send an E-mail
>> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG chairs to
>> > >> handle it?
>> > >>
>> > >> Thank you.
>> > >> Hirochika
>> > >>
>> > >>
>> > >> On May 27, 2014, at 1:24 AM, joel jaeggli  wrote:
>> > >>
>> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
>> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli wrote:
>> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
>> > >>>>>> Asai,
>> > >>>>>>
>> > >>>>>> the IESG statement is here:
>> > >>>>>>
>> > >>>>>> http://www.ietf.org/iesg/statement/writable-mib-module.html
>> > >>>>>>
>> > >>>>>> My reading is that it specifically talks about configuration.
>> While
>> > >>>>>> the discussion started with "lets ban all write access", it may
>> be
>> > >>>>>> important to note that the final statement does not say this.
>> Hence,
>> > >>>>>> I am not sure we have to remove the MAX-ACCESS read-write.
>> > >>>>>
>> > >>>>> some of the vm options do cause me existential peril. The
>> remaining
>> > >>>>> one's however do not. so I think Juergen's assessment  is a
>> correct one.
>> > >>>>> The statement seems to be serving it's purpose!
>> >>>>
>> > >>>> Joel, can you please decrypt your message so that it becomes
>> perhaps
>> > >>>> actionable?
>> > >>>
>> > >>> I'm agreeing with you.
>> > >>>
>> > >>>> /js
>> > --
>> > Hirochika Asai , The University of Tokyo
>> >
>> > _______________________________________________
>> > OPSAWG mailing list
>> > OPSAWG@ietf.org
>> > https://www.ietf.org/mailman/listinfo/opsawg
>>
>> _______________________________________________
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
>>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

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


From nobody Thu May 29 05:31:12 2014
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 B09DA1A08DA for ; Thu, 29 May 2014 05:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KFZCSPrq5mxc for ; Thu, 29 May 2014 05:31:08 -0700 (PDT)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB8B1A0403 for ; Thu, 29 May 2014 05:31:07 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id a108so673480qge.8 for ; Thu, 29 May 2014 05:31:03 -0700 (PDT)
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=I9AA5xsL/mJcipKdncvidWZ7Dfo4ikbuUPN+OW77qX8=; b=SCI+kxjR4HRghm99d5bgrVUQHr7C55rQE2nDzUKqrjI2Dvfh1Q21wBusCPeroM4F5d xhm5US0D9YICC0iinI94P27kxC5UxF+kS8VoikOKeBuo+CEZppTwswqY2yX2LMd6lrNH t9ZM2hFvFIsW2C41SRyabJ4GUEQXhAOrptL8zim4WaXn3lBP7B1uzdV4jDbyuZSTZjys 1Sh/DxTZoaV60u04CH+8QIUTt1MHFOKHhV746dMEZH9j5NqtHxoQb/fOL84+RVBLfrcf MOYaf9r8v2TXAHPsZrRxDxYceK59EtB+kHS0WPH8XfzLs//1of1Y5y8BNwjCB7A2Asrf bQWg==
X-Gm-Message-State: ALoCoQnjy+HJw4QGORmUyEuBATJcYJyIA5unBlPhb64GwW7eFUb4s48JRkjIaX9fteixwmuo5lhY
MIME-Version: 1.0
X-Received: by 10.224.165.70 with SMTP id h6mr9679866qay.78.1401366663210; Thu, 29 May 2014 05:31:03 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 29 May 2014 05:31:03 -0700 (PDT)
In-Reply-To: 
References:  
Date: Thu, 29 May 2014 05:31:03 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e0149c3a4293bfd04fa891a8b
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eAAfZ5GBQbOaM348JZoaeTnTMGE
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 12:31:10 -0000

--089e0149c3a4293bfd04fa891a8b
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka  wrote:

> Hi,
>
> I am moving this discussion to the NETCONF mailing list.
>
> Andy Bierman  writes:
> ...
> >
> > I don't agree NETCONF/YANG persistence is ill-defined.
> > It is not uniform. There are a few variants, identified by
> > capability URIs.
>
> I'd say persistence is at least under-defined. For example, it doesn't
> seem to be clear from 6241 whether candidate is persistent.
>
>
OK

sec 8.3.5.2 says:

   When a client fails with outstanding changes to the candidate
   configuration, recovery can be difficult.  To facilitate easy
   recovery, any outstanding changes are discarded when the lock is
   released, whether explicitly with the  operation or
   implicitly from session failure.

IMO it is odd that candidate is cleaned up only if it was locked.
If a client edits candidate and then closes the session somehow the changes
are left behind.
The RFC is silent about the contents of candidate at boot-time. Our server
always boots
with the candidate and running having the same contents.  Otherwise the
candidate is
dirty at boot-time and cannot be locked by any session until a
discard-changes is invoked.
There is also no explicit requirement to boot with any particular candidate
contents, so
booting with the contents of running is compliant.



> Lada
>

Andy


>
> >
> > The XMLCONF design team (pre-4741) tried very hard to
> > get the router vendors to agree on a single transaction model
> > but it was way too big a change, and (of course) each vendor
> > thought their way was better, so the standard should use that.
> > We ended up with 3 configuration datastores (candidate, running,
> startup).
> > The transaction models that can be used with these datastores
> > are compatible with specific router CLI architectures.
> >
> > Two particular vendors do not agree on how to recover
> > from the "unreachable" problem.  If the operator makes
> > config changes that break the connectivity to the device,
> > then the device has to recover somehow.
> >
> >   M1: do not persist the changes until they are proven to
> >         be correct.  Force the device to reboot with the saved
> >         (known good) config if things go bad.
> >
> >   M2: persist the changes right away.  Pick some timeout
> >         and if the client does not follow up with a confirmation
> >         before the timeout, automatically revert to the version
> >         that was running before the transaction started.
> >
> > RFC 6241 could be more clear on the motivation for the
> > capabilities and operations that support various transaction models.
> > Maybe that is what you meant by 'ill-defined'.
> >
> >
> > Andy
> >
> > So the two objects controlling Notifications seem clearly configuration,
> >> whether or not the setting of them persists or is lost on reboot.  You
> >> could create a YANG module which controls the setting of these two
> >> objects for SNMP usage but I think that even the IESG might see that
> >> that is an unusual approach, as opposed to making them read-write in
> >> SMI!
> >>
> >> When I first read the draft IESG statement, it was unclear to me whether
> >> or not the authors fully understood what they had written.
> >>
> >> Tom Petch
> >>
> >> > (*1) http://www.ietf.org/iesg/statement/writable-mib-module.html
> >> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> >> >
> >> > Hirochika
> >> >
> >> >
> >> > On May 27, 2014, at 3:55 AM, joel jaeggli  wrote:
> >> >
> >> > > yeah if you want to discuss it with the ops/management ADs and the
> >> > > chairs that's fine.
> >> > >
> >> > > I don't think there's a reason to involve the whole iesg.
> >> > >
> >> > > Thanks
> >> > > joel
> >> > >
> >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> >> > >> js and Joel,
> >> > >>
> >> > >> Thank you for your comments.
> >> > >>
> >> > >> I agree that the IESG statement seems to be talking about
> >> configuration,
> >> > >> but I cannot definitely say that the objects I listed in my
> >> previous E-mail
> >> > >> are out of the IESG statement's scope.
> >> > >>
> >> > >> I think it would be better to move this issue to the IESG, but I
> >> don't keep
> >> > >> up the procedure.  May I, as an author of the draft, send an E-mail
> >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG chairs to
> >> > >> handle it?
> >> > >>
> >> > >> Thank you.
> >> > >> Hirochika
> >> > >>
> >> > >>
> >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli 
> wrote:
> >> > >>
> >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli wrote:
> >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> >> > >>>>>> Asai,
> >> > >>>>>>
> >> > >>>>>> the IESG statement is here:
> >> > >>>>>>
> >> > >>>>>> http://www.ietf.org/iesg/statement/writable-mib-module.html
> >> > >>>>>>
> >> > >>>>>> My reading is that it specifically talks about configuration.
> >> While
> >> > >>>>>> the discussion started with "lets ban all write access", it may
> >> be
> >> > >>>>>> important to note that the final statement does not say this.
> >> Hence,
> >> > >>>>>> I am not sure we have to remove the MAX-ACCESS read-write.
> >> > >>>>>
> >> > >>>>> some of the vm options do cause me existential peril. The
> >> remaining
> >> > >>>>> one's however do not. so I think Juergen's assessment  is a
> >> correct one.
> >> > >>>>> The statement seems to be serving it's purpose!
> >> >>>>
> >> > >>>> Joel, can you please decrypt your message so that it becomes
> >> perhaps
> >> > >>>> actionable?
> >> > >>>
> >> > >>> I'm agreeing with you.
> >> > >>>
> >> > >>>> /js
> >> > --
> >> > Hirochika Asai , The University of Tokyo
> >> >
> >> > _______________________________________________
> >> > OPSAWG mailing list
> >> > OPSAWG@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >> _______________________________________________
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--089e0149c3a4293bfd04fa891a8b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:


Hi,



I am moving this discussion to the NETCONF mailing list.



Andy Bierman <andy@yumaworks.com> writes:

...

>

> I don't agree NETCONF/YANG persistence is ill-defined.

> It is not uniform. There are a few variants, identified by

> capability URIs.



I'd say persistence is at least under-defined. For example, it doesn=
9;t seem to be clear from 6241 whether candidate is persistent.





   When a client fails with outstanding changes =
to the candidate
   configuration, recovery can be difficult.  To facilitate easy
   recovery, any outstanding changes are discarded when the lock is
   released, whether explicitly with the <unlock> operation or
   implicitly from session failure.


The RFC is silent about the contents of candidate at boot-time. Our se=
rver always boots
with the candidate and running having the same =
contents. =A0Otherwise the candidate is
dirty at boot-time and ca=
nnot be locked by any session until a discard-changes is invoked.


There is also no explicit requirement to boot with any particular cand=
idate contents, so
booting with the contents of running is compli=
ant.

=A0


Lada

Andy
=A0




>

> The XMLCONF design team (pre-4741) tried very hard to

> get the router vendors to agree on a single transaction model

> but it was way too big a change, and (of course) each vendor

> thought their way was better, so the standard should use that.

> We ended up with 3 configuration datastores (candidate, running, start=
up).

> The transaction models that can be used with these datastores

> are compatible with specific router CLI architectures.

>

> Two particular vendors do not agree on how to recover

> from the "unreachable" problem. =A0If the operator makes

> config changes that break the connectivity to the device,

> then the device has to recover somehow.

>

> =A0 M1: do not persist the changes until they are proven to

> =A0 =A0 =A0 =A0 be correct. =A0Force the device to reboot with the sav=
ed

> =A0 =A0 =A0 =A0 (known good) config if things go bad.

>

> =A0 M2: persist the changes right away. =A0Pick some timeout

> =A0 =A0 =A0 =A0 and if the client does not follow up with a confirmati=
on

> =A0 =A0 =A0 =A0 before the timeout, automatically revert to the versio=
n

> =A0 =A0 =A0 =A0 that was running before the transaction started.

>

> RFC 6241 could be more clear on the motivation for the

> capabilities and operations that support various transaction models.
> Maybe that is what you meant by 'ill-defined'.

>

>

> Andy

>

> So the two objects controlling Notifications seem clearly configuratio=
n,

>> whether or not the setting of them persists or is lost on reboot. =
=A0You

>> could create a YANG module which controls the setting of these two=


>> objects for SNMP usage but I think that even the IESG might see th=
at

>> that is an unusual approach, as opposed to making them read-write =
in

>> SMI!

>>

>> When I first read the draft IESG statement, it was unclear to me w=
hether

>> or not the authors fully understood what they had written.

>>

>> Tom Petch

>>

>> > (*1) http://www.ietf.org/iesg/statement/writab=
le-mib-module.html

>> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-=
vmm-mib-00

>> >

>> > Hirochika

>> >

>> >

>> > On May 27, 2014, at 3:55 AM, joel jaeggli <joelja@bogus.com> wrote:

>> >

>> > > yeah if you want to discuss it with the ops/management A=
Ds and the

>> > > chairs that's fine.

>> > >

>> > > I don't think there's a reason to involve the wh=
ole iesg.

>> > >

>> > > Thanks

>> > > joel

>> > >

>> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:

>> > >> js and Joel,

>> > >>

>> > >> Thank you for your comments.

>> > >>

>> > >> I agree that the IESG statement seems to be talking =
about

>> configuration,

>> > >> but I cannot definitely say that the objects I liste=
d in my

>> previous E-mail

>> > >> are out of the IESG statement's scope.

>> > >>

>> > >> I think it would be better to move this issue to the=
 IESG, but I

>> don't keep

>> > >> up the procedure. =A0May I, as an author of the draf=
t, send an E-mail

>> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG chairs to

>> > >> handle it?

>> > >>

>> > >> Thank you.

>> > >> Hirochika

>> > >>

>> > >>

>> > >> On May 27, 2014, at 1:24 AM, joel jaeggli <joelja@bogus.com> wrote:

>> > >>

>> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote=
:

>> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, jo=
el jaeggli wrote:

>> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaeld=
er wrote:

>> > >>>>>> Asai,

>> > >>>>>>

>> > >>>>>> the IESG statement is here:

>> > >>>>>>

>> > >>>>>> http://www.ietf.org/i=
esg/statement/writable-mib-module.html

>> > >>>>>>

>> > >>>>>> My reading is that it specifically t=
alks about configuration.

>> While

>> > >>>>>> the discussion started with "le=
ts ban all write access", it may

>> be

>> > >>>>>> important to note that the final sta=
tement does not say this.

>> Hence,

>> > >>>>>> I am not sure we have to remove the =
MAX-ACCESS read-write.

>> > >>>>>

>> > >>>>> some of the vm options do cause me exist=
ential peril. The

>> remaining

>> > >>>>> one's however do not. so I think Jue=
rgen's assessment =A0is a

>> correct one.

>> > >>>>> The statement seems to be serving it'=
;s purpose!

>> >>>>

>> > >>>> Joel, can you please decrypt your message so=
 that it becomes

>> perhaps

>> > >>>> actionable?

>> > >>>

>> > >>> I'm agreeing with you.

>> > >>>

>> > >>>> /js

>> > --

>> > Hirochika Asai <=
panda@hongo.wide.ad.jp>, The University of Tokyo

>> >

>> > _______________________________________________

>> > OPSAWG mailing list

>> > OPSAWG@ietf.org

>> > https://www.ietf.org/mailman/listinfo/opsawg

>>

>> _______________________________________________

>> OPSAWG mailing list

>> OPSAWG@ietf.org

>> https://www.ietf.org/mailman/listinfo/opsawg

>>

> _______________________________________________

> OPSAWG mailing list

> OPSAWG@ietf.org

> https://www.ietf.org/mailman/listinfo/opsawg



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C



_______________________________________________

Netconf mailing list

Netconf@ietf.org

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





--089e0149c3a4293bfd04fa891a8b--


From nobody Thu May 29 06:16:44 2014
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 83D7C1A08F9 for ; Thu, 29 May 2014 06:16:42 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] 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 NTrRaY1ianYA for ; Thu, 29 May 2014 06:16:40 -0700 (PDT)
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 B30161A08EB for ; Thu, 29 May 2014 06:16:39 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8F0C313F976; Thu, 29 May 2014 15:16:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401369393; bh=FTbxU2jKlbXRBil+cmzggR5aDtY598ThR4/9X1t99zw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lJs/NgNXQu9Yveu0IWoE79ZTPD54uB7XUesY3nKMwbMiBntYk4zCuj/CmMylfak7c O/oFhnnJSacvmfVkQOkOaIi1W830LusV9RIdlV4vvS5a9+MP45h3WnCHrnkCBtyw23 wMKVzyusFgrqnu+SxHvudyQC5QmVC15F0yDsKUyI=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 29 May 2014 15:16:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4987B7A3-DA0A-4145-A080-F1AC1BE466E2@nic.cz>
References:   
To: Andy Bierman 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/TJvPe4R9mxI5-smsRGuxEy9EQMc
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 13:16:42 -0000

On 29 May 2014, at 14:31, Andy Bierman  wrote:

>=20
>=20
>=20
> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka  =
wrote:
> Hi,
>=20
> I am moving this discussion to the NETCONF mailing list.
>=20
> Andy Bierman  writes:
> ...
> >
> > I don't agree NETCONF/YANG persistence is ill-defined.
> > It is not uniform. There are a few variants, identified by
> > capability URIs.
>=20
> I'd say persistence is at least under-defined. For example, it doesn't =
seem to be clear from 6241 whether candidate is persistent.
>=20
>=20
> OK
>=20
> sec 8.3.5.2 says:
>=20
>    When a client fails with outstanding changes to the candidate
>    configuration, recovery can be difficult.  To facilitate easy
>    recovery, any outstanding changes are discarded when the lock is
>    released, whether explicitly with the  operation or
>  =20
>  implicitly from session failure.
> IMO it is odd that candidate is cleaned up only if it was locked.
> If a client edits candidate and then closes the session somehow the =
changes are left behind.
> The RFC is silent about the contents of candidate at boot-time. Our =
server always boots
> with the candidate and running having the same contents.  Otherwise =
the candidate is
> dirty at boot-time and cannot be locked by any session until a =
discard-changes is invoked.
> There is also no explicit requirement to boot with any particular =
candidate contents, so
> booting with the contents of running is compliant.

I think an alternative interpretation of the 6241 text is that candidate =
is a persistent staging area that survives reboots and is only reverted =
to running after discard-changes. So a client can close a session, then =
later open a new one and start editing where he left off.=20

Lada

>=20
> =20
> Lada
>=20
> Andy
> =20
>=20
> >
> > The XMLCONF design team (pre-4741) tried very hard to
> > get the router vendors to agree on a single transaction model
> > but it was way too big a change, and (of course) each vendor
> > thought their way was better, so the standard should use that.
> > We ended up with 3 configuration datastores (candidate, running, =
startup).
> > The transaction models that can be used with these datastores
> > are compatible with specific router CLI architectures.
> >
> > Two particular vendors do not agree on how to recover
> > from the "unreachable" problem.  If the operator makes
> > config changes that break the connectivity to the device,
> > then the device has to recover somehow.
> >
> >   M1: do not persist the changes until they are proven to
> >         be correct.  Force the device to reboot with the saved
> >         (known good) config if things go bad.
> >
> >   M2: persist the changes right away.  Pick some timeout
> >         and if the client does not follow up with a confirmation
> >         before the timeout, automatically revert to the version
> >         that was running before the transaction started.
> >
> > RFC 6241 could be more clear on the motivation for the
> > capabilities and operations that support various transaction models.
> > Maybe that is what you meant by 'ill-defined'.
> >
> >
> > Andy
> >
> > So the two objects controlling Notifications seem clearly =
configuration,
> >> whether or not the setting of them persists or is lost on reboot.  =
You
> >> could create a YANG module which controls the setting of these two
> >> objects for SNMP usage but I think that even the IESG might see =
that
> >> that is an unusual approach, as opposed to making them read-write =
in
> >> SMI!
> >>
> >> When I first read the draft IESG statement, it was unclear to me =
whether
> >> or not the authors fully understood what they had written.
> >>
> >> Tom Petch
> >>
> >> > (*1) http://www.ietf.org/iesg/statement/writable-mib-module.html
> >> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> >> >
> >> > Hirochika
> >> >
> >> >
> >> > On May 27, 2014, at 3:55 AM, joel jaeggli  =
wrote:
> >> >
> >> > > yeah if you want to discuss it with the ops/management ADs and =
the
> >> > > chairs that's fine.
> >> > >
> >> > > I don't think there's a reason to involve the whole iesg.
> >> > >
> >> > > Thanks
> >> > > joel
> >> > >
> >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> >> > >> js and Joel,
> >> > >>
> >> > >> Thank you for your comments.
> >> > >>
> >> > >> I agree that the IESG statement seems to be talking about
> >> configuration,
> >> > >> but I cannot definitely say that the objects I listed in my
> >> previous E-mail
> >> > >> are out of the IESG statement's scope.
> >> > >>
> >> > >> I think it would be better to move this issue to the IESG, but =
I
> >> don't keep
> >> > >> up the procedure.  May I, as an author of the draft, send an =
E-mail
> >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG =
chairs to
> >> > >> handle it?
> >> > >>
> >> > >> Thank you.
> >> > >> Hirochika
> >> > >>
> >> > >>
> >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli  =
wrote:
> >> > >>
> >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli =
wrote:
> >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> >> > >>>>>> Asai,
> >> > >>>>>>
> >> > >>>>>> the IESG statement is here:
> >> > >>>>>>
> >> > >>>>>> =
http://www.ietf.org/iesg/statement/writable-mib-module.html
> >> > >>>>>>
> >> > >>>>>> My reading is that it specifically talks about =
configuration.
> >> While
> >> > >>>>>> the discussion started with "lets ban all write access", =
it may
> >> be
> >> > >>>>>> important to note that the final statement does not say =
this.
> >> Hence,
> >> > >>>>>> I am not sure we have to remove the MAX-ACCESS read-write.
> >> > >>>>>
> >> > >>>>> some of the vm options do cause me existential peril. The
> >> remaining
> >> > >>>>> one's however do not. so I think Juergen's assessment  is a
> >> correct one.
> >> > >>>>> The statement seems to be serving it's purpose!
> >> >>>>
> >> > >>>> Joel, can you please decrypt your message so that it becomes
> >> perhaps
> >> > >>>> actionable?
> >> > >>>
> >> > >>> I'm agreeing with you.
> >> > >>>
> >> > >>>> /js
> >> > --
> >> > Hirochika Asai , The University of Tokyo
> >> >
> >> > _______________________________________________
> >> > OPSAWG mailing list
> >> > OPSAWG@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/opsawg
> >>
> >> _______________________________________________
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>=20

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





From nobody Thu May 29 08:36:00 2014
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 879E11A6F85 for ; Thu, 29 May 2014 08:35:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4iYEVr1B7Hr8 for ; Thu, 29 May 2014 08:35:47 -0700 (PDT)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F72E1A03C6 for ; Thu, 29 May 2014 08:35:47 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id q107so1493821qgd.29 for ; Thu, 29 May 2014 08:35:43 -0700 (PDT)
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=BT/if/udEPhW8jBlW+1Ra9mJ5PqvL7ivexYqX6TFSdM=; b=N7SL82+0/YeL6Hp2pyK+P7Vs5qOBQH/wMgUAn+/uk9f3xCz+ALMNW62dVU+S+6NsZA qzru8zdVPefdetwqxGRJbVPlZhg1by4MJG3cZok7DlcWHKrCoaYzh8Sjdo4xdkWm6Lra k6cexw/6Gggn+7xdAlFZnEZxRFisIl/ev6FW58FAKyeu9iwji6dS4YHBTi0KOvKH+RTX NDoDIfWqgFhg1sHd2f1geGtl9M90a6A8AzYLRAep5R6zZK3cODW/oSvLy+1qbadJthL9 jPd8gtzP9S5Y/OhLIRNzK1PU2JBLMAXnQnuv20RIox+4v/I/8QaILVVkuQbmwMy3AmWo AN3Q==
X-Gm-Message-State: ALoCoQngKgZOl7+iL3Ly9OqFn2IdbVMueBEyTUT00Ndjdej1GqLJPXjDWx4c9U1/5kkO0BMB7xBN
MIME-Version: 1.0
X-Received: by 10.140.104.204 with SMTP id a70mr10388815qgf.91.1401377742970;  Thu, 29 May 2014 08:35:42 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Thu, 29 May 2014 08:35:42 -0700 (PDT)
In-Reply-To: <4987B7A3-DA0A-4145-A080-F1AC1BE466E2@nic.cz>
References:    <4987B7A3-DA0A-4145-A080-F1AC1BE466E2@nic.cz>
Date: Thu, 29 May 2014 08:35:42 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a1134f42a910f1f04fa8bae77
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/J5OoY8rmisrjSUxsKk7sO3l12P8
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 15:35:50 -0000

--001a1134f42a910f1f04fa8bae77
Content-Type: text/plain; charset=ISO-8859-1

On Thu, May 29, 2014 at 6:16 AM, Ladislav Lhotka  wrote:

>
> On 29 May 2014, at 14:31, Andy Bierman  wrote:
>
> >
> >
> >
> > On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka  wrote:
> > Hi,
> >
> > I am moving this discussion to the NETCONF mailing list.
> >
> > Andy Bierman  writes:
> > ...
> > >
> > > I don't agree NETCONF/YANG persistence is ill-defined.
> > > It is not uniform. There are a few variants, identified by
> > > capability URIs.
> >
> > I'd say persistence is at least under-defined. For example, it doesn't
> seem to be clear from 6241 whether candidate is persistent.
> >
> >
> > OK
> >
> > sec 8.3.5.2 says:
> >
> >    When a client fails with outstanding changes to the candidate
> >    configuration, recovery can be difficult.  To facilitate easy
> >    recovery, any outstanding changes are discarded when the lock is
> >    released, whether explicitly with the  operation or
> >
> >  implicitly from session failure.
> > IMO it is odd that candidate is cleaned up only if it was locked.
> > If a client edits candidate and then closes the session somehow the
> changes are left behind.
> > The RFC is silent about the contents of candidate at boot-time. Our
> server always boots
> > with the candidate and running having the same contents.  Otherwise the
> candidate is
> > dirty at boot-time and cannot be locked by any session until a
> discard-changes is invoked.
> > There is also no explicit requirement to boot with any particular
> candidate contents, so
> > booting with the contents of running is compliant.
>
> I think an alternative interpretation of the 6241 text is that candidate
> is a persistent staging area that survives reboots and is only reverted to
> running after discard-changes. So a client can close a session, then later
> open a new one and start editing where he left off.
>
>

There is no text that says anything about the initial state of candidate.
Does any known implementation behave this way?
(Note that the shared candidate is a horrible place to toss some edits
and come back later to finish up.  The shared candidate is not really
intended to left unlocked so partial edits from various clients can
accumulate.)


Lada
>
>
Andy


> >
> >
> > Lada
> >
> > Andy
> >
> >
> > >
> > > The XMLCONF design team (pre-4741) tried very hard to
> > > get the router vendors to agree on a single transaction model
> > > but it was way too big a change, and (of course) each vendor
> > > thought their way was better, so the standard should use that.
> > > We ended up with 3 configuration datastores (candidate, running,
> startup).
> > > The transaction models that can be used with these datastores
> > > are compatible with specific router CLI architectures.
> > >
> > > Two particular vendors do not agree on how to recover
> > > from the "unreachable" problem.  If the operator makes
> > > config changes that break the connectivity to the device,
> > > then the device has to recover somehow.
> > >
> > >   M1: do not persist the changes until they are proven to
> > >         be correct.  Force the device to reboot with the saved
> > >         (known good) config if things go bad.
> > >
> > >   M2: persist the changes right away.  Pick some timeout
> > >         and if the client does not follow up with a confirmation
> > >         before the timeout, automatically revert to the version
> > >         that was running before the transaction started.
> > >
> > > RFC 6241 could be more clear on the motivation for the
> > > capabilities and operations that support various transaction models.
> > > Maybe that is what you meant by 'ill-defined'.
> > >
> > >
> > > Andy
> > >
> > > So the two objects controlling Notifications seem clearly
> configuration,
> > >> whether or not the setting of them persists or is lost on reboot.  You
> > >> could create a YANG module which controls the setting of these two
> > >> objects for SNMP usage but I think that even the IESG might see that
> > >> that is an unusual approach, as opposed to making them read-write in
> > >> SMI!
> > >>
> > >> When I first read the draft IESG statement, it was unclear to me
> whether
> > >> or not the authors fully understood what they had written.
> > >>
> > >> Tom Petch
> > >>
> > >> > (*1) http://www.ietf.org/iesg/statement/writable-mib-module.html
> > >> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> > >> >
> > >> > Hirochika
> > >> >
> > >> >
> > >> > On May 27, 2014, at 3:55 AM, joel jaeggli  wrote:
> > >> >
> > >> > > yeah if you want to discuss it with the ops/management ADs and the
> > >> > > chairs that's fine.
> > >> > >
> > >> > > I don't think there's a reason to involve the whole iesg.
> > >> > >
> > >> > > Thanks
> > >> > > joel
> > >> > >
> > >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> > >> > >> js and Joel,
> > >> > >>
> > >> > >> Thank you for your comments.
> > >> > >>
> > >> > >> I agree that the IESG statement seems to be talking about
> > >> configuration,
> > >> > >> but I cannot definitely say that the objects I listed in my
> > >> previous E-mail
> > >> > >> are out of the IESG statement's scope.
> > >> > >>
> > >> > >> I think it would be better to move this issue to the IESG, but I
> > >> don't keep
> > >> > >> up the procedure.  May I, as an author of the draft, send an
> E-mail
> > >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG chairs
> to
> > >> > >> handle it?
> > >> > >>
> > >> > >> Thank you.
> > >> > >> Hirochika
> > >> > >>
> > >> > >>
> > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli 
> wrote:
> > >> > >>
> > >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> > >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli wrote:
> > >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> > >> > >>>>>> Asai,
> > >> > >>>>>>
> > >> > >>>>>> the IESG statement is here:
> > >> > >>>>>>
> > >> > >>>>>> http://www.ietf.org/iesg/statement/writable-mib-module.html
> > >> > >>>>>>
> > >> > >>>>>> My reading is that it specifically talks about configuration.
> > >> While
> > >> > >>>>>> the discussion started with "lets ban all write access", it
> may
> > >> be
> > >> > >>>>>> important to note that the final statement does not say this.
> > >> Hence,
> > >> > >>>>>> I am not sure we have to remove the MAX-ACCESS read-write.
> > >> > >>>>>
> > >> > >>>>> some of the vm options do cause me existential peril. The
> > >> remaining
> > >> > >>>>> one's however do not. so I think Juergen's assessment  is a
> > >> correct one.
> > >> > >>>>> The statement seems to be serving it's purpose!
> > >> >>>>
> > >> > >>>> Joel, can you please decrypt your message so that it becomes
> > >> perhaps
> > >> > >>>> actionable?
> > >> > >>>
> > >> > >>> I'm agreeing with you.
> > >> > >>>
> > >> > >>>> /js
> > >> > --
> > >> > Hirochika Asai , The University of Tokyo
> > >> >
> > >> > _______________________________________________
> > >> > OPSAWG mailing list
> > >> > OPSAWG@ietf.org
> > >> > https://www.ietf.org/mailman/listinfo/opsawg
> > >>
> > >> _______________________________________________
> > >> OPSAWG mailing list
> > >> OPSAWG@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/opsawg
> > >>
> > > _______________________________________________
> > > OPSAWG mailing list
> > > OPSAWG@ietf.org
> > > https://www.ietf.org/mailman/listinfo/opsawg
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a1134f42a910f1f04fa8bae77
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Thu, May 29, 2014 at 6:16 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:




On 29 May 2014, at 14:31, Andy Bierman <andy@yumaworks.com> wrote:



>

>

>

> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Hi,

>

> I am moving this discussion to the NETCONF mailing list.

>

> Andy Bierman <andy@yumaworks.=
com> writes:

> ...

> >

> > I don't agree NETCONF/YANG persistence is ill-defined.

> > It is not uniform. There are a few variants, identified by

> > capability URIs.

>

> I'd say persistence is at least under-defined. For example, it doe=
sn't seem to be clear from 6241 whether candidate is persistent.

>

>

> OK

>

> sec 8.3.5.2 says:

>

> =A0 =A0When a client fails with outstanding changes to the candidate
> =A0 =A0configuration, recovery can be difficult. =A0To facilitate easy=


> =A0 =A0recovery, any outstanding changes are discarded when the lock i=
s

> =A0 =A0released, whether explicitly with the <unlock> operation =
or

>

> =A0implicitly from session failure.

> IMO it is odd that candidate is cleaned up only if it was locked.

> If a client edits candidate and then closes the session somehow the ch=
anges are left behind.

> The RFC is silent about the contents of candidate at boot-time. Our se=
rver always boots

> with the candidate and running having the same contents. =A0Otherwise =
the candidate is

> dirty at boot-time and cannot be locked by any session until a discard=
-changes is invoked.

> There is also no explicit requirement to boot with any particular cand=
idate contents, so

> booting with the contents of running is compliant.



I think an alternative interpretation of the 6241 text is that candidate is=
 a persistent staging area that survives reboots and is only reverted to ru=
nning after discard-changes. So a client can close a session, then later op=
en a new one and start editing where he left off.





There is no text that s=
ays anything about the initial state of candidate.
Does any known=
 implementation behave this way?
(Note that the shared candidate =
is a horrible place to toss some edits


and come back later to finish up. =A0The shared candidate is not reall=
y
intended to left unlocked so partial edits from various clients=
 can accumulate.)




Lada



Andy
=A0

>

>

> Lada

>

> Andy

>

>

> >

> > The XMLCONF design team (pre-4741) tried very hard to

> > get the router vendors to agree on a single transaction model

> > but it was way too big a change, and (of course) each vendor

> > thought their way was better, so the standard should use that.
> > We ended up with 3 configuration datastores (candidate, running, =
startup).

> > The transaction models that can be used with these datastores

> > are compatible with specific router CLI architectures.

> >

> > Two particular vendors do not agree on how to recover

> > from the "unreachable" problem. =A0If the operator make=
s

> > config changes that break the connectivity to the device,

> > then the device has to recover somehow.

> >

> > =A0 M1: do not persist the changes until they are proven to

> > =A0 =A0 =A0 =A0 be correct. =A0Force the device to reboot with th=
e saved

> > =A0 =A0 =A0 =A0 (known good) config if things go bad.

> >

> > =A0 M2: persist the changes right away. =A0Pick some timeout

> > =A0 =A0 =A0 =A0 and if the client does not follow up with a confi=
rmation

> > =A0 =A0 =A0 =A0 before the timeout, automatically revert to the v=
ersion

> > =A0 =A0 =A0 =A0 that was running before the transaction started.<=
br>
> >

> > RFC 6241 could be more clear on the motivation for the

> > capabilities and operations that support various transaction mode=
ls.

> > Maybe that is what you meant by 'ill-defined'.

> >

> >

> > Andy

> >

> > So the two objects controlling Notifications seem clearly configu=
ration,

> >> whether or not the setting of them persists or is lost on reb=
oot. =A0You

> >> could create a YANG module which controls the setting of thes=
e two

> >> objects for SNMP usage but I think that even the IESG might s=
ee that

> >> that is an unusual approach, as opposed to making them read-w=
rite in

> >> SMI!

> >>

> >> When I first read the draft IESG statement, it was unclear to=
 me whether

> >> or not the authors fully understood what they had written.
> >>

> >> Tom Petch

> >>

> >> > (*1) http://www.ietf.org/iesg/statement/w=
ritable-mib-module.html

> >> > (*2) http://tools.ietf.org/html/draft-ietf-op=
sawg-vmm-mib-00

> >> >

> >> > Hirochika

> >> >

> >> >

> >> > On May 27, 2014, at 3:55 AM, joel jaeggli <joelja@bogus.com> wrote:

> >> >

> >> > > yeah if you want to discuss it with the ops/managem=
ent ADs and the

> >> > > chairs that's fine.

> >> > >

> >> > > I don't think there's a reason to involve t=
he whole iesg.

> >> > >

> >> > > Thanks

> >> > > joel

> >> > >

> >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:

> >> > >> js and Joel,

> >> > >>

> >> > >> Thank you for your comments.

> >> > >>

> >> > >> I agree that the IESG statement seems to be tal=
king about

> >> configuration,

> >> > >> but I cannot definitely say that the objects I =
listed in my

> >> previous E-mail

> >> > >> are out of the IESG statement's scope.

> >> > >>

> >> > >> I think it would be better to move this issue t=
o the IESG, but I

> >> don't keep

> >> > >> up the procedure. =A0May I, as an author of the=
 draft, send an E-mail

> >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG chairs to

> >> > >> handle it?

> >> > >>

> >> > >> Thank you.

> >> > >> Hirochika

> >> > >>

> >> > >>

> >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli <<=
a href=3D"mailto:joelja@bogus.com">joelja@bogus.com> wrote:

> >> > >>

> >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder =
wrote:

> >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -070=
0, joel jaeggli wrote:

> >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoen=
waelder wrote:

> >> > >>>>>> Asai,

> >> > >>>>>>

> >> > >>>>>> the IESG statement is here:

> >> > >>>>>>

> >> > >>>>>> http://www.ietf.=
org/iesg/statement/writable-mib-module.html

> >> > >>>>>>

> >> > >>>>>> My reading is that it specifica=
lly talks about configuration.

> >> While

> >> > >>>>>> the discussion started with &qu=
ot;lets ban all write access", it may

> >> be

> >> > >>>>>> important to note that the fina=
l statement does not say this.

> >> Hence,

> >> > >>>>>> I am not sure we have to remove=
 the MAX-ACCESS read-write.

> >> > >>>>>

> >> > >>>>> some of the vm options do cause me =
existential peril. The

> >> remaining

> >> > >>>>> one's however do not. so I thin=
k Juergen's assessment =A0is a

> >> correct one.

> >> > >>>>> The statement seems to be serving i=
t's purpose!

> >> >>>>

> >> > >>>> Joel, can you please decrypt your messa=
ge so that it becomes

> >> perhaps

> >> > >>>> actionable?

> >> > >>>

> >> > >>> I'm agreeing with you.

> >> > >>>

> >> > >>>> /js

> >> > --

> >> > Hirochika Asai <panda@hongo.wide.ad.jp>, The University of Tokyo

> >> >

> >> > _______________________________________________

> >> > OPSAWG mailing list

> >> > OPSAWG@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/opsawg

> >>

> >> _______________________________________________

> >> OPSAWG mailing list

> >> OPSAWG@ietf.org

> >> https://www.ietf.org/mailman/listinfo/opsawg

> >>

> > _______________________________________________

> > OPSAWG mailing list

> > OPSAWG@ietf.org

> > https://www.ietf.org/mailman/listinfo/opsawg

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>

> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org

> https://www.ietf.org/mailman/listinfo/netconf

>



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a1134f42a910f1f04fa8bae77--


From nobody Fri May 30 03:37:19 2014
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 DB1BA1A0895 for ; Fri, 30 May 2014 03:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBsAEoIkEbVs for ; Fri, 30 May 2014 03:37:14 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0083.outbound.protection.outlook.com [213.199.154.83]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECCD1A089E for ; Fri, 30 May 2014 03:37:13 -0700 (PDT)
Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 30 May 2014 10:37:06 +0000
Message-ID: <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Andy Bierman , Ladislav Lhotka 
References:   
Date: Fri, 30 May 2014 11:34:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.165]
X-ClientProxiedBy: AM3PR07CA0028.eurprd07.prod.outlook.com (10.141.45.156) To AMXPR07MB054.eurprd07.prod.outlook.com (10.242.67.143)
X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
X-Forefront-PRVS: 02272225C5
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(51444003)(24454002)(13464003)(479174003)(189002)(199002)(377454003)(51704005)(87286001)(87976001)(74662001)(44736004)(85852003)(77982001)(92726001)(89996001)(83072002)(4396001)(92566001)(74502001)(15202345003)(76482001)(83322001)(19580395003)(50226001)(19580405001)(77156001)(64706001)(81816999)(81686999)(50986999)(76176999)(99396002)(81542001)(102836001)(21056001)(42186004)(81342001)(79102001)(33646001)(551934003)(47776003)(44716002)(62236002)(20776003)(14496001)(101416001)(15975445006)(84392001)(46102001)(88136002)(104166001)(80022001)(61296002)(62966002)(50466002)(575784001)(66066001)(23756003)(31966008)(86362001)(93916002)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR07MB054; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/KkjWADxFrpV95Q9kksStiMxsrEo
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 10:37:18 -0000

----- Original Message -----
From: "Andy Bierman" 
To: "Ladislav Lhotka" 
Cc: "Netconf" 
Sent: Thursday, May 29, 2014 1:31 PM
> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka 
wrote:
>
> > Hi,
> >
> > I am moving this discussion to the NETCONF mailing list.
> >
> > Andy Bierman  writes:
> > ...
> > >
> > > I don't agree NETCONF/YANG persistence is ill-defined.
> > > It is not uniform. There are a few variants, identified by
> > > capability URIs.
> >
> > I'd say persistence is at least under-defined. For example, it
doesn't
> > seem to be clear from 6241 whether candidate is persistent.
> >
> >
> OK

Andy

I am happy to characterise it as under-defined rather that ill-defined,
but I think that the RFC are lacking.   We did have this discussion a
few months back, and my point then was that if the only configuration
datastore is running, then the assumption by implementers was that any
change to it would immediately be persistent.  Seems reasonable, but not
specified anywhere, and since running then has the opposite semantics
with startup alongside it, well, that makes it less clearly defined, for
me.

As Lada points out, that is not the only such under-definition.

Tom Petch

> sec 8.3.5.2 says:
>
>    When a client fails with outstanding changes to the candidate
>    configuration, recovery can be difficult.  To facilitate easy
>    recovery, any outstanding changes are discarded when the lock is
>    released, whether explicitly with the  operation or
>    implicitly from session failure.
>
> IMO it is odd that candidate is cleaned up only if it was locked.
> If a client edits candidate and then closes the session somehow the
changes
> are left behind.
> The RFC is silent about the contents of candidate at boot-time. Our
server
> always boots
> with the candidate and running having the same contents.  Otherwise
the
> candidate is
> dirty at boot-time and cannot be locked by any session until a
> discard-changes is invoked.
> There is also no explicit requirement to boot with any particular
candidate
> contents, so
> booting with the contents of running is compliant.
>
>
>
> > Lada
> >
>
> Andy
>
>
> >
> > >
> > > The XMLCONF design team (pre-4741) tried very hard to
> > > get the router vendors to agree on a single transaction model
> > > but it was way too big a change, and (of course) each vendor
> > > thought their way was better, so the standard should use that.
> > > We ended up with 3 configuration datastores (candidate, running,
> > startup).
> > > The transaction models that can be used with these datastores
> > > are compatible with specific router CLI architectures.
> > >
> > > Two particular vendors do not agree on how to recover
> > > from the "unreachable" problem.  If the operator makes
> > > config changes that break the connectivity to the device,
> > > then the device has to recover somehow.
> > >
> > >   M1: do not persist the changes until they are proven to
> > >         be correct.  Force the device to reboot with the saved
> > >         (known good) config if things go bad.
> > >
> > >   M2: persist the changes right away.  Pick some timeout
> > >         and if the client does not follow up with a confirmation
> > >         before the timeout, automatically revert to the version
> > >         that was running before the transaction started.
> > >
> > > RFC 6241 could be more clear on the motivation for the
> > > capabilities and operations that support various transaction
models.
> > > Maybe that is what you meant by 'ill-defined'.
> > >
> > >
> > > Andy
> > >
> > > So the two objects controlling Notifications seem clearly
configuration,
> > >> whether or not the setting of them persists or is lost on reboot.
You
> > >> could create a YANG module which controls the setting of these
two
> > >> objects for SNMP usage but I think that even the IESG might see
that
> > >> that is an unusual approach, as opposed to making them read-write
in
> > >> SMI!
> > >>
> > >> When I first read the draft IESG statement, it was unclear to me
whether
> > >> or not the authors fully understood what they had written.
> > >>
> > >> Tom Petch
> > >>
> > >> > (*1)
http://www.ietf.org/iesg/statement/writable-mib-module.html
> > >> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> > >> >
> > >> > Hirochika
> > >> >
> > >> >
> > >> > On May 27, 2014, at 3:55 AM, joel jaeggli 
wrote:
> > >> >
> > >> > > yeah if you want to discuss it with the ops/management ADs
and the
> > >> > > chairs that's fine.
> > >> > >
> > >> > > I don't think there's a reason to involve the whole iesg.
> > >> > >
> > >> > > Thanks
> > >> > > joel
> > >> > >
> > >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> > >> > >> js and Joel,
> > >> > >>
> > >> > >> Thank you for your comments.
> > >> > >>
> > >> > >> I agree that the IESG statement seems to be talking about
> > >> configuration,
> > >> > >> but I cannot definitely say that the objects I listed in my
> > >> previous E-mail
> > >> > >> are out of the IESG statement's scope.
> > >> > >>
> > >> > >> I think it would be better to move this issue to the IESG,
but I
> > >> don't keep
> > >> > >> up the procedure.  May I, as an author of the draft, send an
E-mail
> > >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG
chairs to
> > >> > >> handle it?
> > >> > >>
> > >> > >> Thank you.
> > >> > >> Hirochika
> > >> > >>
> > >> > >>
> > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli 
> > wrote:
> > >> > >>
> > >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> > >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli
wrote:
> > >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> > >> > >>>>>> Asai,
> > >> > >>>>>>
> > >> > >>>>>> the IESG statement is here:
> > >> > >>>>>>
> > >> > >>>>>>
http://www.ietf.org/iesg/statement/writable-mib-module.html
> > >> > >>>>>>
> > >> > >>>>>> My reading is that it specifically talks about
configuration.
> > >> While
> > >> > >>>>>> the discussion started with "lets ban all write access",
it may
> > >> be
> > >> > >>>>>> important to note that the final statement does not say
this.
> > >> Hence,
> > >> > >>>>>> I am not sure we have to remove the MAX-ACCESS
read-write.
> > >> > >>>>>
> > >> > >>>>> some of the vm options do cause me existential peril. The
> > >> remaining
> > >> > >>>>> one's however do not. so I think Juergen's assessment  is
a
> > >> correct one.
> > >> > >>>>> The statement seems to be serving it's purpose!
> > >> >>>>
> > >> > >>>> Joel, can you please decrypt your message so that it
becomes
> > >> perhaps
> > >> > >>>> actionable?
> > >> > >>>
> > >> > >>> I'm agreeing with you.
> > >> > >>>
> > >> > >>>> /js
> > >> > --
> > >> > Hirochika Asai , The University of
Tokyo
> > >> >
> > >> > _______________________________________________
> > >> > OPSAWG mailing list
> > >> > OPSAWG@ietf.org
> > >> > https://www.ietf.org/mailman/listinfo/opsawg
> > >>
> > >> _______________________________________________
> > >> OPSAWG mailing list
> > >> OPSAWG@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/opsawg
> > >>
> > > _______________________________________________
> > > OPSAWG mailing list
> > > OPSAWG@ietf.org
> > > https://www.ietf.org/mailman/listinfo/opsawg
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
>


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


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


From nobody Fri May 30 04:11:31 2014
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 092F01A08AF for ; Fri, 30 May 2014 04:11:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 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_15=0.6, RP_MATCHES_RCVD=-0.651] 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 r4uIDViI0FF7 for ; Fri, 30 May 2014 04:11:19 -0700 (PDT)
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 789D81A0193 for ; Fri, 30 May 2014 04:11:18 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C76FB13FA81; Fri, 30 May 2014 13:11:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401448270; bh=PRoOcLdVmgeCMtPUbmkfa/euOidOKzVYlBZFY7Qt1y8=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NpuMwLhIB8NCYZGXsWNLKCZ7nxh1x+Vv4kfOQDNRmpyPWZVjL7NqLUqdo6uI44uFF tcMSCp1ErfepdqSIe33C+19n7+HKObIbHZh7ER0Ui8NjgpOmbPvgiiGwU97nevwYwg Fy7yQhXYHgyi7J81oanWquJdc+sLcZQyczKld8VQ=
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Content-Type: text/plain; charset=windows-1252
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net>
Date: Fri, 30 May 2014 13:11:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net>
To: "t.petch" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/PQd11f3Ql6KVwuC2FOW2sq7UJrM
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 11:11:29 -0000

On 30 May 2014, at 12:34, t.petch  wrote:

> ----- Original Message -----
> From: "Andy Bierman" 
> To: "Ladislav Lhotka" 
> Cc: "Netconf" 
> Sent: Thursday, May 29, 2014 1:31 PM
>> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka 
> wrote:
>>=20
>>> Hi,
>>>=20
>>> I am moving this discussion to the NETCONF mailing list.
>>>=20
>>> Andy Bierman  writes:
>>> ...
>>>>=20
>>>> I don't agree NETCONF/YANG persistence is ill-defined.
>>>> It is not uniform. There are a few variants, identified by
>>>> capability URIs.
>>>=20
>>> I'd say persistence is at least under-defined. For example, it
> doesn't
>>> seem to be clear from 6241 whether candidate is persistent.
>>>=20
>>>=20
>> OK
>=20
> Andy
>=20
> I am happy to characterise it as under-defined rather that =
ill-defined,
> but I think that the RFC are lacking.   We did have this discussion a
> few months back, and my point then was that if the only configuration
> datastore is running, then the assumption by implementers was that any
> change to it would immediately be persistent.  Seems reasonable, but =
not
> specified anywhere, and since running then has the opposite semantics
> with startup alongside it, well, that makes it less clearly defined, =
for
> me.
>=20
> As Lada points out, that is not the only such under-definition.

Another thing that puzzles me:

Let=92s say a client edits the value of parameter X in running. The new =
value is immediately projected into operational state. Then later the =
state value gets changed by some means external to NETCONF. In what =
event, if any, will the value of X be reset to the value that=92s =
configured in running?

Lada

>=20
> Tom Petch
>=20
>> sec 8.3.5.2 says:
>>=20
>>   When a client fails with outstanding changes to the candidate
>>   configuration, recovery can be difficult.  To facilitate easy
>>   recovery, any outstanding changes are discarded when the lock is
>>   released, whether explicitly with the  operation or
>>   implicitly from session failure.
>>=20
>> IMO it is odd that candidate is cleaned up only if it was locked.
>> If a client edits candidate and then closes the session somehow the
> changes
>> are left behind.
>> The RFC is silent about the contents of candidate at boot-time. Our
> server
>> always boots
>> with the candidate and running having the same contents.  Otherwise
> the
>> candidate is
>> dirty at boot-time and cannot be locked by any session until a
>> discard-changes is invoked.
>> There is also no explicit requirement to boot with any particular
> candidate
>> contents, so
>> booting with the contents of running is compliant.
>>=20
>>=20
>>=20
>>> Lada
>>>=20
>>=20
>> Andy
>>=20
>>=20
>>>=20
>>>>=20
>>>> The XMLCONF design team (pre-4741) tried very hard to
>>>> get the router vendors to agree on a single transaction model
>>>> but it was way too big a change, and (of course) each vendor
>>>> thought their way was better, so the standard should use that.
>>>> We ended up with 3 configuration datastores (candidate, running,
>>> startup).
>>>> The transaction models that can be used with these datastores
>>>> are compatible with specific router CLI architectures.
>>>>=20
>>>> Two particular vendors do not agree on how to recover
>>>> from the "unreachable" problem.  If the operator makes
>>>> config changes that break the connectivity to the device,
>>>> then the device has to recover somehow.
>>>>=20
>>>>  M1: do not persist the changes until they are proven to
>>>>        be correct.  Force the device to reboot with the saved
>>>>        (known good) config if things go bad.
>>>>=20
>>>>  M2: persist the changes right away.  Pick some timeout
>>>>        and if the client does not follow up with a confirmation
>>>>        before the timeout, automatically revert to the version
>>>>        that was running before the transaction started.
>>>>=20
>>>> RFC 6241 could be more clear on the motivation for the
>>>> capabilities and operations that support various transaction
> models.
>>>> Maybe that is what you meant by 'ill-defined'.
>>>>=20
>>>>=20
>>>> Andy
>>>>=20
>>>> So the two objects controlling Notifications seem clearly
> configuration,
>>>>> whether or not the setting of them persists or is lost on reboot.
> You
>>>>> could create a YANG module which controls the setting of these
> two
>>>>> objects for SNMP usage but I think that even the IESG might see
> that
>>>>> that is an unusual approach, as opposed to making them read-write
> in
>>>>> SMI!
>>>>>=20
>>>>> When I first read the draft IESG statement, it was unclear to me
> whether
>>>>> or not the authors fully understood what they had written.
>>>>>=20
>>>>> Tom Petch
>>>>>=20
>>>>>> (*1)
> http://www.ietf.org/iesg/statement/writable-mib-module.html
>>>>>> (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
>>>>>>=20
>>>>>> Hirochika
>>>>>>=20
>>>>>>=20
>>>>>> On May 27, 2014, at 3:55 AM, joel jaeggli 
> wrote:
>>>>>>=20
>>>>>>> yeah if you want to discuss it with the ops/management ADs
> and the
>>>>>>> chairs that's fine.
>>>>>>>=20
>>>>>>> I don't think there's a reason to involve the whole iesg.
>>>>>>>=20
>>>>>>> Thanks
>>>>>>> joel
>>>>>>>=20
>>>>>>> On 5/26/14, 10:48 AM, Hirochika Asai wrote:
>>>>>>>> js and Joel,
>>>>>>>>=20
>>>>>>>> Thank you for your comments.
>>>>>>>>=20
>>>>>>>> I agree that the IESG statement seems to be talking about
>>>>> configuration,
>>>>>>>> but I cannot definitely say that the objects I listed in my
>>>>> previous E-mail
>>>>>>>> are out of the IESG statement's scope.
>>>>>>>>=20
>>>>>>>> I think it would be better to move this issue to the IESG,
> but I
>>>>> don't keep
>>>>>>>> up the procedure.  May I, as an author of the draft, send an
> E-mail
>>>>>>>> stating this issue to iesg@ietf.org, CCing WG? Or ask WG
> chairs to
>>>>>>>> handle it?
>>>>>>>>=20
>>>>>>>> Thank you.
>>>>>>>> Hirochika
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> On May 27, 2014, at 1:24 AM, joel jaeggli 
>>> wrote:
>>>>>>>>=20
>>>>>>>>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
>>>>>>>>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli
> wrote:
>>>>>>>>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
>>>>>>>>>>>> Asai,
>>>>>>>>>>>>=20
>>>>>>>>>>>> the IESG statement is here:
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
> http://www.ietf.org/iesg/statement/writable-mib-module.html
>>>>>>>>>>>>=20
>>>>>>>>>>>> My reading is that it specifically talks about
> configuration.
>>>>> While
>>>>>>>>>>>> the discussion started with "lets ban all write access",
> it may
>>>>> be
>>>>>>>>>>>> important to note that the final statement does not say
> this.
>>>>> Hence,
>>>>>>>>>>>> I am not sure we have to remove the MAX-ACCESS
> read-write.
>>>>>>>>>>>=20
>>>>>>>>>>> some of the vm options do cause me existential peril. The
>>>>> remaining
>>>>>>>>>>> one's however do not. so I think Juergen's assessment  is
> a
>>>>> correct one.
>>>>>>>>>>> The statement seems to be serving it's purpose!
>>>>>>>>>=20
>>>>>>>>>> Joel, can you please decrypt your message so that it
> becomes
>>>>> perhaps
>>>>>>>>>> actionable?
>>>>>>>>>=20
>>>>>>>>> I'm agreeing with you.
>>>>>>>>>=20
>>>>>>>>>> /js
>>>>>> --
>>>>>> Hirochika Asai , The University of
> Tokyo
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OPSAWG mailing list
>>>>>> OPSAWG@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>>>=20
>>>>> _______________________________________________
>>>>> OPSAWG mailing list
>>>>> OPSAWG@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>>>=20
>>>> _______________________________________________
>>>> OPSAWG mailing list
>>>> OPSAWG@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>=20
>>=20
>=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 Fri May 30 07:17:43 2014
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 E53871A08F6 for ; Fri, 30 May 2014 07:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level: 
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 o9F6HzRoqKwI for ; Fri, 30 May 2014 07:17:37 -0700 (PDT)
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4CC1A0901 for ; Fri, 30 May 2014 07:17:36 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id f51so5370631qge.40 for ; Fri, 30 May 2014 07:17:32 -0700 (PDT)
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=A6BGqx7LoIVigDTnLQ8tys7qXOzzVKP6y9oyCQB02N0=; b=i7igSvzvvhy/oeTJIMISLHWjddmLeqJ4PVCwWX3ygY5Ulaf7IaK/u1h1fF6qYRadMe W2J5xDRvLqfhi83ZUm4WBss/kXOjiOitPcB7x5p7McWbyR+xyBD4c7CmpamVOte5Kv0A eKtU1d/VK09dQEKIPm/AM86rfMCuTG8cQJZAZbMp+PHhL7+5fck+C4PVzHeRzrsLRy45 92Mml1SpcUwQRghoegewkNW/KbT6sc5vnRH4xZ4iSJALJiEMWXxENTWqOxwVO1rmkpgb SRlRcYBL2eXjN3u1Iy22MkjJwaT9Z6P1ZVlu/3N8Hc5dJvntOJr98PDUybYj9rTwp7Rw sXhw==
X-Gm-Message-State: ALoCoQlUaOEQnSFoLr7x6mMnxSMk6QFWZ70+0l0kDStzdnT6O+Ko3PB5neiNgtApMQCl3vgi3CSP
MIME-Version: 1.0
X-Received: by 10.140.27.245 with SMTP id 108mr20200801qgx.18.1401459451867; Fri, 30 May 2014 07:17:31 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 30 May 2014 07:17:31 -0700 (PDT)
In-Reply-To: <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net>
References:    <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net>
Date: Fri, 30 May 2014 07:17:31 -0700
Message-ID: 
From: Andy Bierman 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=001a11c15260cbd0b904fa9eb429
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dpONIfzEgx1RzS-YN09MyEoaWT4
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 14:17:40 -0000

--001a11c15260cbd0b904fa9eb429
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 30, 2014 at 3:34 AM, t.petch  wrote:

> ----- Original Message -----
> From: "Andy Bierman" 
> To: "Ladislav Lhotka" 
> Cc: "Netconf" 
> Sent: Thursday, May 29, 2014 1:31 PM
> > On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka 
> wrote:
> >
> > > Hi,
> > >
> > > I am moving this discussion to the NETCONF mailing list.
> > >
> > > Andy Bierman  writes:
> > > ...
> > > >
> > > > I don't agree NETCONF/YANG persistence is ill-defined.
> > > > It is not uniform. There are a few variants, identified by
> > > > capability URIs.
> > >
> > > I'd say persistence is at least under-defined. For example, it
> doesn't
> > > seem to be clear from 6241 whether candidate is persistent.
> > >
> > >
> > OK
>
> Andy
>
> I am happy to characterise it as under-defined rather that ill-defined,
> but I think that the RFC are lacking.   We did have this discussion a
> few months back, and my point then was that if the only configuration
> datastore is running, then the assumption by implementers was that any
> change to it would immediately be persistent.  Seems reasonable, but not
> specified anywhere, and since running then has the opposite semantics
> with startup alongside it, well, that makes it less clearly defined, for
> me.
>

So you are saying you did not understand RFC 6241, sec.  8.7?
Is there something unclear in this section? It says:

   The device supports separate running and startup configuration
   datastores.  The startup configuration is loaded by the device when
   it boots.  Operations that affect the running configuration will not
   be automatically copied to the startup configuration.  An explicit
    operation from the  to the  is used
   to update the startup configuration to the current contents of the
   running configuration.  NETCONF protocol operations refer to the
   startup datastore using the  element.


The client checks for the "distinct startup" capability.
How is this unspecified?  Did you miss this section?



> As Lada points out, that is not the only such under-definition.
>
>
The RFC does not say anything about High Availability features.
If the server wants to persist state information so it can recover
from a hot-swap faster, then that is a fine extra feature, but
not required at all by the standard.


> Tom Petch
>
>
Andy


> > sec 8.3.5.2 says:
> >
> >    When a client fails with outstanding changes to the candidate
> >    configuration, recovery can be difficult.  To facilitate easy
> >    recovery, any outstanding changes are discarded when the lock is
> >    released, whether explicitly with the  operation or
> >    implicitly from session failure.
> >
> > IMO it is odd that candidate is cleaned up only if it was locked.
> > If a client edits candidate and then closes the session somehow the
> changes
> > are left behind.
> > The RFC is silent about the contents of candidate at boot-time. Our
> server
> > always boots
> > with the candidate and running having the same contents.  Otherwise
> the
> > candidate is
> > dirty at boot-time and cannot be locked by any session until a
> > discard-changes is invoked.
> > There is also no explicit requirement to boot with any particular
> candidate
> > contents, so
> > booting with the contents of running is compliant.
> >
> >
> >
> > > Lada
> > >
> >
> > Andy
> >
> >
> > >
> > > >
> > > > The XMLCONF design team (pre-4741) tried very hard to
> > > > get the router vendors to agree on a single transaction model
> > > > but it was way too big a change, and (of course) each vendor
> > > > thought their way was better, so the standard should use that.
> > > > We ended up with 3 configuration datastores (candidate, running,
> > > startup).
> > > > The transaction models that can be used with these datastores
> > > > are compatible with specific router CLI architectures.
> > > >
> > > > Two particular vendors do not agree on how to recover
> > > > from the "unreachable" problem.  If the operator makes
> > > > config changes that break the connectivity to the device,
> > > > then the device has to recover somehow.
> > > >
> > > >   M1: do not persist the changes until they are proven to
> > > >         be correct.  Force the device to reboot with the saved
> > > >         (known good) config if things go bad.
> > > >
> > > >   M2: persist the changes right away.  Pick some timeout
> > > >         and if the client does not follow up with a confirmation
> > > >         before the timeout, automatically revert to the version
> > > >         that was running before the transaction started.
> > > >
> > > > RFC 6241 could be more clear on the motivation for the
> > > > capabilities and operations that support various transaction
> models.
> > > > Maybe that is what you meant by 'ill-defined'.
> > > >
> > > >
> > > > Andy
> > > >
> > > > So the two objects controlling Notifications seem clearly
> configuration,
> > > >> whether or not the setting of them persists or is lost on reboot.
> You
> > > >> could create a YANG module which controls the setting of these
> two
> > > >> objects for SNMP usage but I think that even the IESG might see
> that
> > > >> that is an unusual approach, as opposed to making them read-write
> in
> > > >> SMI!
> > > >>
> > > >> When I first read the draft IESG statement, it was unclear to me
> whether
> > > >> or not the authors fully understood what they had written.
> > > >>
> > > >> Tom Petch
> > > >>
> > > >> > (*1)
> http://www.ietf.org/iesg/statement/writable-mib-module.html
> > > >> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> > > >> >
> > > >> > Hirochika
> > > >> >
> > > >> >
> > > >> > On May 27, 2014, at 3:55 AM, joel jaeggli 
> wrote:
> > > >> >
> > > >> > > yeah if you want to discuss it with the ops/management ADs
> and the
> > > >> > > chairs that's fine.
> > > >> > >
> > > >> > > I don't think there's a reason to involve the whole iesg.
> > > >> > >
> > > >> > > Thanks
> > > >> > > joel
> > > >> > >
> > > >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> > > >> > >> js and Joel,
> > > >> > >>
> > > >> > >> Thank you for your comments.
> > > >> > >>
> > > >> > >> I agree that the IESG statement seems to be talking about
> > > >> configuration,
> > > >> > >> but I cannot definitely say that the objects I listed in my
> > > >> previous E-mail
> > > >> > >> are out of the IESG statement's scope.
> > > >> > >>
> > > >> > >> I think it would be better to move this issue to the IESG,
> but I
> > > >> don't keep
> > > >> > >> up the procedure.  May I, as an author of the draft, send an
> E-mail
> > > >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG
> chairs to
> > > >> > >> handle it?
> > > >> > >>
> > > >> > >> Thank you.
> > > >> > >> Hirochika
> > > >> > >>
> > > >> > >>
> > > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli 
> > > wrote:
> > > >> > >>
> > > >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> > > >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli
> wrote:
> > > >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> > > >> > >>>>>> Asai,
> > > >> > >>>>>>
> > > >> > >>>>>> the IESG statement is here:
> > > >> > >>>>>>
> > > >> > >>>>>>
> http://www.ietf.org/iesg/statement/writable-mib-module.html
> > > >> > >>>>>>
> > > >> > >>>>>> My reading is that it specifically talks about
> configuration.
> > > >> While
> > > >> > >>>>>> the discussion started with "lets ban all write access",
> it may
> > > >> be
> > > >> > >>>>>> important to note that the final statement does not say
> this.
> > > >> Hence,
> > > >> > >>>>>> I am not sure we have to remove the MAX-ACCESS
> read-write.
> > > >> > >>>>>
> > > >> > >>>>> some of the vm options do cause me existential peril. The
> > > >> remaining
> > > >> > >>>>> one's however do not. so I think Juergen's assessment  is
> a
> > > >> correct one.
> > > >> > >>>>> The statement seems to be serving it's purpose!
> > > >> >>>>
> > > >> > >>>> Joel, can you please decrypt your message so that it
> becomes
> > > >> perhaps
> > > >> > >>>> actionable?
> > > >> > >>>
> > > >> > >>> I'm agreeing with you.
> > > >> > >>>
> > > >> > >>>> /js
> > > >> > --
> > > >> > Hirochika Asai , The University of
> Tokyo
> > > >> >
> > > >> > _______________________________________________
> > > >> > OPSAWG mailing list
> > > >> > OPSAWG@ietf.org
> > > >> > https://www.ietf.org/mailman/listinfo/opsawg
> > > >>
> > > >> _______________________________________________
> > > >> OPSAWG mailing list
> > > >> OPSAWG@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/opsawg
> > > >>
> > > > _______________________________________________
> > > > OPSAWG mailing list
> > > > OPSAWG@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/opsawg
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> >
>
>
> ------------------------------------------------------------------------
> --------
>
>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
>
>

--001a11c15260cbd0b904fa9eb429
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Fri, May 30, 2014 at 3:34 AM, t.petch <ietfc@btconnect.com> wrote:


----- Original Message -----

From: "Andy Bierman" <an=
dy@yumaworks.com>

To: "Ladislav Lhotka" <lhotka=
@nic.cz>

Cc: "Netconf" <netconf@iet=
f.org>

Sent: Thursday, May 29, 2014 1:31 PM

> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka <lhotka@nic.cz>

wrote:

>

> > Hi,

> >

> > I am moving this discussion to the NETCONF mailing list.

> >

> > Andy Bierman <andy@yumaw=
orks.com> writes:

> > ...

> > >

> > > I don't agree NETCONF/YANG persistence is ill-defined.
> > > It is not uniform. There are a few variants, identified by
> > > capability URIs.

> >

> > I'd say persistence is at least under-defined. For example, i=
t

doesn't

> > seem to be clear from 6241 whether candidate is persistent.

> >

> >

> OK



Andy



I am happy to characterise it as under-defined rather that ill-defined,

but I think that the RFC are lacking. =A0 We did have this discussion a

few months back, and my point then was that if the only configuration

datastore is running, then the assumption by implementers was that any

change to it would immediately be persistent. =A0Seems reasonable, but not<=
br>
specified anywhere, and since running then has the opposite semantics

with startup alongside it, well, that makes it less clearly defined, for
me.

So you are saying you did not under=
stand RFC 6241, sec. =A08.7?
Is there something unclear in this s=
ection? It says:
   The device supports separate running and startup configuration
   datastores.  The startup configuration is loaded by the device when
   it boots.  Operations that affect the running configuration will not
   be automatically copied to the startup configuration.  An explicit
   <copy-config> operation from the <running> to the <startu=
p> is used
   to update the startup configuration to the current contents of the
   running configuration.  NETCONF protocol operations refer to the
   startup datastore using the <startup> element.

The client=
 checks for the "distinct startup" capability.
How is this uns=
pecified? =A0Did you miss this section?




As Lada points out, that is not the only such under-definition.



The RFC does not say anything about Hi=
gh Availability features.
If the server wants to persist state in=
formation so it can recover
from a hot-swap faster, then that is =
a fine extra feature, but


not required at all by the standard.
=A0


Tom Petch



Andy
=A0


> sec 8.3.5.2 says:

>

> =A0 =A0When a client fails with outstanding changes to the candidate
> =A0 =A0configuration, recovery can be difficult. =A0To facilitate easy=


> =A0 =A0recovery, any outstanding changes are discarded when the lock i=
s

> =A0 =A0released, whether explicitly with the <unlock> operation =
or

> =A0 =A0implicitly from session failure.

>

> IMO it is odd that candidate is cleaned up only if it was locked.

> If a client edits candidate and then closes the session somehow the
changes

> are left behind.

> The RFC is silent about the contents of candidate at boot-time. Our
server

> always boots

> with the candidate and running having the same contents. =A0Otherwise<=
br>
the

> candidate is

> dirty at boot-time and cannot be locked by any session until a

> discard-changes is invoked.

> There is also no explicit requirement to boot with any particular

candidate

> contents, so

> booting with the contents of running is compliant.

>

>

>

> > Lada

> >

>

> Andy

>

>

> >

> > >

> > > The XMLCONF design team (pre-4741) tried very hard to

> > > get the router vendors to agree on a single transaction mode=
l

> > > but it was way too big a change, and (of course) each vendor=


> > > thought their way was better, so the standard should use tha=
t.

> > > We ended up with 3 configuration datastores (candidate, runn=
ing,

> > startup).

> > > The transaction models that can be used with these datastore=
s

> > > are compatible with specific router CLI architectures.

> > >

> > > Two particular vendors do not agree on how to recover

> > > from the "unreachable" problem. =A0If the operator=
 makes

> > > config changes that break the connectivity to the device,
> > > then the device has to recover somehow.

> > >

> > > =A0 M1: do not persist the changes until they are proven to<=
br>
> > > =A0 =A0 =A0 =A0 be correct. =A0Force the device to reboot wi=
th the saved

> > > =A0 =A0 =A0 =A0 (known good) config if things go bad.

> > >

> > > =A0 M2: persist the changes right away. =A0Pick some timeout=


> > > =A0 =A0 =A0 =A0 and if the client does not follow up with a =
confirmation

> > > =A0 =A0 =A0 =A0 before the timeout, automatically revert to =
the version

> > > =A0 =A0 =A0 =A0 that was running before the transaction star=
ted.

> > >

> > > RFC 6241 could be more clear on the motivation for the

> > > capabilities and operations that support various transaction=


models.

> > > Maybe that is what you meant by 'ill-defined'.

> > >

> > >

> > > Andy

> > >

> > > So the two objects controlling Notifications seem clearly
configuration,

> > >> whether or not the setting of them persists or is lost o=
n reboot.

You

> > >> could create a YANG module which controls the setting of=
 these

two

> > >> objects for SNMP usage but I think that even the IESG mi=
ght see

that

> > >> that is an unusual approach, as opposed to making them r=
ead-write

in

> > >> SMI!

> > >>

> > >> When I first read the draft IESG statement, it was uncle=
ar to me

whether

> > >> or not the authors fully understood what they had writte=
n.

> > >>

> > >> Tom Petch

> > >>

> > >> > (*1)

http://www.ietf.org/iesg/statement/writable-mib-module.html<=
/a>

> > >> > (*2) http://tools.ietf.org/html/draft-ie=
tf-opsawg-vmm-mib-00

> > >> >

> > >> > Hirochika

> > >> >

> > >> >

> > >> > On May 27, 2014, at 3:55 AM, joel jaeggli <joelja@bogus.com>

wrote:

> > >> >

> > >> > > yeah if you want to discuss it with the ops/ma=
nagement ADs

and the

> > >> > > chairs that's fine.

> > >> > >

> > >> > > I don't think there's a reason to invo=
lve the whole iesg.

> > >> > >

> > >> > > Thanks

> > >> > > joel

> > >> > >

> > >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> > >> > >> js and Joel,

> > >> > >>

> > >> > >> Thank you for your comments.

> > >> > >>

> > >> > >> I agree that the IESG statement seems to b=
e talking about

> > >> configuration,

> > >> > >> but I cannot definitely say that the objec=
ts I listed in my

> > >> previous E-mail

> > >> > >> are out of the IESG statement's scope.=


> > >> > >>

> > >> > >> I think it would be better to move this is=
sue to the IESG,

but I

> > >> don't keep

> > >> > >> up the procedure. =A0May I, as an author o=
f the draft, send an

E-mail

> > >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG

chairs to

> > >> > >> handle it?

> > >> > >>

> > >> > >> Thank you.

> > >> > >> Hirochika

> > >> > >>

> > >> > >>

> > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli =
<joelja@bogus.com>

> > wrote:

> > >> > >>

> > >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwae=
lder wrote:

> > >> > >>>> On Mon, May 26, 2014 at 08:42:47AM=
 -0700, joel jaeggli

wrote:

> > >> > >>>>> On 5/26/14, 2:31 AM, Juergen S=
choenwaelder wrote:

> > >> > >>>>>> Asai,

> > >> > >>>>>>

> > >> > >>>>>> the IESG statement is here=
:

> > >> > >>>>>>

> > >> > >>>>>>

http://www.ietf.org/iesg/statement/writable-mib-module.html<=
/a>

> > >> > >>>>>>

> > >> > >>>>>> My reading is that it spec=
ifically talks about

configuration.

> > >> While

> > >> > >>>>>> the discussion started wit=
h "lets ban all write access",

it may

> > >> be

> > >> > >>>>>> important to note that the=
 final statement does not say

this.

> > >> Hence,

> > >> > >>>>>> I am not sure we have to r=
emove the MAX-ACCESS

read-write.

> > >> > >>>>>

> > >> > >>>>> some of the vm options do caus=
e me existential peril. The

> > >> remaining

> > >> > >>>>> one's however do not. so I=
 think Juergen's assessment =A0is

a

> > >> correct one.

> > >> > >>>>> The statement seems to be serv=
ing it's purpose!

> > >> >>>>

> > >> > >>>> Joel, can you please decrypt your =
message so that it

becomes

> > >> perhaps

> > >> > >>>> actionable?

> > >> > >>>

> > >> > >>> I'm agreeing with you.

> > >> > >>>

> > >> > >>>> /js

> > >> > --

> > >> > Hirochika Asai <panda@hongo.wide.ad.jp>, The University of

Tokyo

> > >> >

> > >> > _______________________________________________

> > >> > OPSAWG mailing list

> > >> > OPSAWG@ietf.org<=
/a>

> > >> > https://www.ietf.org/mailman/listinfo/opsawg
> > >>

> > >> _______________________________________________

> > >> OPSAWG mailing list

> > >> OPSAWG@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/opsawg

> > >>

> > > _______________________________________________

> > > OPSAWG mailing list

> > > OPSAWG@ietf.org

> > > https://www.ietf.org/mailman/listinfo/opsawg

> >

> > --

> > Ladislav Lhotka, CZ.NIC Labs

> > PGP Key ID: E74E8C0C

> >

> > _______________________________________________

> > Netconf mailing list

> > Netconf@ietf.org

> > https://www.ietf.org/mailman/listinfo/netconf

> >

>





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





> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org

> https://www.ietf.org/mailman/listinfo/netconf

>







--001a11c15260cbd0b904fa9eb429--


From nobody Fri May 30 07:30:33 2014
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 3FD441A0911 for ; Fri, 30 May 2014 07:30:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level: 
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 y2xAHxeyFKDe for ; Fri, 30 May 2014 07:30:28 -0700 (PDT)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBEE1A08FB for ; Fri, 30 May 2014 07:30:28 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id q107so5636497qgd.1 for ; Fri, 30 May 2014 07:30:23 -0700 (PDT)
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=PXZubkmUzM3XZVyNI21Iva6t8MmMoQ8aypk6u6Rr6i4=; b=Hk+DuHgrgVi3c2MkBF2opjoPdrnG9blLJAFaONZT5l9qj6R4sOFIgG632UlAzIsR6d /A2OnglKcLwK8gTbZmFrDoahTaiAezdYpp0l1tXBsj5YC6J1cStfEKM9tAW2oqMJSHBw IrAlHj5ET5rTy9PL1nZIjSuK5BinSl2NmPmRytkDWpsqwUHUxCH/z7ByBd1i6vyztO4O Xet1I4l5pHgczO0FbWx5jHRktjGpO3AENFZfS8p2p+MmJ07A82RNcUVYWO5WoRZaKHxV 2muXHZDn4QDf9Xg13Pmfdcw659VJ6GA2P/XV3bOX8DXW1DCJGAfPSgVY+2FyQM0cw7wo lDiA==
X-Gm-Message-State: ALoCoQmmyGit+5kjvnpBPQOOR6wUZQ+KfxWTt1C11Z+i4kG/cuXfuEiQ1DKD+Mc+J04Fn69QPG/E
MIME-Version: 1.0
X-Received: by 10.140.27.23 with SMTP id 23mr20355530qgw.94.1401460223366; Fri, 30 May 2014 07:30:23 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 30 May 2014 07:30:23 -0700 (PDT)
In-Reply-To: 
References:    <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net> 
Date: Fri, 30 May 2014 07:30:23 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c14a7cc812aa04fa9ee2eb
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6Vrrkbao6BJfaFeGD4-wVU22LbQ
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 14:30:32 -0000

--001a11c14a7cc812aa04fa9ee2eb
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka  wrote:

>
> On 30 May 2014, at 12:34, t.petch  wrote:
>
> > ----- Original Message -----
> > From: "Andy Bierman" 
> > To: "Ladislav Lhotka" 
> > Cc: "Netconf" 
> > Sent: Thursday, May 29, 2014 1:31 PM
> >> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka 
> > wrote:
> >>
> >>> Hi,
> >>>
> >>> I am moving this discussion to the NETCONF mailing list.
> >>>
> >>> Andy Bierman  writes:
> >>> ...
> >>>>
> >>>> I don't agree NETCONF/YANG persistence is ill-defined.
> >>>> It is not uniform. There are a few variants, identified by
> >>>> capability URIs.
> >>>
> >>> I'd say persistence is at least under-defined. For example, it
> > doesn't
> >>> seem to be clear from 6241 whether candidate is persistent.
> >>>
> >>>
> >> OK
> >
> > Andy
> >
> > I am happy to characterise it as under-defined rather that ill-defined,
> > but I think that the RFC are lacking.   We did have this discussion a
> > few months back, and my point then was that if the only configuration
> > datastore is running, then the assumption by implementers was that any
> > change to it would immediately be persistent.  Seems reasonable, but not
> > specified anywhere, and since running then has the opposite semantics
> > with startup alongside it, well, that makes it less clearly defined, for
> > me.
> >
> > As Lada points out, that is not the only such under-definition.
>
> Another thing that puzzles me:
>
> Let's say a client edits the value of parameter X in running. The new
> value is immediately projected into operational state. Then later the state
> value gets changed by some means external to NETCONF. In what event, if
> any, will the value of X be reset to the value that's configured in running?
>
>
If state variables and config variables interact, then the description-stmt
should explain this data-model specific behavior.


Lada
>

Andy


>
> >
> > Tom Petch
> >
> >> sec 8.3.5.2 says:
> >>
> >>   When a client fails with outstanding changes to the candidate
> >>   configuration, recovery can be difficult.  To facilitate easy
> >>   recovery, any outstanding changes are discarded when the lock is
> >>   released, whether explicitly with the  operation or
> >>   implicitly from session failure.
> >>
> >> IMO it is odd that candidate is cleaned up only if it was locked.
> >> If a client edits candidate and then closes the session somehow the
> > changes
> >> are left behind.
> >> The RFC is silent about the contents of candidate at boot-time. Our
> > server
> >> always boots
> >> with the candidate and running having the same contents.  Otherwise
> > the
> >> candidate is
> >> dirty at boot-time and cannot be locked by any session until a
> >> discard-changes is invoked.
> >> There is also no explicit requirement to boot with any particular
> > candidate
> >> contents, so
> >> booting with the contents of running is compliant.
> >>
> >>
> >>
> >>> Lada
> >>>
> >>
> >> Andy
> >>
> >>
> >>>
> >>>>
> >>>> The XMLCONF design team (pre-4741) tried very hard to
> >>>> get the router vendors to agree on a single transaction model
> >>>> but it was way too big a change, and (of course) each vendor
> >>>> thought their way was better, so the standard should use that.
> >>>> We ended up with 3 configuration datastores (candidate, running,
> >>> startup).
> >>>> The transaction models that can be used with these datastores
> >>>> are compatible with specific router CLI architectures.
> >>>>
> >>>> Two particular vendors do not agree on how to recover
> >>>> from the "unreachable" problem.  If the operator makes
> >>>> config changes that break the connectivity to the device,
> >>>> then the device has to recover somehow.
> >>>>
> >>>>  M1: do not persist the changes until they are proven to
> >>>>        be correct.  Force the device to reboot with the saved
> >>>>        (known good) config if things go bad.
> >>>>
> >>>>  M2: persist the changes right away.  Pick some timeout
> >>>>        and if the client does not follow up with a confirmation
> >>>>        before the timeout, automatically revert to the version
> >>>>        that was running before the transaction started.
> >>>>
> >>>> RFC 6241 could be more clear on the motivation for the
> >>>> capabilities and operations that support various transaction
> > models.
> >>>> Maybe that is what you meant by 'ill-defined'.
> >>>>
> >>>>
> >>>> Andy
> >>>>
> >>>> So the two objects controlling Notifications seem clearly
> > configuration,
> >>>>> whether or not the setting of them persists or is lost on reboot.
> > You
> >>>>> could create a YANG module which controls the setting of these
> > two
> >>>>> objects for SNMP usage but I think that even the IESG might see
> > that
> >>>>> that is an unusual approach, as opposed to making them read-write
> > in
> >>>>> SMI!
> >>>>>
> >>>>> When I first read the draft IESG statement, it was unclear to me
> > whether
> >>>>> or not the authors fully understood what they had written.
> >>>>>
> >>>>> Tom Petch
> >>>>>
> >>>>>> (*1)
> > http://www.ietf.org/iesg/statement/writable-mib-module.html
> >>>>>> (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> >>>>>>
> >>>>>> Hirochika
> >>>>>>
> >>>>>>
> >>>>>> On May 27, 2014, at 3:55 AM, joel jaeggli 
> > wrote:
> >>>>>>
> >>>>>>> yeah if you want to discuss it with the ops/management ADs
> > and the
> >>>>>>> chairs that's fine.
> >>>>>>>
> >>>>>>> I don't think there's a reason to involve the whole iesg.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> joel
> >>>>>>>
> >>>>>>> On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> >>>>>>>> js and Joel,
> >>>>>>>>
> >>>>>>>> Thank you for your comments.
> >>>>>>>>
> >>>>>>>> I agree that the IESG statement seems to be talking about
> >>>>> configuration,
> >>>>>>>> but I cannot definitely say that the objects I listed in my
> >>>>> previous E-mail
> >>>>>>>> are out of the IESG statement's scope.
> >>>>>>>>
> >>>>>>>> I think it would be better to move this issue to the IESG,
> > but I
> >>>>> don't keep
> >>>>>>>> up the procedure.  May I, as an author of the draft, send an
> > E-mail
> >>>>>>>> stating this issue to iesg@ietf.org, CCing WG? Or ask WG
> > chairs to
> >>>>>>>> handle it?
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>> Hirochika
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On May 27, 2014, at 1:24 AM, joel jaeggli 
> >>> wrote:
> >>>>>>>>
> >>>>>>>>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> >>>>>>>>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli
> > wrote:
> >>>>>>>>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> >>>>>>>>>>>> Asai,
> >>>>>>>>>>>>
> >>>>>>>>>>>> the IESG statement is here:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> > http://www.ietf.org/iesg/statement/writable-mib-module.html
> >>>>>>>>>>>>
> >>>>>>>>>>>> My reading is that it specifically talks about
> > configuration.
> >>>>> While
> >>>>>>>>>>>> the discussion started with "lets ban all write access",
> > it may
> >>>>> be
> >>>>>>>>>>>> important to note that the final statement does not say
> > this.
> >>>>> Hence,
> >>>>>>>>>>>> I am not sure we have to remove the MAX-ACCESS
> > read-write.
> >>>>>>>>>>>
> >>>>>>>>>>> some of the vm options do cause me existential peril. The
> >>>>> remaining
> >>>>>>>>>>> one's however do not. so I think Juergen's assessment  is
> > a
> >>>>> correct one.
> >>>>>>>>>>> The statement seems to be serving it's purpose!
> >>>>>>>>>
> >>>>>>>>>> Joel, can you please decrypt your message so that it
> > becomes
> >>>>> perhaps
> >>>>>>>>>> actionable?
> >>>>>>>>>
> >>>>>>>>> I'm agreeing with you.
> >>>>>>>>>
> >>>>>>>>>> /js
> >>>>>> --
> >>>>>> Hirochika Asai , The University of
> > Tokyo
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> OPSAWG mailing list
> >>>>>> OPSAWG@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/opsawg
> >>>>>
> >>>>> _______________________________________________
> >>>>> OPSAWG mailing list
> >>>>> OPSAWG@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/opsawg
> >>>>>
> >>>> _______________________________________________
> >>>> OPSAWG mailing list
> >>>> OPSAWG@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/opsawg
> >>>
> >>> --
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> Netconf@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >>>
> >>
> >
> >
> > ------------------------------------------------------------------------
> > --------
> >
> >
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c14a7cc812aa04fa9ee2eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:




On 30 May 2014, at 12:34, t.petch <ietfc@btconnect.com> wrote:



> ----- Original Message -----

> From: "Andy Bierman" <andy@yumaworks.com>

> To: "Ladislav Lhotka" <l=
hotka@nic.cz>

> Cc: "Netconf" <netcon=
f@ietf.org>

> Sent: Thursday, May 29, 2014 1:31 PM

>> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka <lhotka@nic.cz>

> wrote:

>>

>>> Hi,

>>>

>>> I am moving this discussion to the NETCONF mailing list.

>>>

>>> Andy Bierman <andy@yu=
maworks.com> writes:

>>> ...

>>>>

>>>> I don't agree NETCONF/YANG persistence is ill-defined.=


>>>> It is not uniform. There are a few variants, identified by=


>>>> capability URIs.

>>>

>>> I'd say persistence is at least under-defined. For example=
, it

> doesn't

>>> seem to be clear from 6241 whether candidate is persistent.
>>>

>>>

>> OK

>

> Andy

>

> I am happy to characterise it as under-defined rather that ill-defined=
,

> but I think that the RFC are lacking.   We did have this discussi=
on a

> few months back, and my point then was that if the only configuration<=
br>
> datastore is running, then the assumption by implementers was that any=


> change to it would immediately be persistent.  Seems reasonable, =
but not

> specified anywhere, and since running then has the opposite semantics<=
br>
> with startup alongside it, well, that makes it less clearly defined, f=
or

> me.

>

> As Lada points out, that is not the only such under-definition.



Another thing that puzzles me:



Let’s say a client edits the value of parameter X in running. The new=
 value is immediately projected into operational state. Then later the stat=
e value gets changed by some means external to NETCONF. In what event, if a=
ny, will the value of X be reset to the value that’s configured in ru=
nning?




If state variables and config variable=
s interact, then the description-stmt
should explain this data-mo=
del specific behavior.




Lada

Andy
 



>

> Tom Petch

>

>> sec 8.3.5.2 says:

>>

>>   When a client fails with outstanding changes to the candida=
te

>>   configuration, recovery can be difficult.  To facilita=
te easy

>>   recovery, any outstanding changes are discarded when the lo=
ck is

>>   released, whether explicitly with the <unlock> operat=
ion or

>>   implicitly from session failure.

>>

>> IMO it is odd that candidate is cleaned up only if it was locked.<=
br>
>> If a client edits candidate and then closes the session somehow th=
e

> changes

>> are left behind.

>> The RFC is silent about the contents of candidate at boot-time. Ou=
r

> server

>> always boots

>> with the candidate and running having the same contents.  Oth=
erwise

> the

>> candidate is

>> dirty at boot-time and cannot be locked by any session until a

>> discard-changes is invoked.

>> There is also no explicit requirement to boot with any particular<=
br>
> candidate

>> contents, so

>> booting with the contents of running is compliant.

>>

>>

>>

>>> Lada

>>>

>>

>> Andy

>>

>>

>>>

>>>>

>>>> The XMLCONF design team (pre-4741) tried very hard to

>>>> get the router vendors to agree on a single transaction mo=
del

>>>> but it was way too big a change, and (of course) each vend=
or

>>>> thought their way was better, so the standard should use t=
hat.

>>>> We ended up with 3 configuration datastores (candidate, ru=
nning,

>>> startup).

>>>> The transaction models that can be used with these datasto=
res

>>>> are compatible with specific router CLI architectures.

>>>>

>>>> Two particular vendors do not agree on how to recover

>>>> from the "unreachable" problem.  If the ope=
rator makes

>>>> config changes that break the connectivity to the device,<=
br>
>>>> then the device has to recover somehow.

>>>>

>>>>  M1: do not persist the changes until they are proven=
 to

>>>>        be correct.  Force the dev=
ice to reboot with the saved

>>>>        (known good) config if things g=
o bad.

>>>>

>>>>  M2: persist the changes right away.  Pick some =
timeout

>>>>        and if the client does not foll=
ow up with a confirmation

>>>>        before the timeout, automatical=
ly revert to the version

>>>>        that was running before the tra=
nsaction started.

>>>>

>>>> RFC 6241 could be more clear on the motivation for the

>>>> capabilities and operations that support various transacti=
on

> models.

>>>> Maybe that is what you meant by 'ill-defined'.

>>>>

>>>>

>>>> Andy

>>>>

>>>> So the two objects controlling Notifications seem clearly<=
br>
> configuration,

>>>>> whether or not the setting of them persists or is lost=
 on reboot.

> You

>>>>> could create a YANG module which controls the setting =
of these

> two

>>>>> objects for SNMP usage but I think that even the IESG =
might see

> that

>>>>> that is an unusual approach, as opposed to making them=
 read-write

> in

>>>>> SMI!

>>>>>

>>>>> When I first read the draft IESG statement, it was unc=
lear to me

> whether

>>>>> or not the authors fully understood what they had writ=
ten.

>>>>>

>>>>> Tom Petch

>>>>>

>>>>>> (*1)

> http://www.ietf.org/iesg/statement/writable-mib-module.=
html

>>>>>> (*2) http://tools.ietf.org/html/draft-i=
etf-opsawg-vmm-mib-00

>>>>>>

>>>>>> Hirochika

>>>>>>

>>>>>>

>>>>>> On May 27, 2014, at 3:55 AM, joel jaeggli <joelja@bogus.com>

> wrote:

>>>>>>

>>>>>>> yeah if you want to discuss it with the ops/ma=
nagement ADs

> and the

>>>>>>> chairs that's fine.

>>>>>>>

>>>>>>> I don't think there's a reason to invo=
lve the whole iesg.

>>>>>>>

>>>>>>> Thanks

>>>>>>> joel

>>>>>>>

>>>>>>> On 5/26/14, 10:48 AM, Hirochika Asai wrote:
>>>>>>>> js and Joel,

>>>>>>>>

>>>>>>>> Thank you for your comments.

>>>>>>>>

>>>>>>>> I agree that the IESG statement seems to b=
e talking about

>>>>> configuration,

>>>>>>>> but I cannot definitely say that the objec=
ts I listed in my

>>>>> previous E-mail

>>>>>>>> are out of the IESG statement's scope.=


>>>>>>>>

>>>>>>>> I think it would be better to move this is=
sue to the IESG,

> but I

>>>>> don't keep

>>>>>>>> up the procedure.  May I, as an autho=
r of the draft, send an

> E-mail

>>>>>>>> stating this issue to iesg@ietf.org, CCing WG? Or ask WG

> chairs to

>>>>>>>> handle it?

>>>>>>>>

>>>>>>>> Thank you.

>>>>>>>> Hirochika

>>>>>>>>

>>>>>>>>

>>>>>>>> On May 27, 2014, at 1:24 AM, joel jaeggli =
<joelja@bogus.com>

>>> wrote:

>>>>>>>>

>>>>>>>>> On 5/26/14, 9:20 AM, Juergen Schoenwae=
lder wrote:

>>>>>>>>>> On Mon, May 26, 2014 at 08:42:47AM=
 -0700, joel jaeggli

> wrote:

>>>>>>>>>>> On 5/26/14, 2:31 AM, Juergen S=
choenwaelder wrote:

>>>>>>>>>>>> Asai,

>>>>>>>>>>>>

>>>>>>>>>>>> the IESG statement is here=
:

>>>>>>>>>>>>

>>>>>>>>>>>>

> http://www.ietf.org/iesg/statement/writable-mib-module.=
html

>>>>>>>>>>>>

>>>>>>>>>>>> My reading is that it spec=
ifically talks about

> configuration.

>>>>> While

>>>>>>>>>>>> the discussion started wit=
h "lets ban all write access",

> it may

>>>>> be

>>>>>>>>>>>> important to note that the=
 final statement does not say

> this.

>>>>> Hence,

>>>>>>>>>>>> I am not sure we have to r=
emove the MAX-ACCESS

> read-write.

>>>>>>>>>>>

>>>>>>>>>>> some of the vm options do caus=
e me existential peril. The

>>>>> remaining

>>>>>>>>>>> one's however do not. so I=
 think Juergen's assessment  is

> a

>>>>> correct one.

>>>>>>>>>>> The statement seems to be serv=
ing it's purpose!

>>>>>>>>>

>>>>>>>>>> Joel, can you please decrypt your =
message so that it

> becomes

>>>>> perhaps

>>>>>>>>>> actionable?

>>>>>>>>>

>>>>>>>>> I'm agreeing with you.

>>>>>>>>>

>>>>>>>>>> /js

>>>>>> --

>>>>>> Hirochika Asai <panda@hongo.wide.ad.jp>, The University of

> Tokyo

>>>>>>

>>>>>> _______________________________________________
>>>>>> OPSAWG mailing list

>>>>>> OPSAWG@ietf.org=


>>>>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>>>

>>>>> _______________________________________________

>>>>> OPSAWG mailing list

>>>>> OPSAWG@ietf.org=


>>>>> https://www.ietf.org/mailman/listinfo/opsawg

>>>>>

>>>> _______________________________________________

>>>> OPSAWG mailing list

>>>> OPSAWG@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/opsawg

>>>

>>> --

>>> Ladislav Lhotka, CZ.NIC Labs

>>> PGP Key ID: E74E8C0C

>>>

>>> _______________________________________________

>>> Netconf mailing list

>>> Netconf@ietf.org

>>> https://www.ietf.org/mailman/listinfo/netconf

>>>

>>

>

>

> ----------------------------------------------------------------------=
--

> --------

>

>

>> _______________________________________________

>> Netconf mailing list

>> Netconf@ietf.org

>> https://www.ietf.org/mailman/listinfo/netconf



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a11c14a7cc812aa04fa9ee2eb--


From nobody Fri May 30 07:44:40 2014
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 6CB5A1A0941 for ; Fri, 30 May 2014 07:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level: 
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 JWItkjnU4L_5 for ; Fri, 30 May 2014 07:44:36 -0700 (PDT)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9911A093A for ; Fri, 30 May 2014 07:44:35 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id a108so5504116qge.8 for ; Fri, 30 May 2014 07:44:30 -0700 (PDT)
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=SFnJkW+5TsGZdWjJojdouohM1h/4bOfLQsT0rr2VAQk=; b=DOYnf9wnEaK+IbR2x5B4+nSbdGi8SIEAit8j4uMGltX9WrqijIJX/1iKuQFt/G0UiH rjMOgrwSGEDf+BgtaxSnyzVyUu1R7lNGOrjp4QfdcQ9CCQGJOkI2MHNMbJot/PEaTuGc h5vSZj6INZdiQJmf5WSClaRIGzDAhjtbck0YT7CIbMgasnCHvk1MvH6tyJIaqIfQyyJE iSqFGM8q7qBneWtdQmG6fpJR1qMK6Be9SyB+FLy+lCQZH6TiJMvMWhUYfL/7rMLNgGhD 0fZx0i7+8fOki0A64se/RFkNO552KazXYunm3ss16c7H5sVaea/Wxpd1bvhkMb/YYMR8 JWpQ==
X-Gm-Message-State: ALoCoQkbkXqo1uUqXUyEZMXkj1+vwra5cf6NjCOzdZM4p9LMGt+eNCcsKVAGvVSSmN09xKi8B7BH
MIME-Version: 1.0
X-Received: by 10.140.27.23 with SMTP id 23mr20481707qgw.94.1401461070664; Fri, 30 May 2014 07:44:30 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 30 May 2014 07:44:30 -0700 (PDT)
In-Reply-To: <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net>
References:    <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net>
Date: Fri, 30 May 2014 07:44:30 -0700
Message-ID: 
From: Andy Bierman 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=001a11c14a7c495fe104fa9f1506
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/oWqni103YRlFxEBtvZzgYixh15Y
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 14:44:39 -0000

--001a11c14a7c495fe104fa9f1506
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 30, 2014 at 3:34 AM, t.petch  wrote:

> ----- Original Message -----
> From: "Andy Bierman" 
> To: "Ladislav Lhotka" 
> Cc: "Netconf" 
> Sent: Thursday, May 29, 2014 1:31 PM
> > On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka 
> wrote:
> >
> > > Hi,
> > >
> > > I am moving this discussion to the NETCONF mailing list.
> > >
> > > Andy Bierman  writes:
> > > ...
> > > >
> > > > I don't agree NETCONF/YANG persistence is ill-defined.
> > > > It is not uniform. There are a few variants, identified by
> > > > capability URIs.
> > >
> > > I'd say persistence is at least under-defined. For example, it
> doesn't
> > > seem to be clear from 6241 whether candidate is persistent.
> > >
> > >
> > OK
>
> Andy
>
> I am happy to characterise it as under-defined rather that ill-defined,
> but I think that the RFC are lacking.   We did have this discussion a
> few months back, and my point then was that if the only configuration
> datastore is running, then the assumption by implementers was that any
> change to it would immediately be persistent.  Seems reasonable, but not
> specified anywhere, and since running then has the opposite semantics
> with startup alongside it, well, that makes it less clearly defined, for
> me.
>
>

OK -- you are talking about a server that does not advertise :startup.
We used to call that "mirror mode", but that is not in the RFC.

Since no NETCONF implementation goes back to factory-default
config on every reboot, it seems vendors understand that persistence
of config data is required in real products, if not in the RFC.

This text in 1.4 says persistence is an implementation-specific feature:

   Note that the NETCONF protocol is focused on the information required
   to get the device into its desired running state.  The inclusion of
   other important, persistent data is implementation specific.  For
   example, user files and databases are not treated as configuration
   data by the NETCONF protocol.

   For example, if a local database of user authentication data is
   stored on the device, it is an implementation-dependent matter
   whether it is included in configuration data.

This text in 8.4.1 specifies mandatory persistence for confirmed commit.

   If the device reboots for any reason before the confirm timeout
   expires, the server MUST restore the configuration to its state
    before the confirmed commit was issued.



> As Lada points out, that is not the only such under-definition.
>
> Tom Petch
>
>
Andy



> > sec 8.3.5.2 says:
> >
> >    When a client fails with outstanding changes to the candidate
> >    configuration, recovery can be difficult.  To facilitate easy
> >    recovery, any outstanding changes are discarded when the lock is
> >    released, whether explicitly with the  operation or
> >    implicitly from session failure.
> >
> > IMO it is odd that candidate is cleaned up only if it was locked.
> > If a client edits candidate and then closes the session somehow the
> changes
> > are left behind.
> > The RFC is silent about the contents of candidate at boot-time. Our
> server
> > always boots
> > with the candidate and running having the same contents.  Otherwise
> the
> > candidate is
> > dirty at boot-time and cannot be locked by any session until a
> > discard-changes is invoked.
> > There is also no explicit requirement to boot with any particular
> candidate
> > contents, so
> > booting with the contents of running is compliant.
> >
> >
> >
> > > Lada
> > >
> >
> > Andy
> >
> >
> > >
> > > >
> > > > The XMLCONF design team (pre-4741) tried very hard to
> > > > get the router vendors to agree on a single transaction model
> > > > but it was way too big a change, and (of course) each vendor
> > > > thought their way was better, so the standard should use that.
> > > > We ended up with 3 configuration datastores (candidate, running,
> > > startup).
> > > > The transaction models that can be used with these datastores
> > > > are compatible with specific router CLI architectures.
> > > >
> > > > Two particular vendors do not agree on how to recover
> > > > from the "unreachable" problem.  If the operator makes
> > > > config changes that break the connectivity to the device,
> > > > then the device has to recover somehow.
> > > >
> > > >   M1: do not persist the changes until they are proven to
> > > >         be correct.  Force the device to reboot with the saved
> > > >         (known good) config if things go bad.
> > > >
> > > >   M2: persist the changes right away.  Pick some timeout
> > > >         and if the client does not follow up with a confirmation
> > > >         before the timeout, automatically revert to the version
> > > >         that was running before the transaction started.
> > > >
> > > > RFC 6241 could be more clear on the motivation for the
> > > > capabilities and operations that support various transaction
> models.
> > > > Maybe that is what you meant by 'ill-defined'.
> > > >
> > > >
> > > > Andy
> > > >
> > > > So the two objects controlling Notifications seem clearly
> configuration,
> > > >> whether or not the setting of them persists or is lost on reboot.
> You
> > > >> could create a YANG module which controls the setting of these
> two
> > > >> objects for SNMP usage but I think that even the IESG might see
> that
> > > >> that is an unusual approach, as opposed to making them read-write
> in
> > > >> SMI!
> > > >>
> > > >> When I first read the draft IESG statement, it was unclear to me
> whether
> > > >> or not the authors fully understood what they had written.
> > > >>
> > > >> Tom Petch
> > > >>
> > > >> > (*1)
> http://www.ietf.org/iesg/statement/writable-mib-module.html
> > > >> > (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> > > >> >
> > > >> > Hirochika
> > > >> >
> > > >> >
> > > >> > On May 27, 2014, at 3:55 AM, joel jaeggli 
> wrote:
> > > >> >
> > > >> > > yeah if you want to discuss it with the ops/management ADs
> and the
> > > >> > > chairs that's fine.
> > > >> > >
> > > >> > > I don't think there's a reason to involve the whole iesg.
> > > >> > >
> > > >> > > Thanks
> > > >> > > joel
> > > >> > >
> > > >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> > > >> > >> js and Joel,
> > > >> > >>
> > > >> > >> Thank you for your comments.
> > > >> > >>
> > > >> > >> I agree that the IESG statement seems to be talking about
> > > >> configuration,
> > > >> > >> but I cannot definitely say that the objects I listed in my
> > > >> previous E-mail
> > > >> > >> are out of the IESG statement's scope.
> > > >> > >>
> > > >> > >> I think it would be better to move this issue to the IESG,
> but I
> > > >> don't keep
> > > >> > >> up the procedure.  May I, as an author of the draft, send an
> E-mail
> > > >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG
> chairs to
> > > >> > >> handle it?
> > > >> > >>
> > > >> > >> Thank you.
> > > >> > >> Hirochika
> > > >> > >>
> > > >> > >>
> > > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli 
> > > wrote:
> > > >> > >>
> > > >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> > > >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli
> wrote:
> > > >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> > > >> > >>>>>> Asai,
> > > >> > >>>>>>
> > > >> > >>>>>> the IESG statement is here:
> > > >> > >>>>>>
> > > >> > >>>>>>
> http://www.ietf.org/iesg/statement/writable-mib-module.html
> > > >> > >>>>>>
> > > >> > >>>>>> My reading is that it specifically talks about
> configuration.
> > > >> While
> > > >> > >>>>>> the discussion started with "lets ban all write access",
> it may
> > > >> be
> > > >> > >>>>>> important to note that the final statement does not say
> this.
> > > >> Hence,
> > > >> > >>>>>> I am not sure we have to remove the MAX-ACCESS
> read-write.
> > > >> > >>>>>
> > > >> > >>>>> some of the vm options do cause me existential peril. The
> > > >> remaining
> > > >> > >>>>> one's however do not. so I think Juergen's assessment  is
> a
> > > >> correct one.
> > > >> > >>>>> The statement seems to be serving it's purpose!
> > > >> >>>>
> > > >> > >>>> Joel, can you please decrypt your message so that it
> becomes
> > > >> perhaps
> > > >> > >>>> actionable?
> > > >> > >>>
> > > >> > >>> I'm agreeing with you.
> > > >> > >>>
> > > >> > >>>> /js
> > > >> > --
> > > >> > Hirochika Asai , The University of
> Tokyo
> > > >> >
> > > >> > _______________________________________________
> > > >> > OPSAWG mailing list
> > > >> > OPSAWG@ietf.org
> > > >> > https://www.ietf.org/mailman/listinfo/opsawg
> > > >>
> > > >> _______________________________________________
> > > >> OPSAWG mailing list
> > > >> OPSAWG@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/opsawg
> > > >>
> > > > _______________________________________________
> > > > OPSAWG mailing list
> > > > OPSAWG@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/opsawg
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> >
>
>
> ------------------------------------------------------------------------
> --------
>
>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
>
>

--001a11c14a7c495fe104fa9f1506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Fri, May 30, 2014 at 3:34 AM, t.petch <ietfc@btconnect.com> wrote:


----- Original Message -----

From: "Andy Bierman" <an=
dy@yumaworks.com>

To: "Ladislav Lhotka" <lhotka=
@nic.cz>

Cc: "Netconf" <netconf@iet=
f.org>

Sent: Thursday, May 29, 2014 1:31 PM

> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka <lhotka@nic.cz>

wrote:

>

> > Hi,

> >

> > I am moving this discussion to the NETCONF mailing list.

> >

> > Andy Bierman <andy@yumaw=
orks.com> writes:

> > ...

> > >

> > > I don't agree NETCONF/YANG persistence is ill-defined.
> > > It is not uniform. There are a few variants, identified by
> > > capability URIs.

> >

> > I'd say persistence is at least under-defined. For example, i=
t

doesn't

> > seem to be clear from 6241 whether candidate is persistent.

> >

> >

> OK



Andy



I am happy to characterise it as under-defined rather that ill-defined,

but I think that the RFC are lacking. =A0 We did have this discussion a

few months back, and my point then was that if the only configuration

datastore is running, then the assumption by implementers was that any

change to it would immediately be persistent. =A0Seems reasonable, but not<=
br>
specified anywhere, and since running then has the opposite semantics

with startup alongside it, well, that makes it less clearly defined, for
me.




OK -- you are talking a=
bout a server that does not advertise :startup.
We used to call t=
hat "mirror mode", but that is not in the RFC.



Since no NETCONF implementation goes back to factory-default
config on every reboot, it seems vendors understand that persistence=

of config data is required in real products, if not in the RFC.<=
/div>


This text in 1.4 says persistence is an implementation-=
specific feature:
   Note that the NETCONF protocol is focused on =
the information required
   to get the device into its desired running state.  The inclusion of
   other important, persistent data is implementation specific.  For
   example, user files and databases are not treated as configuration
   data by the NETCONF protocol.

   For example, if a local database of user authentication data is
   stored on the device, it is an implementation-dependent matter
   whether it is included in configuration data.
This text in 8.4.1=
 specifies mandatory persistence for confirmed commit.


   If the device reboots for any reason=
 before the confirm timeout
   expires, the server MUST restore the configuration to its state
    before the confirmed commit was issued.
=A0=



As Lada points out, that is not the only such under-definition.



Tom Petch



Andy

=A0


> sec 8.3.5.2 says:

>

> =A0 =A0When a client fails with outstanding changes to the candidate
> =A0 =A0configuration, recovery can be difficult. =A0To facilitate easy=


> =A0 =A0recovery, any outstanding changes are discarded when the lock i=
s

> =A0 =A0released, whether explicitly with the <unlock> operation =
or

> =A0 =A0implicitly from session failure.

>

> IMO it is odd that candidate is cleaned up only if it was locked.

> If a client edits candidate and then closes the session somehow the
changes

> are left behind.

> The RFC is silent about the contents of candidate at boot-time. Our
server

> always boots

> with the candidate and running having the same contents. =A0Otherwise<=
br>
the

> candidate is

> dirty at boot-time and cannot be locked by any session until a

> discard-changes is invoked.

> There is also no explicit requirement to boot with any particular

candidate

> contents, so

> booting with the contents of running is compliant.

>

>

>

> > Lada

> >

>

> Andy

>

>

> >

> > >

> > > The XMLCONF design team (pre-4741) tried very hard to

> > > get the router vendors to agree on a single transaction mode=
l

> > > but it was way too big a change, and (of course) each vendor=


> > > thought their way was better, so the standard should use tha=
t.

> > > We ended up with 3 configuration datastores (candidate, runn=
ing,

> > startup).

> > > The transaction models that can be used with these datastore=
s

> > > are compatible with specific router CLI architectures.

> > >

> > > Two particular vendors do not agree on how to recover

> > > from the "unreachable" problem. =A0If the operator=
 makes

> > > config changes that break the connectivity to the device,
> > > then the device has to recover somehow.

> > >

> > > =A0 M1: do not persist the changes until they are proven to<=
br>
> > > =A0 =A0 =A0 =A0 be correct. =A0Force the device to reboot wi=
th the saved

> > > =A0 =A0 =A0 =A0 (known good) config if things go bad.

> > >

> > > =A0 M2: persist the changes right away. =A0Pick some timeout=


> > > =A0 =A0 =A0 =A0 and if the client does not follow up with a =
confirmation

> > > =A0 =A0 =A0 =A0 before the timeout, automatically revert to =
the version

> > > =A0 =A0 =A0 =A0 that was running before the transaction star=
ted.

> > >

> > > RFC 6241 could be more clear on the motivation for the

> > > capabilities and operations that support various transaction=


models.

> > > Maybe that is what you meant by 'ill-defined'.

> > >

> > >

> > > Andy

> > >

> > > So the two objects controlling Notifications seem clearly
configuration,

> > >> whether or not the setting of them persists or is lost o=
n reboot.

You

> > >> could create a YANG module which controls the setting of=
 these

two

> > >> objects for SNMP usage but I think that even the IESG mi=
ght see

that

> > >> that is an unusual approach, as opposed to making them r=
ead-write

in

> > >> SMI!

> > >>

> > >> When I first read the draft IESG statement, it was uncle=
ar to me

whether

> > >> or not the authors fully understood what they had writte=
n.

> > >>

> > >> Tom Petch

> > >>

> > >> > (*1)

http://www.ietf.org/iesg/statement/writable-mib-module.html<=
/a>

> > >> > (*2) http://tools.ietf.org/html/draft-ie=
tf-opsawg-vmm-mib-00

> > >> >

> > >> > Hirochika

> > >> >

> > >> >

> > >> > On May 27, 2014, at 3:55 AM, joel jaeggli <joelja@bogus.com>

wrote:

> > >> >

> > >> > > yeah if you want to discuss it with the ops/ma=
nagement ADs

and the

> > >> > > chairs that's fine.

> > >> > >

> > >> > > I don't think there's a reason to invo=
lve the whole iesg.

> > >> > >

> > >> > > Thanks

> > >> > > joel

> > >> > >

> > >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> > >> > >> js and Joel,

> > >> > >>

> > >> > >> Thank you for your comments.

> > >> > >>

> > >> > >> I agree that the IESG statement seems to b=
e talking about

> > >> configuration,

> > >> > >> but I cannot definitely say that the objec=
ts I listed in my

> > >> previous E-mail

> > >> > >> are out of the IESG statement's scope.=


> > >> > >>

> > >> > >> I think it would be better to move this is=
sue to the IESG,

but I

> > >> don't keep

> > >> > >> up the procedure. =A0May I, as an author o=
f the draft, send an

E-mail

> > >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG

chairs to

> > >> > >> handle it?

> > >> > >>

> > >> > >> Thank you.

> > >> > >> Hirochika

> > >> > >>

> > >> > >>

> > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli =
<joelja@bogus.com>

> > wrote:

> > >> > >>

> > >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwae=
lder wrote:

> > >> > >>>> On Mon, May 26, 2014 at 08:42:47AM=
 -0700, joel jaeggli

wrote:

> > >> > >>>>> On 5/26/14, 2:31 AM, Juergen S=
choenwaelder wrote:

> > >> > >>>>>> Asai,

> > >> > >>>>>>

> > >> > >>>>>> the IESG statement is here=
:

> > >> > >>>>>>

> > >> > >>>>>>

http://www.ietf.org/iesg/statement/writable-mib-module.html<=
/a>

> > >> > >>>>>>

> > >> > >>>>>> My reading is that it spec=
ifically talks about

configuration.

> > >> While

> > >> > >>>>>> the discussion started wit=
h "lets ban all write access",

it may

> > >> be

> > >> > >>>>>> important to note that the=
 final statement does not say

this.

> > >> Hence,

> > >> > >>>>>> I am not sure we have to r=
emove the MAX-ACCESS

read-write.

> > >> > >>>>>

> > >> > >>>>> some of the vm options do caus=
e me existential peril. The

> > >> remaining

> > >> > >>>>> one's however do not. so I=
 think Juergen's assessment =A0is

a

> > >> correct one.

> > >> > >>>>> The statement seems to be serv=
ing it's purpose!

> > >> >>>>

> > >> > >>>> Joel, can you please decrypt your =
message so that it

becomes

> > >> perhaps

> > >> > >>>> actionable?

> > >> > >>>

> > >> > >>> I'm agreeing with you.

> > >> > >>>

> > >> > >>>> /js

> > >> > --

> > >> > Hirochika Asai <panda@hongo.wide.ad.jp>, The University of

Tokyo

> > >> >

> > >> > _______________________________________________

> > >> > OPSAWG mailing list

> > >> > OPSAWG@ietf.org<=
/a>

> > >> > https://www.ietf.org/mailman/listinfo/opsawg
> > >>

> > >> _______________________________________________

> > >> OPSAWG mailing list

> > >> OPSAWG@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/opsawg

> > >>

> > > _______________________________________________

> > > OPSAWG mailing list

> > > OPSAWG@ietf.org

> > > https://www.ietf.org/mailman/listinfo/opsawg

> >

> > --

> > Ladislav Lhotka, CZ.NIC Labs

> > PGP Key ID: E74E8C0C

> >

> > _______________________________________________

> > Netconf mailing list

> > Netconf@ietf.org

> > https://www.ietf.org/mailman/listinfo/netconf

> >

>





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





> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org

> https://www.ietf.org/mailman/listinfo/netconf

>







--001a11c14a7c495fe104fa9f1506--


From nobody Fri May 30 07:58:49 2014
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 7C8B61A0922 for ; Fri, 30 May 2014 07:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 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_15=0.6, RP_MATCHES_RCVD=-0.651] 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 XqZo0BrtPC3q for ; Fri, 30 May 2014 07:58:45 -0700 (PDT)
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 016741A08E6 for ; Fri, 30 May 2014 07:58:45 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7C5AA13F890; Fri, 30 May 2014 16:58:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401461919; bh=pavBvfSMV/dwPQDH73ylTx3tmZy907UecHbNs6fD6ww=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZA5rUw1j6kgquHa/5rbtOXp4x22isH6582eVbzQ69etyR4sVOFewr9DIvGWdGYLTQ ZkIVeoe+4U9c9G0d18KmJZDHhq+y3bWGLyZcZTXSl68vyxKUyBl33U1RwRZIZXaugZ 0soYLsCDgO+yDuI5gUV/kD2Z/dpQ5xKRyFrUGs+M=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 30 May 2014 16:58:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net>  
To: Andy Bierman 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/CmikmCA0qdD-nWwlZeIB6CPyi2E
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 14:58:47 -0000

On 30 May 2014, at 16:30, Andy Bierman  wrote:

>=20
>=20
>=20
> On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka  =
wrote:
>=20
> On 30 May 2014, at 12:34, t.petch  wrote:
>=20
> > ----- Original Message -----
> > From: "Andy Bierman" 
> > To: "Ladislav Lhotka" 
> > Cc: "Netconf" 
> > Sent: Thursday, May 29, 2014 1:31 PM
> >> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka 
> > wrote:
> >>
> >>> Hi,
> >>>
> >>> I am moving this discussion to the NETCONF mailing list.
> >>>
> >>> Andy Bierman  writes:
> >>> ...
> >>>>
> >>>> I don't agree NETCONF/YANG persistence is ill-defined.
> >>>> It is not uniform. There are a few variants, identified by
> >>>> capability URIs.
> >>>
> >>> I'd say persistence is at least under-defined. For example, it
> > doesn't
> >>> seem to be clear from 6241 whether candidate is persistent.
> >>>
> >>>
> >> OK
> >
> > Andy
> >
> > I am happy to characterise it as under-defined rather that =
ill-defined,
> > but I think that the RFC are lacking.   We did have this discussion =
a
> > few months back, and my point then was that if the only =
configuration
> > datastore is running, then the assumption by implementers was that =
any
> > change to it would immediately be persistent.  Seems reasonable, but =
not
> > specified anywhere, and since running then has the opposite =
semantics
> > with startup alongside it, well, that makes it less clearly defined, =
for
> > me.
> >
> > As Lada points out, that is not the only such under-definition.
>=20
> Another thing that puzzles me:
>=20
> Let=92s say a client edits the value of parameter X in running. The =
new value is immediately projected into operational state. Then later =
the state value gets changed by some means external to NETCONF. In what =
event, if any, will the value of X be reset to the value that=92s =
configured in running?
>=20
>=20
> If state variables and config variables interact, then the =
description-stmt
> should explain this data-model specific behavior.

They needn=92t interact within the NETCONF realm. For example: =
configured static routes appear in a RIB, but then some of the routes =
are deleted from the RIB via I2RS. So the RIB and config are out of =
sync.
Will the configured routes ever be re-installed, e.g. after running =
changes again?

Lada

>=20
>=20
> Lada
>=20
> Andy
> =20
>=20
> >
> > Tom Petch
> >
> >> sec 8.3.5.2 says:
> >>
> >>   When a client fails with outstanding changes to the candidate
> >>   configuration, recovery can be difficult.  To facilitate easy
> >>   recovery, any outstanding changes are discarded when the lock is
> >>   released, whether explicitly with the  operation or
> >>   implicitly from session failure.
> >>
> >> IMO it is odd that candidate is cleaned up only if it was locked.
> >> If a client edits candidate and then closes the session somehow the
> > changes
> >> are left behind.
> >> The RFC is silent about the contents of candidate at boot-time. Our
> > server
> >> always boots
> >> with the candidate and running having the same contents.  Otherwise
> > the
> >> candidate is
> >> dirty at boot-time and cannot be locked by any session until a
> >> discard-changes is invoked.
> >> There is also no explicit requirement to boot with any particular
> > candidate
> >> contents, so
> >> booting with the contents of running is compliant.
> >>
> >>
> >>
> >>> Lada
> >>>
> >>
> >> Andy
> >>
> >>
> >>>
> >>>>
> >>>> The XMLCONF design team (pre-4741) tried very hard to
> >>>> get the router vendors to agree on a single transaction model
> >>>> but it was way too big a change, and (of course) each vendor
> >>>> thought their way was better, so the standard should use that.
> >>>> We ended up with 3 configuration datastores (candidate, running,
> >>> startup).
> >>>> The transaction models that can be used with these datastores
> >>>> are compatible with specific router CLI architectures.
> >>>>
> >>>> Two particular vendors do not agree on how to recover
> >>>> from the "unreachable" problem.  If the operator makes
> >>>> config changes that break the connectivity to the device,
> >>>> then the device has to recover somehow.
> >>>>
> >>>>  M1: do not persist the changes until they are proven to
> >>>>        be correct.  Force the device to reboot with the saved
> >>>>        (known good) config if things go bad.
> >>>>
> >>>>  M2: persist the changes right away.  Pick some timeout
> >>>>        and if the client does not follow up with a confirmation
> >>>>        before the timeout, automatically revert to the version
> >>>>        that was running before the transaction started.
> >>>>
> >>>> RFC 6241 could be more clear on the motivation for the
> >>>> capabilities and operations that support various transaction
> > models.
> >>>> Maybe that is what you meant by 'ill-defined'.
> >>>>
> >>>>
> >>>> Andy
> >>>>
> >>>> So the two objects controlling Notifications seem clearly
> > configuration,
> >>>>> whether or not the setting of them persists or is lost on =
reboot.
> > You
> >>>>> could create a YANG module which controls the setting of these
> > two
> >>>>> objects for SNMP usage but I think that even the IESG might see
> > that
> >>>>> that is an unusual approach, as opposed to making them =
read-write
> > in
> >>>>> SMI!
> >>>>>
> >>>>> When I first read the draft IESG statement, it was unclear to me
> > whether
> >>>>> or not the authors fully understood what they had written.
> >>>>>
> >>>>> Tom Petch
> >>>>>
> >>>>>> (*1)
> > http://www.ietf.org/iesg/statement/writable-mib-module.html
> >>>>>> (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> >>>>>>
> >>>>>> Hirochika
> >>>>>>
> >>>>>>
> >>>>>> On May 27, 2014, at 3:55 AM, joel jaeggli 
> > wrote:
> >>>>>>
> >>>>>>> yeah if you want to discuss it with the ops/management ADs
> > and the
> >>>>>>> chairs that's fine.
> >>>>>>>
> >>>>>>> I don't think there's a reason to involve the whole iesg.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> joel
> >>>>>>>
> >>>>>>> On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> >>>>>>>> js and Joel,
> >>>>>>>>
> >>>>>>>> Thank you for your comments.
> >>>>>>>>
> >>>>>>>> I agree that the IESG statement seems to be talking about
> >>>>> configuration,
> >>>>>>>> but I cannot definitely say that the objects I listed in my
> >>>>> previous E-mail
> >>>>>>>> are out of the IESG statement's scope.
> >>>>>>>>
> >>>>>>>> I think it would be better to move this issue to the IESG,
> > but I
> >>>>> don't keep
> >>>>>>>> up the procedure.  May I, as an author of the draft, send an
> > E-mail
> >>>>>>>> stating this issue to iesg@ietf.org, CCing WG? Or ask WG
> > chairs to
> >>>>>>>> handle it?
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>> Hirochika
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On May 27, 2014, at 1:24 AM, joel jaeggli 
> >>> wrote:
> >>>>>>>>
> >>>>>>>>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> >>>>>>>>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli
> > wrote:
> >>>>>>>>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> >>>>>>>>>>>> Asai,
> >>>>>>>>>>>>
> >>>>>>>>>>>> the IESG statement is here:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> > http://www.ietf.org/iesg/statement/writable-mib-module.html
> >>>>>>>>>>>>
> >>>>>>>>>>>> My reading is that it specifically talks about
> > configuration.
> >>>>> While
> >>>>>>>>>>>> the discussion started with "lets ban all write access",
> > it may
> >>>>> be
> >>>>>>>>>>>> important to note that the final statement does not say
> > this.
> >>>>> Hence,
> >>>>>>>>>>>> I am not sure we have to remove the MAX-ACCESS
> > read-write.
> >>>>>>>>>>>
> >>>>>>>>>>> some of the vm options do cause me existential peril. The
> >>>>> remaining
> >>>>>>>>>>> one's however do not. so I think Juergen's assessment  is
> > a
> >>>>> correct one.
> >>>>>>>>>>> The statement seems to be serving it's purpose!
> >>>>>>>>>
> >>>>>>>>>> Joel, can you please decrypt your message so that it
> > becomes
> >>>>> perhaps
> >>>>>>>>>> actionable?
> >>>>>>>>>
> >>>>>>>>> I'm agreeing with you.
> >>>>>>>>>
> >>>>>>>>>> /js
> >>>>>> --
> >>>>>> Hirochika Asai , The University of
> > Tokyo
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> OPSAWG mailing list
> >>>>>> OPSAWG@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/opsawg
> >>>>>
> >>>>> _______________________________________________
> >>>>> OPSAWG mailing list
> >>>>> OPSAWG@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/opsawg
> >>>>>
> >>>> _______________________________________________
> >>>> OPSAWG mailing list
> >>>> OPSAWG@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/opsawg
> >>>
> >>> --
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> Netconf@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >>>
> >>
> >
> >
> > =
------------------------------------------------------------------------
> > --------
> >
> >
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

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





From nobody Fri May 30 08:07:22 2014
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 986C81A0997 for ; Fri, 30 May 2014 08:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level: 
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 pPWiDBaOwIap for ; Fri, 30 May 2014 08:07:01 -0700 (PDT)
Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51011A0924 for ; Fri, 30 May 2014 08:07:01 -0700 (PDT)
Received: by mail-qg0-f41.google.com with SMTP id j5so5676806qga.28 for ; Fri, 30 May 2014 08:06:57 -0700 (PDT)
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=wXIL72C9atS2VKU/+y6vt6TYyWjFF11ceIXIln/JQxc=; b=Qg94NhXgUlxL/60tvJ09dA7kH7v+XOnVZ4NEPqG6IRBwRBw+MfMOlR081pYGXB9MuJ V4gxn9TS/FBdQt0WFcaefoMkGArQ9MotEq8Rd0CowffQ5ZrwLALd+nLRce1kQipsZbaS 0cKPXaj0mC3upOA7li5Loyah9KfHBVuUuG2AMJ+ugX/4M+sxYlqg9oq0xnxchI5RJTNt oLb4T9HfkILzzffF/eJpALNDaMfb5y4mKf2G10hgRmJQe9DFWAdzBPivhEzVr4JWpX06 f88FgxKTMaDh6bTy19/LoOW1P+9G0KR+QpdTydmamxwk/TopRVy1hUg+sl+GbFj2U1Sp iUEw==
X-Gm-Message-State: ALoCoQk1NaSKu+9eYAemUt8fVuT59UfGpaXYSQtz0/xelKKFqdO/pYSX0k0BXrH5Akk+NixWrZyX
MIME-Version: 1.0
X-Received: by 10.224.55.6 with SMTP id s6mr21924565qag.7.1401462416948; Fri, 30 May 2014 08:06:56 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 30 May 2014 08:06:56 -0700 (PDT)
In-Reply-To: 
References:    <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net>   
Date: Fri, 30 May 2014 08:06:56 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e0153705e8777b404fa9f65d9
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GI1GqriwU2oM8iFb-wVU2Pg3HOE
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 15:07:10 -0000

--089e0153705e8777b404fa9f65d9
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 30, 2014 at 7:58 AM, Ladislav Lhotka  wrote:

>
> On 30 May 2014, at 16:30, Andy Bierman  wrote:
>
> >
> >
> >
> > On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka  wrote:
> >
> > On 30 May 2014, at 12:34, t.petch  wrote:
> >
> > > ----- Original Message -----
> > > From: "Andy Bierman" 
> > > To: "Ladislav Lhotka" 
> > > Cc: "Netconf" 
> > > Sent: Thursday, May 29, 2014 1:31 PM
> > >> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka 
> > > wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I am moving this discussion to the NETCONF mailing list.
> > >>>
> > >>> Andy Bierman  writes:
> > >>> ...
> > >>>>
> > >>>> I don't agree NETCONF/YANG persistence is ill-defined.
> > >>>> It is not uniform. There are a few variants, identified by
> > >>>> capability URIs.
> > >>>
> > >>> I'd say persistence is at least under-defined. For example, it
> > > doesn't
> > >>> seem to be clear from 6241 whether candidate is persistent.
> > >>>
> > >>>
> > >> OK
> > >
> > > Andy
> > >
> > > I am happy to characterise it as under-defined rather that ill-defined,
> > > but I think that the RFC are lacking.   We did have this discussion a
> > > few months back, and my point then was that if the only configuration
> > > datastore is running, then the assumption by implementers was that any
> > > change to it would immediately be persistent.  Seems reasonable, but
> not
> > > specified anywhere, and since running then has the opposite semantics
> > > with startup alongside it, well, that makes it less clearly defined,
> for
> > > me.
> > >
> > > As Lada points out, that is not the only such under-definition.
> >
> > Another thing that puzzles me:
> >
> > Let's say a client edits the value of parameter X in running. The new
> value is immediately projected into operational state. Then later the state
> value gets changed by some means external to NETCONF. In what event, if
> any, will the value of X be reset to the value that's configured in running?
> >
> >
> > If state variables and config variables interact, then the
> description-stmt
> > should explain this data-model specific behavior.
>
> They needn't interact within the NETCONF realm. For example: configured
> static routes appear in a RIB, but then some of the routes are deleted from
> the RIB via I2RS. So the RIB and config are out of sync.
> Will the configured routes ever be re-installed, e.g. after running
> changes again?
>
>
>From my understanding of I2RS architecture, the local config could
be assigned a priority. It is likely an implementation detail how the
system re-installs config that was replaced by state, and then that state
changed
or was removed by I2RS.  If vendors or other standards add new behavior
to the system outside the scope of NETCONF, then they should specify
how they interact with the configuration.


Lada
>

Andy


>
> >
> >
> > Lada
> >
> > Andy
> >
> >
> > >
> > > Tom Petch
> > >
> > >> sec 8.3.5.2 says:
> > >>
> > >>   When a client fails with outstanding changes to the candidate
> > >>   configuration, recovery can be difficult.  To facilitate easy
> > >>   recovery, any outstanding changes are discarded when the lock is
> > >>   released, whether explicitly with the  operation or
> > >>   implicitly from session failure.
> > >>
> > >> IMO it is odd that candidate is cleaned up only if it was locked.
> > >> If a client edits candidate and then closes the session somehow the
> > > changes
> > >> are left behind.
> > >> The RFC is silent about the contents of candidate at boot-time. Our
> > > server
> > >> always boots
> > >> with the candidate and running having the same contents.  Otherwise
> > > the
> > >> candidate is
> > >> dirty at boot-time and cannot be locked by any session until a
> > >> discard-changes is invoked.
> > >> There is also no explicit requirement to boot with any particular
> > > candidate
> > >> contents, so
> > >> booting with the contents of running is compliant.
> > >>
> > >>
> > >>
> > >>> Lada
> > >>>
> > >>
> > >> Andy
> > >>
> > >>
> > >>>
> > >>>>
> > >>>> The XMLCONF design team (pre-4741) tried very hard to
> > >>>> get the router vendors to agree on a single transaction model
> > >>>> but it was way too big a change, and (of course) each vendor
> > >>>> thought their way was better, so the standard should use that.
> > >>>> We ended up with 3 configuration datastores (candidate, running,
> > >>> startup).
> > >>>> The transaction models that can be used with these datastores
> > >>>> are compatible with specific router CLI architectures.
> > >>>>
> > >>>> Two particular vendors do not agree on how to recover
> > >>>> from the "unreachable" problem.  If the operator makes
> > >>>> config changes that break the connectivity to the device,
> > >>>> then the device has to recover somehow.
> > >>>>
> > >>>>  M1: do not persist the changes until they are proven to
> > >>>>        be correct.  Force the device to reboot with the saved
> > >>>>        (known good) config if things go bad.
> > >>>>
> > >>>>  M2: persist the changes right away.  Pick some timeout
> > >>>>        and if the client does not follow up with a confirmation
> > >>>>        before the timeout, automatically revert to the version
> > >>>>        that was running before the transaction started.
> > >>>>
> > >>>> RFC 6241 could be more clear on the motivation for the
> > >>>> capabilities and operations that support various transaction
> > > models.
> > >>>> Maybe that is what you meant by 'ill-defined'.
> > >>>>
> > >>>>
> > >>>> Andy
> > >>>>
> > >>>> So the two objects controlling Notifications seem clearly
> > > configuration,
> > >>>>> whether or not the setting of them persists or is lost on reboot.
> > > You
> > >>>>> could create a YANG module which controls the setting of these
> > > two
> > >>>>> objects for SNMP usage but I think that even the IESG might see
> > > that
> > >>>>> that is an unusual approach, as opposed to making them read-write
> > > in
> > >>>>> SMI!
> > >>>>>
> > >>>>> When I first read the draft IESG statement, it was unclear to me
> > > whether
> > >>>>> or not the authors fully understood what they had written.
> > >>>>>
> > >>>>> Tom Petch
> > >>>>>
> > >>>>>> (*1)
> > > http://www.ietf.org/iesg/statement/writable-mib-module.html
> > >>>>>> (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> > >>>>>>
> > >>>>>> Hirochika
> > >>>>>>
> > >>>>>>
> > >>>>>> On May 27, 2014, at 3:55 AM, joel jaeggli 
> > > wrote:
> > >>>>>>
> > >>>>>>> yeah if you want to discuss it with the ops/management ADs
> > > and the
> > >>>>>>> chairs that's fine.
> > >>>>>>>
> > >>>>>>> I don't think there's a reason to involve the whole iesg.
> > >>>>>>>
> > >>>>>>> Thanks
> > >>>>>>> joel
> > >>>>>>>
> > >>>>>>> On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> > >>>>>>>> js and Joel,
> > >>>>>>>>
> > >>>>>>>> Thank you for your comments.
> > >>>>>>>>
> > >>>>>>>> I agree that the IESG statement seems to be talking about
> > >>>>> configuration,
> > >>>>>>>> but I cannot definitely say that the objects I listed in my
> > >>>>> previous E-mail
> > >>>>>>>> are out of the IESG statement's scope.
> > >>>>>>>>
> > >>>>>>>> I think it would be better to move this issue to the IESG,
> > > but I
> > >>>>> don't keep
> > >>>>>>>> up the procedure.  May I, as an author of the draft, send an
> > > E-mail
> > >>>>>>>> stating this issue to iesg@ietf.org, CCing WG? Or ask WG
> > > chairs to
> > >>>>>>>> handle it?
> > >>>>>>>>
> > >>>>>>>> Thank you.
> > >>>>>>>> Hirochika
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On May 27, 2014, at 1:24 AM, joel jaeggli 
> > >>> wrote:
> > >>>>>>>>
> > >>>>>>>>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> > >>>>>>>>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli
> > > wrote:
> > >>>>>>>>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> > >>>>>>>>>>>> Asai,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> the IESG statement is here:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > > http://www.ietf.org/iesg/statement/writable-mib-module.html
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> My reading is that it specifically talks about
> > > configuration.
> > >>>>> While
> > >>>>>>>>>>>> the discussion started with "lets ban all write access",
> > > it may
> > >>>>> be
> > >>>>>>>>>>>> important to note that the final statement does not say
> > > this.
> > >>>>> Hence,
> > >>>>>>>>>>>> I am not sure we have to remove the MAX-ACCESS
> > > read-write.
> > >>>>>>>>>>>
> > >>>>>>>>>>> some of the vm options do cause me existential peril. The
> > >>>>> remaining
> > >>>>>>>>>>> one's however do not. so I think Juergen's assessment  is
> > > a
> > >>>>> correct one.
> > >>>>>>>>>>> The statement seems to be serving it's purpose!
> > >>>>>>>>>
> > >>>>>>>>>> Joel, can you please decrypt your message so that it
> > > becomes
> > >>>>> perhaps
> > >>>>>>>>>> actionable?
> > >>>>>>>>>
> > >>>>>>>>> I'm agreeing with you.
> > >>>>>>>>>
> > >>>>>>>>>> /js
> > >>>>>> --
> > >>>>>> Hirochika Asai , The University of
> > > Tokyo
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> OPSAWG mailing list
> > >>>>>> OPSAWG@ietf.org
> > >>>>>> https://www.ietf.org/mailman/listinfo/opsawg
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> OPSAWG mailing list
> > >>>>> OPSAWG@ietf.org
> > >>>>> https://www.ietf.org/mailman/listinfo/opsawg
> > >>>>>
> > >>>> _______________________________________________
> > >>>> OPSAWG mailing list
> > >>>> OPSAWG@ietf.org
> > >>>> https://www.ietf.org/mailman/listinfo/opsawg
> > >>>
> > >>> --
> > >>> Ladislav Lhotka, CZ.NIC Labs
> > >>> PGP Key ID: E74E8C0C
> > >>>
> > >>> _______________________________________________
> > >>> Netconf mailing list
> > >>> Netconf@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/netconf
> > >>>
> > >>
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > > --------
> > >
> > >
> > >> _______________________________________________
> > >> Netconf mailing list
> > >> Netconf@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netconf
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--089e0153705e8777b404fa9f65d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Fri, May 30, 2014 at 7:58 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:




On 30 May 2014, at 16:30, Andy Bierman <andy@yumaworks.com> wrote:



>

>

>

> On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> On 30 May 2014, at 12:34, t.petch <ietfc@btconnect.com> wrote:

>

> > ----- Original Message -----

> > From: "Andy Bierman" <andy@yumaworks.com>

> > To: "Ladislav Lhotka" <lhotka@nic.cz>

> > Cc: "Netconf" <n=
etconf@ietf.org>

> > Sent: Thursday, May 29, 2014 1:31 PM

> >> On Thu, May 29, 2014 at 4:37 AM, Ladislav Lhotka <lhotka@nic.cz>

> > wrote:

> >>

> >>> Hi,

> >>>

> >>> I am moving this discussion to the NETCONF mailing list.<=
br>
> >>>

> >>> Andy Bierman <an=
dy@yumaworks.com> writes:

> >>> ...

> >>>>

> >>>> I don't agree NETCONF/YANG persistence is ill-def=
ined.

> >>>> It is not uniform. There are a few variants, identifi=
ed by

> >>>> capability URIs.

> >>>

> >>> I'd say persistence is at least under-defined. For ex=
ample, it

> > doesn't

> >>> seem to be clear from 6241 whether candidate is persisten=
t.

> >>>

> >>>

> >> OK

> >

> > Andy

> >

> > I am happy to characterise it as under-defined rather that ill-de=
fined,

> > but I think that the RFC are lacking.   We did have this dis=
cussion a

> > few months back, and my point then was that if the only configura=
tion

> > datastore is running, then the assumption by implementers was tha=
t any

> > change to it would immediately be persistent.  Seems reasona=
ble, but not

> > specified anywhere, and since running then has the opposite seman=
tics

> > with startup alongside it, well, that makes it less clearly defin=
ed, for

> > me.

> >

> > As Lada points out, that is not the only such under-definition.
>

> Another thing that puzzles me:

>

> Let’s say a client edits the value of parameter X in running. Th=
e new value is immediately projected into operational state. Then later the=
 state value gets changed by some means external to NETCONF. In what event,=
 if any, will the value of X be reset to the value that’s configured =
in running?


>

>

> If state variables and config variables interact, then the description=
-stmt

> should explain this data-model specific behavior.



They needn’t interact within the NETCONF realm. For example: configur=
ed static routes appear in a RIB, but then some of the routes are deleted f=
rom the RIB via I2RS. So the RIB and config are out of sync.

Will the configured routes ever be re-installed, e.g. after running changes=
 again?



From my understanding of I2RS architec=
ture, the local config could
be assigned a priority. It is likely=
 an implementation detail how the
system re-installs config that =
was replaced by state, and then that state changed


or was removed by I2RS.  If vendors or other standards add new be=
havior
to the system outside the scope of NETCONF, then they shou=
ld specify
how they interact with the configuration.




Lada

Andy
 



>

>

> Lada

>

> Andy

>

>

> >

> > Tom Petch

> >

> >> sec 8.3.5.2 says:

> >>

> >>   When a client fails with outstanding changes to the ca=
ndidate

> >>   configuration, recovery can be difficult.  To fac=
ilitate easy

> >>   recovery, any outstanding changes are discarded when t=
he lock is

> >>   released, whether explicitly with the <unlock> o=
peration or

> >>   implicitly from session failure.

> >>

> >> IMO it is odd that candidate is cleaned up only if it was loc=
ked.

> >> If a client edits candidate and then closes the session someh=
ow the

> > changes

> >> are left behind.

> >> The RFC is silent about the contents of candidate at boot-tim=
e. Our

> > server

> >> always boots

> >> with the candidate and running having the same contents. &nbs=
p;Otherwise

> > the

> >> candidate is

> >> dirty at boot-time and cannot be locked by any session until =
a

> >> discard-changes is invoked.

> >> There is also no explicit requirement to boot with any partic=
ular

> > candidate

> >> contents, so

> >> booting with the contents of running is compliant.

> >>

> >>

> >>

> >>> Lada

> >>>

> >>

> >> Andy

> >>

> >>

> >>>

> >>>>

> >>>> The XMLCONF design team (pre-4741) tried very hard to=


> >>>> get the router vendors to agree on a single transacti=
on model

> >>>> but it was way too big a change, and (of course) each=
 vendor

> >>>> thought their way was better, so the standard should =
use that.

> >>>> We ended up with 3 configuration datastores (candidat=
e, running,

> >>> startup).

> >>>> The transaction models that can be used with these da=
tastores

> >>>> are compatible with specific router CLI architectures=
.

> >>>>

> >>>> Two particular vendors do not agree on how to recover=


> >>>> from the "unreachable" problem.  If th=
e operator makes

> >>>> config changes that break the connectivity to the dev=
ice,

> >>>> then the device has to recover somehow.

> >>>>

> >>>>  M1: do not persist the changes until they are p=
roven to

> >>>>        be correct.  Force th=
e device to reboot with the saved

> >>>>        (known good) config if thi=
ngs go bad.

> >>>>

> >>>>  M2: persist the changes right away.  Pick =
some timeout

> >>>>        and if the client does not=
 follow up with a confirmation

> >>>>        before the timeout, automa=
tically revert to the version

> >>>>        that was running before th=
e transaction started.

> >>>>

> >>>> RFC 6241 could be more clear on the motivation for th=
e

> >>>> capabilities and operations that support various tran=
saction

> > models.

> >>>> Maybe that is what you meant by 'ill-defined'=
.

> >>>>

> >>>>

> >>>> Andy

> >>>>

> >>>> So the two objects controlling Notifications seem cle=
arly

> > configuration,

> >>>>> whether or not the setting of them persists or is=
 lost on reboot.

> > You

> >>>>> could create a YANG module which controls the set=
ting of these

> > two

> >>>>> objects for SNMP usage but I think that even the =
IESG might see

> > that

> >>>>> that is an unusual approach, as opposed to making=
 them read-write

> > in

> >>>>> SMI!

> >>>>>

> >>>>> When I first read the draft IESG statement, it wa=
s unclear to me

> > whether

> >>>>> or not the authors fully understood what they had=
 written.

> >>>>>

> >>>>> Tom Petch

> >>>>>

> >>>>>> (*1)

> > http://www.ietf.org/iesg/statement/writable-mib-mo=
dule.html

> >>>>>> (*2) http://tools.ietf.org/html/dr=
aft-ietf-opsawg-vmm-mib-00

> >>>>>>

> >>>>>> Hirochika

> >>>>>>

> >>>>>>

> >>>>>> On May 27, 2014, at 3:55 AM, joel jaeggli <=
;joelja@bogus.com>

> > wrote:

> >>>>>>

> >>>>>>> yeah if you want to discuss it with the o=
ps/management ADs

> > and the

> >>>>>>> chairs that's fine.

> >>>>>>>

> >>>>>>> I don't think there's a reason to=
 involve the whole iesg.

> >>>>>>>

> >>>>>>> Thanks

> >>>>>>> joel

> >>>>>>>

> >>>>>>> On 5/26/14, 10:48 AM, Hirochika Asai wrot=
e:

> >>>>>>>> js and Joel,

> >>>>>>>>

> >>>>>>>> Thank you for your comments.

> >>>>>>>>

> >>>>>>>> I agree that the IESG statement seems=
 to be talking about

> >>>>> configuration,

> >>>>>>>> but I cannot definitely say that the =
objects I listed in my

> >>>>> previous E-mail

> >>>>>>>> are out of the IESG statement's s=
cope.

> >>>>>>>>

> >>>>>>>> I think it would be better to move th=
is issue to the IESG,

> > but I

> >>>>> don't keep

> >>>>>>>> up the procedure.  May I, as an =
author of the draft, send an

> > E-mail

> >>>>>>>> stating this issue to iesg@ietf.org, CCing WG? Or ask WG

> > chairs to

> >>>>>>>> handle it?

> >>>>>>>>

> >>>>>>>> Thank you.

> >>>>>>>> Hirochika

> >>>>>>>>

> >>>>>>>>

> >>>>>>>> On May 27, 2014, at 1:24 AM, joel jae=
ggli <joelja@bogus.com>

> >>> wrote:

> >>>>>>>>

> >>>>>>>>> On 5/26/14, 9:20 AM, Juergen Scho=
enwaelder wrote:

> >>>>>>>>>> On Mon, May 26, 2014 at 08:42=
:47AM -0700, joel jaeggli

> > wrote:

> >>>>>>>>>>> On 5/26/14, 2:31 AM, Juer=
gen Schoenwaelder wrote:

> >>>>>>>>>>>> Asai,

> >>>>>>>>>>>>

> >>>>>>>>>>>> the IESG statement is=
 here:

> >>>>>>>>>>>>

> >>>>>>>>>>>>

> > http://www.ietf.org/iesg/statement/writable-mib-mo=
dule.html

> >>>>>>>>>>>>

> >>>>>>>>>>>> My reading is that it=
 specifically talks about

> > configuration.

> >>>>> While

> >>>>>>>>>>>> the discussion starte=
d with "lets ban all write access",

> > it may

> >>>>> be

> >>>>>>>>>>>> important to note tha=
t the final statement does not say

> > this.

> >>>>> Hence,

> >>>>>>>>>>>> I am not sure we have=
 to remove the MAX-ACCESS

> > read-write.

> >>>>>>>>>>>

> >>>>>>>>>>> some of the vm options do=
 cause me existential peril. The

> >>>>> remaining

> >>>>>>>>>>> one's however do not.=
 so I think Juergen's assessment  is

> > a

> >>>>> correct one.

> >>>>>>>>>>> The statement seems to be=
 serving it's purpose!

> >>>>>>>>>

> >>>>>>>>>> Joel, can you please decrypt =
your message so that it

> > becomes

> >>>>> perhaps

> >>>>>>>>>> actionable?

> >>>>>>>>>

> >>>>>>>>> I'm agreeing with you.

> >>>>>>>>>

> >>>>>>>>>> /js

> >>>>>> --

> >>>>>> Hirochika Asai <panda@hongo.wide.ad.jp>, The University of

> > Tokyo

> >>>>>>

> >>>>>> _____________________________________________=
__

> >>>>>> OPSAWG mailing list

> >>>>>> OPSAWG@iet=
f.org

> >>>>>> https://www.ietf.org/mailman/listinfo/opsawg<=
/a>

> >>>>>

> >>>>> _______________________________________________
> >>>>> OPSAWG mailing list

> >>>>> OPSAWG@ietf.or=
g

> >>>>> https://www.ietf.org/mailman/listinfo/opsawg<=
br>
> >>>>>

> >>>> _______________________________________________

> >>>> OPSAWG mailing list

> >>>> OPSAWG@ietf.org

> >>>> https://www.ietf.org/mailman/listinfo/opsawg

> >>>

> >>> --

> >>> Ladislav Lhotka, CZ.NIC Labs

> >>> PGP Key ID: E74E8C0C

> >>>

> >>> _______________________________________________

> >>> Netconf mailing list

> >>> Netconf@ietf.org<=
br>
> >>> https://www.ietf.org/mailman/listinfo/netconf

> >>>

> >>

> >

> >

> > -----------------------------------------------------------------=
-------

> > --------

> >

> >

> >> _______________________________________________

> >> Netconf mailing list

> >> Netconf@ietf.org

> >> https://www.ietf.org/mailman/listinfo/netconf

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>

>

>

>

>



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--089e0153705e8777b404fa9f65d9--


From nobody Fri May 30 08:09:12 2014
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 EBDD11A08EE for ; Fri, 30 May 2014 08:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 cgepQjWrcJPv for ; Fri, 30 May 2014 08:09:08 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1C91A08E6 for ; Fri, 30 May 2014 08:09:08 -0700 (PDT)
Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 419D812809E7; Fri, 30 May 2014 17:08:31 +0200 (CEST)
Date: Fri, 30 May 2014 17:09:02 +0200 (CEST)
Message-Id: <20140530.170902.287203538.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/mKdpKDBynuWSC5RAii8OAAHNfAA
Cc: netconf@ietf.org
Subject: Re: [Netconf] [OPSAWG] config persistence
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 May 2014 15:09:11 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDMwIE1heSAy
MDE0LCBhdCAxNjozMCwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0K
PiANCj4gPiBPbiBGcmksIE1heSAzMCwgMjAxNCBhdCA0OjExIEFNLCBMYWRpc2xhdiBMaG90a2Eg
PGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+IEFub3RoZXIgdGhpbmcgdGhhdCBwdXp6bGVzIG1l
Og0KPiA+IA0KPiA+IExldOKAmXMgc2F5IGEgY2xpZW50IGVkaXRzIHRoZSB2YWx1ZSBvZiBwYXJh
bWV0ZXIgWCBpbiBydW5uaW5nLiBUaGUgbmV3IHZhbHVlDQo+ID4gaXMgaW1tZWRpYXRlbHkgcHJv
amVjdGVkIGludG8gb3BlcmF0aW9uYWwgc3RhdGUuIFRoZW4gbGF0ZXIgdGhlIHN0YXRlIHZhbHVl
DQo+ID4gZ2V0cyBjaGFuZ2VkIGJ5IHNvbWUgbWVhbnMgZXh0ZXJuYWwgdG8gTkVUQ09ORi4gSW4g
d2hhdCBldmVudCwgaWYgYW55LCB3aWxsDQo+ID4gdGhlIHZhbHVlIG9mIFggYmUgcmVzZXQgdG8g
dGhlIHZhbHVlIHRoYXTigJlzIGNvbmZpZ3VyZWQgaW4gcnVubmluZz8NCj4gPiANCj4gPiANCj4g
PiBJZiBzdGF0ZSB2YXJpYWJsZXMgYW5kIGNvbmZpZyB2YXJpYWJsZXMgaW50ZXJhY3QsIHRoZW4g
dGhlIGRlc2NyaXB0aW9uLXN0bXQNCj4gPiBzaG91bGQgZXhwbGFpbiB0aGlzIGRhdGEtbW9kZWwg
c3BlY2lmaWMgYmVoYXZpb3IuDQo+IA0KPiBUaGV5IG5lZWRu4oCZdCBpbnRlcmFjdCB3aXRoaW4g
dGhlIE5FVENPTkYgcmVhbG0uIEZvciBleGFtcGxlOiBjb25maWd1cmVkIHN0YXRpYw0KPiByb3V0
ZXMgYXBwZWFyIGluIGEgUklCLCBidXQgdGhlbiBzb21lIG9mIHRoZSByb3V0ZXMgYXJlIGRlbGV0
ZWQgZnJvbSB0aGUgUklCDQo+IHZpYSBJMlJTLiBTbyB0aGUgUklCIGFuZCBjb25maWcgYXJlIG91
dCBvZiBzeW5jLg0KPiBXaWxsIHRoZSBjb25maWd1cmVkIHJvdXRlcyBldmVyIGJlIHJlLWluc3Rh
bGxlZCwgZS5nLiBhZnRlciBydW5uaW5nIGNoYW5nZXMNCj4gYWdhaW4/DQoNCkFzIEFuZHkgYWxy
ZWFkeSB3cm90ZSwgdGhlcmUgaXMgbm90IGEgc2luZ2xlIGdlbmVyaWMgYW5zd2VyLiAgSW4gdGhp
cw0KcGFydGljdWxhciBjYXNlLCBpdCBpcyB1cCB0byBJMlJTIHRvIGNsZWFybHkgZGVmaW5lLg0K
DQoNCi9tYXJ0aW4NCg==


From nobody Fri May 30 08:35:37 2014
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 3DE8F1A0939 for ; Fri, 30 May 2014 08:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 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, RP_MATCHES_RCVD=-0.651] 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 roA9rwN8-z9h for ; Fri, 30 May 2014 08:35:28 -0700 (PDT)
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 C10AE1A014E for ; Fri, 30 May 2014 08:35:23 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3CBFB13F69D; Fri, 30 May 2014 17:35:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401464118; bh=UuKpyEhHdzTowOFQJj3uhR4RSIDECPs+py+hyel9CPc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=EVvf7PG1pZu05niSGm6ZTFNBJ5ZiJSR2LH8CxzjrgiaQcHth+ZwOWf5TCKtIPdQO7 pMsCJiz2eSgnDdPwvcmqZrVyYl9ZwAvI27J3YAafEuAom+Id/MNzLG5ayCAFiKygw9 pziAu3+z1OtIxMA86IMICoDEYMkHfwVvs9+z/zDU=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: <20140530.170902.287203538.mbj@tail-f.com>
Date: Fri, 30 May 2014 17:35:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <792328BF-54A0-4E6C-96E9-24E1E444642C@nic.cz>
References:    <20140530.170902.287203538.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/vO3kpLPR_kMddZsuLGZXOKHdlUk
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence
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 May 2014 15:35:34 -0000

On 30 May 2014, at 17:09, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>>=20
>> On 30 May 2014, at 16:30, Andy Bierman  wrote:
>>=20
>>> On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka  =
wrote:
>>> Another thing that puzzles me:
>>>=20
>>> Let=92s say a client edits the value of parameter X in running. The =
new value
>>> is immediately projected into operational state. Then later the =
state value
>>> gets changed by some means external to NETCONF. In what event, if =
any, will
>>> the value of X be reset to the value that=92s configured in running?
>>>=20
>>>=20
>>> If state variables and config variables interact, then the =
description-stmt
>>> should explain this data-model specific behavior.
>>=20
>> They needn=92t interact within the NETCONF realm. For example: =
configured static
>> routes appear in a RIB, but then some of the routes are deleted from =
the RIB
>> via I2RS. So the RIB and config are out of sync.
>> Will the configured routes ever be re-installed, e.g. after running =
changes
>> again?
>=20
> As Andy already wrote, there is not a single generic answer.  In this
> particular case, it is up to I2RS to clearly define.

I2RS was just an example, my question simply is: When is the running =
configuration (or parts of it) applied/re-applied? On a Unix system =
configured in init scripts it is usually clear - e.g. any time

/etc/init.d/xxxx reload

is run. NETCONF has no such explicit push mechanism, so I wonder =
whether/when this might happen anyway.
The spec says nothing about it, presumably because running was =
considered to be always in sync with operational parameters.

Lada

>=20
>=20
> /martin

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





From nobody Fri May 30 08:50:03 2014
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 CB8A91A0999 for ; Fri, 30 May 2014 08:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q556DG-QfSp9 for ; Fri, 30 May 2014 08:50:00 -0700 (PDT)
Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11161A0141 for ; Fri, 30 May 2014 08:49:59 -0700 (PDT)
Received: by mail-qg0-f51.google.com with SMTP id q107so5929154qgd.10 for ; Fri, 30 May 2014 08:49:55 -0700 (PDT)
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=15kvEIK+ez6mBIJqqZUPpFexlxVM+DxKKTzybUDS7to=; b=MqOV+lJDLoGnSXaT1rtHhU0mKpsJyCQkd8baMTnmzV8vNJl32RtWzRNByYtjVpgXee zVfNG3XcYbk6npoo5fiZg3nYaTEjdMO3aOBbfsMS7SRIoCDjCvzM1e5MUglE5d1JJ861 SQUZV5d4Zh+GZ1Ur/DRP6BBGN9MfuKyATIgRDUlhoc2OIbDc8Qe57Xb4n9ms7Eos1uLO ko/Oc1dOrTogKWcOTEE0VHVArlP3gNmwsBsILH54lEokHwjuz5ptcIrCso5xUNNZfCHH V7ZSBR/xcp137wl7t7UzpKZDsrmdD1hi6fhfP1Gty92n08I5hLHj0ibHn+LXB9JT1DVh mblA==
X-Gm-Message-State: ALoCoQnuT8Acc784QM+1YIuDy424evu3Ajr59wlimGT90erEZiAWmKXnOR9RlOObQGSIvfvb9JGN
MIME-Version: 1.0
X-Received: by 10.224.24.134 with SMTP id v6mr22790141qab.88.1401464995095; Fri, 30 May 2014 08:49:55 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 30 May 2014 08:49:55 -0700 (PDT)
In-Reply-To: <792328BF-54A0-4E6C-96E9-24E1E444642C@nic.cz>
References:    <20140530.170902.287203538.mbj@tail-f.com> <792328BF-54A0-4E6C-96E9-24E1E444642C@nic.cz>
Date: Fri, 30 May 2014 08:49:55 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c252c632d76104fa9fff74
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dRePPbKszJ2CCQRQTZuRQ1AoomY
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence
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 May 2014 15:50:01 -0000

--001a11c252c632d76104fa9fff74
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 30, 2014 at 8:35 AM, Ladislav Lhotka  wrote:

>
> On 30 May 2014, at 17:09, Martin Bjorklund  wrote:
>
> > Ladislav Lhotka  wrote:
> >>
> >> On 30 May 2014, at 16:30, Andy Bierman  wrote:
> >>
> >>> On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka 
> wrote:
> >>> Another thing that puzzles me:
> >>>
> >>> Let's say a client edits the value of parameter X in running. The new
> value
> >>> is immediately projected into operational state. Then later the state
> value
> >>> gets changed by some means external to NETCONF. In what event, if any,
> will
> >>> the value of X be reset to the value that's configured in running?
> >>>
> >>>
> >>> If state variables and config variables interact, then the
> description-stmt
> >>> should explain this data-model specific behavior.
> >>
> >> They needn't interact within the NETCONF realm. For example: configured
> static
> >> routes appear in a RIB, but then some of the routes are deleted from
> the RIB
> >> via I2RS. So the RIB and config are out of sync.
> >> Will the configured routes ever be re-installed, e.g. after running
> changes
> >> again?
> >
> > As Andy already wrote, there is not a single generic answer.  In this
> > particular case, it is up to I2RS to clearly define.
>
> I2RS was just an example, my question simply is: When is the running
> configuration (or parts of it) applied/re-applied? On a Unix system
> configured in init scripts it is usually clear - e.g. any time
>
> /etc/init.d/xxxx reload
>
> is run. NETCONF has no such explicit push mechanism, so I wonder
> whether/when this might happen anyway.
> The spec says nothing about it, presumably because running was considered
> to be always in sync with operational parameters.
>
>
I think NETCONF is explicit about the semantics of the running
configuration.
The system MUST be aware of the desired state of the system as embodied
in the running datastore.  The system uses that information, along with all
sorts of other information, to perform its functions.  The resulting
operational
state will be data model and implementation specific.


Lada
>
>
Andy


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

--001a11c252c632d76104fa9fff74
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Fri, May 30, 2014 at 8:35 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:




On 30 May 2014, at 17:09, Martin Bjorklund <mbj@tail-f.com> wrote:



> Ladislav Lhotka <lhotka@nic.cz=
> wrote:

>>

>> On 30 May 2014, at 16:30, Andy Bierman <andy@yumaworks.com> wrote:

>>

>>> On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>>> Another thing that puzzles me:

>>>

>>> Let’s say a client edits the value of parameter X in run=
ning. The new value

>>> is immediately projected into operational state. Then later th=
e state value

>>> gets changed by some means external to NETCONF. In what event,=
 if any, will

>>> the value of X be reset to the value that’s configured i=
n running?

>>>

>>>

>>> If state variables and config variables interact, then the des=
cription-stmt

>>> should explain this data-model specific behavior.

>>

>> They needn’t interact within the NETCONF realm. For example:=
 configured static

>> routes appear in a RIB, but then some of the routes are deleted fr=
om the RIB

>> via I2RS. So the RIB and config are out of sync.

>> Will the configured routes ever be re-installed, e.g. after runnin=
g changes

>> again?

>

> As Andy already wrote, there is not a single generic answer.  In =
this

> particular case, it is up to I2RS to clearly define.



I2RS was just an example, my question simply is: When is the running config=
uration (or parts of it) applied/re-applied? On a Unix system configured in=
 init scripts it is usually clear - e.g. any time



/etc/init.d/xxxx reload



is run. NETCONF has no such explicit push mechanism, so I wonder whether/wh=
en this might happen anyway.

The spec says nothing about it, presumably because running was considered t=
o be always in sync with operational parameters.



I think NETCONF is explicit about the =
semantics of the running configuration.
The system MUST be aware =
of the desired state of the system as embodied
in the running dat=
astore.  The system uses that information, along with all


sorts of other information, to perform its functions.  The result=
ing operational
state will be data model and implementation speci=
fic.




Lada



Andy
 

>

>

> /martin



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a11c252c632d76104fa9fff74--


From nobody Fri May 30 09:10:17 2014
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 D82F01A09D9 for ; Fri, 30 May 2014 09:10:15 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] 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 r6IGflQQJblt for ; Fri, 30 May 2014 09:10:14 -0700 (PDT)
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 0B1081A0946 for ; Fri, 30 May 2014 09:10:14 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6A80B13F69D; Fri, 30 May 2014 18:10:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401466208; bh=QC/oR6wL0/ThjQz1/UkepRkDOxYn4H/TUbeL0peQTEg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pg0+TSIrxfkGxG4OUB9y78RYr8Nfk1Pm2cA9ta5YEjEfd33ydQmpYcLLu2orGxT7+ mI1KZ00SBrEVkIitYm/qMrpIejNX33WDfyYh+AjyMlMyOfn5lY+v0PrpDL6nnqnoDl qOs3Tsl2JLgsrVup+uQdm0f1hFwLyFJYN5WdBjts=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 30 May 2014 18:10:07 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <13629E9D-C837-4127-BDD8-3636DEB8813D@nic.cz>
References:    <20140530.170902.287203538.mbj@tail-f.com> <792328BF-54A0-4E6C-96E9-24E1E444642C@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/CBb5qtMP08yEiwc0LdGwIlbyODM
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence
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 May 2014 16:10:16 -0000

On 30 May 2014, at 17:49, Andy Bierman  wrote:

>=20
>=20
>=20
> On Fri, May 30, 2014 at 8:35 AM, Ladislav Lhotka  =
wrote:
>=20
> On 30 May 2014, at 17:09, Martin Bjorklund  wrote:
>=20
> > Ladislav Lhotka  wrote:
> >>
> >> On 30 May 2014, at 16:30, Andy Bierman  wrote:
> >>
> >>> On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka  =
wrote:
> >>> Another thing that puzzles me:
> >>>
> >>> Let=92s say a client edits the value of parameter X in running. =
The new value
> >>> is immediately projected into operational state. Then later the =
state value
> >>> gets changed by some means external to NETCONF. In what event, if =
any, will
> >>> the value of X be reset to the value that=92s configured in =
running?
> >>>
> >>>
> >>> If state variables and config variables interact, then the =
description-stmt
> >>> should explain this data-model specific behavior.
> >>
> >> They needn=92t interact within the NETCONF realm. For example: =
configured static
> >> routes appear in a RIB, but then some of the routes are deleted =
from the RIB
> >> via I2RS. So the RIB and config are out of sync.
> >> Will the configured routes ever be re-installed, e.g. after running =
changes
> >> again?
> >
> > As Andy already wrote, there is not a single generic answer.  In =
this
> > particular case, it is up to I2RS to clearly define.
>=20
> I2RS was just an example, my question simply is: When is the running =
configuration (or parts of it) applied/re-applied? On a Unix system =
configured in init scripts it is usually clear - e.g. any time
>=20
> /etc/init.d/xxxx reload
>=20
> is run. NETCONF has no such explicit push mechanism, so I wonder =
whether/when this might happen anyway.
> The spec says nothing about it, presumably because running was =
considered to be always in sync with operational parameters.
>=20
>=20
> I think NETCONF is explicit about the semantics of the running =
configuration.
> The system MUST be aware of the desired state of the system as =
embodied
> in the running datastore.  The system uses that information, along =
with all
> sorts of other information, to perform its functions.  The resulting =
operational
> state will be data model and implementation specific.

My company implemented NETCONF on OpenWRT so that UCI scripts =
essentially act as the running config. The way how UCI works is that =
=93uci commit=94 may generate a native configuration file for a certain =
service. A user can nonetheless use vi to edit the native configuration =
file directly, so the UCI config gets out of sync and will be =
resynchronised only after next =93uci commit=94 for that service.

Are you saying this is not a compliant NETCONF implementation?

Lada
 =20
>=20
>=20
> Lada
>=20
>=20
> Andy
> =20
> >
> >
> > /martin
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

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





From nobody Fri May 30 09:31:03 2014
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 5079E1A0991 for ; Fri, 30 May 2014 09:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ChKRVo8kuR_M for ; Fri, 30 May 2014 09:30:58 -0700 (PDT)
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513981A035B for ; Fri, 30 May 2014 09:30:58 -0700 (PDT)
Received: by mail-qg0-f47.google.com with SMTP id j107so5948657qga.20 for ; Fri, 30 May 2014 09:30:53 -0700 (PDT)
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=9f0NOgbrxHXlk2iekSQK55rx93MyV/VL+qhep//n2ps=; b=a3IBG6AS7ZpUS/URO6Mbc6+hX4XdoLfOqE8SNeH/a0nl02l4SXf5Yx6L8ZoFZiW4Xy QMDcc46B27UIMe1Vj8YFs60OIW/VR/TRfkJlSjqujSEM5LcItt0TsAorP8w47jEbKG0E RwsELVPco+a02bCkHwIcV5/dOL+GL2CzOnBral2koHDFLbVBMQNM0GRFcLY6jmRLk6DC vt/ztJbFz4byydgZBAVHpUXt5c9lu2N2CZsoJdLn/AEf9TM9hE6vrwdjA5mllKfX8Kt0 lXXmVwsBtmGZaP5G0s3kZBv3GudR19i2jSX8VVgGfJ0hrhVBTlp9BPzoSvSE8feyMLjp dxDg==
X-Gm-Message-State: ALoCoQmd4cuzhcCKBncSqFmrwAa6CC4jLxiXaISsy+wOeFAlROVL0UGjFZcW6Rc9VRPDT0E//pwP
MIME-Version: 1.0
X-Received: by 10.224.79.198 with SMTP id q6mr22063001qak.99.1401467453452; Fri, 30 May 2014 09:30:53 -0700 (PDT)
Received: by 10.140.104.49 with HTTP; Fri, 30 May 2014 09:30:53 -0700 (PDT)
In-Reply-To: <13629E9D-C837-4127-BDD8-3636DEB8813D@nic.cz>
References:    <20140530.170902.287203538.mbj@tail-f.com> <792328BF-54A0-4E6C-96E9-24E1E444642C@nic.cz>  <13629E9D-C837-4127-BDD8-3636DEB8813D@nic.cz>
Date: Fri, 30 May 2014 09:30:53 -0700
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=047d7bdca5daba688c04faa091a0
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/G-7_OJMYwUqZeAddl43kb4HpvtA
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence
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 May 2014 16:31:02 -0000

--047d7bdca5daba688c04faa091a0
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 30, 2014 at 9:10 AM, Ladislav Lhotka  wrote:

>
> On 30 May 2014, at 17:49, Andy Bierman  wrote:
>
> >
> >
> >
> > On Fri, May 30, 2014 at 8:35 AM, Ladislav Lhotka  wrote:
> >
> > On 30 May 2014, at 17:09, Martin Bjorklund  wrote:
> >
> > > Ladislav Lhotka  wrote:
> > >>
> > >> On 30 May 2014, at 16:30, Andy Bierman  wrote:
> > >>
> > >>> On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka 
> wrote:
> > >>> Another thing that puzzles me:
> > >>>
> > >>> Let's say a client edits the value of parameter X in running. The
> new value
> > >>> is immediately projected into operational state. Then later the
> state value
> > >>> gets changed by some means external to NETCONF. In what event, if
> any, will
> > >>> the value of X be reset to the value that's configured in running?
> > >>>
> > >>>
> > >>> If state variables and config variables interact, then the
> description-stmt
> > >>> should explain this data-model specific behavior.
> > >>
> > >> They needn't interact within the NETCONF realm. For example:
> configured static
> > >> routes appear in a RIB, but then some of the routes are deleted from
> the RIB
> > >> via I2RS. So the RIB and config are out of sync.
> > >> Will the configured routes ever be re-installed, e.g. after running
> changes
> > >> again?
> > >
> > > As Andy already wrote, there is not a single generic answer.  In this
> > > particular case, it is up to I2RS to clearly define.
> >
> > I2RS was just an example, my question simply is: When is the running
> configuration (or parts of it) applied/re-applied? On a Unix system
> configured in init scripts it is usually clear - e.g. any time
> >
> > /etc/init.d/xxxx reload
> >
> > is run. NETCONF has no such explicit push mechanism, so I wonder
> whether/when this might happen anyway.
> > The spec says nothing about it, presumably because running was
> considered to be always in sync with operational parameters.
> >
> >
> > I think NETCONF is explicit about the semantics of the running
> configuration.
> > The system MUST be aware of the desired state of the system as embodied
> > in the running datastore.  The system uses that information, along with
> all
> > sorts of other information, to perform its functions.  The resulting
> operational
> > state will be data model and implementation specific.
>
> My company implemented NETCONF on OpenWRT so that UCI scripts essentially
> act as the running config. The way how UCI works is that "uci commit" may
> generate a native configuration file for a certain service. A user can
> nonetheless use vi to edit the native configuration file directly, so the
> UCI config gets out of sync and will be resynchronised only after next "uci
> commit" for that service.
>
> Are you saying this is not a compliant NETCONF implementation?
>
>
If a client requests contents from the running configuration datastore via
NETCONF protocol operations, then your implementation is required to
return the correct values.  Other protocols can change the running config
outside the scope of NETCONF.  If so, the server still has to return the
correct .  (There could be latency, e.g. the server polls the
last-modified timestamp on the file in your implementation.)


Lada
>

Andy


>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> > >
> > >
> > > /martin
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--047d7bdca5daba688c04faa091a0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Fri, May 30, 2014 at 9:10 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:




On 30 May 2014, at 17:49, Andy Bierman <andy@yumaworks.com> wrote:



>

>

>

> On Fri, May 30, 2014 at 8:35 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> On 30 May 2014, at 17:09, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Ladislav Lhotka <lhotka@nic.c=
z> wrote:

> >>

> >> On 30 May 2014, at 16:30, Andy Bierman <andy@yumaworks.com> wrote:

> >>

> >>> On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> >>> Another thing that puzzles me:

> >>>

> >>> Let’s say a client edits the value of parameter X i=
n running. The new value

> >>> is immediately projected into operational state. Then lat=
er the state value

> >>> gets changed by some means external to NETCONF. In what e=
vent, if any, will

> >>> the value of X be reset to the value that’s configu=
red in running?

> >>>

> >>>

> >>> If state variables and config variables interact, then th=
e description-stmt

> >>> should explain this data-model specific behavior.

> >>

> >> They needn’t interact within the NETCONF realm. For exa=
mple: configured static

> >> routes appear in a RIB, but then some of the routes are delet=
ed from the RIB

> >> via I2RS. So the RIB and config are out of sync.

> >> Will the configured routes ever be re-installed, e.g. after r=
unning changes

> >> again?

> >

> > As Andy already wrote, there is not a single generic answer. &nbs=
p;In this

> > particular case, it is up to I2RS to clearly define.

>

> I2RS was just an example, my question simply is: When is the running c=
onfiguration (or parts of it) applied/re-applied? On a Unix system configur=
ed in init scripts it is usually clear - e.g. any time

>

> /etc/init.d/xxxx reload

>

> is run. NETCONF has no such explicit push mechanism, so I wonder wheth=
er/when this might happen anyway.

> The spec says nothing about it, presumably because running was conside=
red to be always in sync with operational parameters.

>

>

> I think NETCONF is explicit about the semantics of the running configu=
ration.

> The system MUST be aware of the desired state of the system as embodie=
d

> in the running datastore.  The system uses that information, alon=
g with all

> sorts of other information, to perform its functions.  The result=
ing operational

> state will be data model and implementation specific.



My company implemented NETCONF on OpenWRT so that UCI scripts essentially a=
ct as the running config. The way how UCI works is that “uci commit&r=
dquo; may generate a native configuration file for a certain service. A use=
r can nonetheless use vi to edit the native configuration file directly, so=
 the UCI config gets out of sync and will be resynchronised only after next=
 “uci commit” for that service.




Are you saying this is not a compliant NETCONF implementation?



If a client requests contents from the=
 running configuration datastore via
NETCONF protocol operations,=
 then your implementation is required to
return the correct value=
s.  Other protocols can change the running config


outside the scope of NETCONF.  If so, the server still has to ret=
urn the
correct <rpc-reply>.  (There could be latency,=
 e.g. the server polls the
last-modified timestamp on the file in=
 your implementation.)





Lada

Andy
 



>

>

> Lada

>

>

> Andy

>

> >

> >

> > /martin

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>

>

>

>

>



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--047d7bdca5daba688c04faa091a0--


From nobody Fri May 30 09:49:43 2014
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 975851A6F6E for ; Fri, 30 May 2014 09:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlL5crPOSsFk for ; Fri, 30 May 2014 09:49:36 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD861A6F6C for ; Fri, 30 May 2014 09:49:36 -0700 (PDT)
Received: from DBXPRD0510HT003.eurprd05.prod.outlook.com (157.56.252.165) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 30 May 2014 16:49:29 +0000
Message-ID: <04ff01cf7c26$bb32bde0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Andy Bierman 
References: <02bc01cf7bf2$b5c7b560$4001a8c0@gateway.2wire.net> 
Date: Fri, 30 May 2014 17:46:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.165]
X-ClientProxiedBy: DBXPR07CA018.eurprd07.prod.outlook.com (10.141.8.176) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151)
X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
X-Forefront-PRVS: 02272225C5
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(24454002)(51704005)(189002)(199002)(377454003)(479174003)(51444003)(50986999)(62966002)(92566001)(44716002)(85852003)(83072002)(23756003)(62236002)(89996001)(81686999)(74662001)(74502001)(76176999)(81816999)(20776003)(79102001)(47776003)(64706001)(81342001)(61296002)(81542001)(50226001)(551934003)(88136002)(15975445006)(101416001)(31966008)(19580395003)(87976001)(83322001)(87286001)(19580405001)(80022001)(102836001)(84392001)(99396002)(42186004)(76482001)(15202345003)(77982001)(21056001)(86362001)(575784001)(93916002)(92726001)(4396001)(77156001)(104166001)(46102001)(50466002)(44736004)(33646001)(66066001)(14496001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0510HT003.eurprd05.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
Received-SPF: None (: btconnect.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-OriginatorOrg: btconnect.com
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/vsqYNEJ9Vzff3s8LAoO5sBwL6a4
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB)
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 May 2014 16:49:39 -0000

----- Original Message -----
From: "Andy Bierman" 
To: "t.petch" 
Cc: "Ladislav Lhotka" ; "Netconf" 
Sent: Friday, May 30, 2014 3:17 PM


> >
> > Andy
> >
> > I am happy to characterise it as under-defined rather that
ill-defined,
> > but I think that the RFC are lacking.   We did have this discussion
a
> > few months back, and my point then was that if the only
configuration
> > datastore is running, then the assumption by implementers was that
any
> > change to it would immediately be persistent.  Seems reasonable, but
not
> > specified anywhere, and since running then has the opposite
semantics
> > with startup alongside it, well, that makes it less clearly defined,
for
> > me.
> >
>
> So you are saying you did not understand RFC 6241, sec.  8.7?
> Is there something unclear in this section? It says:
>
>    The device supports separate running and startup configuration
>    datastores.  The startup configuration is loaded by the device when
>    it boots.  Operations that affect the running configuration will
not
>    be automatically copied to the startup configuration.  An explicit
>     operation from the  to the  is used
>    to update the startup configuration to the current contents of the
>    running configuration.  NETCONF protocol operations refer to the
>    startup datastore using the  element.
>
>
> The client checks for the "distinct startup" capability.
> How is this unspecified?  Did you miss this section?

Andy

And when there is no startup configuration (because it is optional)?  We
did agree a year ago that that condition was not specified in an RFC,
although implementations seem to be consistent about it.  That is the
scenario I am referring to

Tom Petch

>
> > As Lada points out, that is not the only such under-definition.
> >
> >
> The RFC does not say anything about High Availability features.
> If the server wants to persist state information so it can recover
> from a hot-swap faster, then that is a fine extra feature, but
> not required at all by the standard.
>
>
> > Tom Petch
> >
> >
> Andy
>
>
> > > sec 8.3.5.2 says:
> > >
> > >    When a client fails with outstanding changes to the candidate
> > >    configuration, recovery can be difficult.  To facilitate easy
> > >    recovery, any outstanding changes are discarded when the lock
is
> > >    released, whether explicitly with the  operation or
> > >    implicitly from session failure.
> > >
> > > IMO it is odd that candidate is cleaned up only if it was locked.
> > > If a client edits candidate and then closes the session somehow
the
> > changes
> > > are left behind.
> > > The RFC is silent about the contents of candidate at boot-time.
Our
> > server
> > > always boots
> > > with the candidate and running having the same contents.
Otherwise
> > the
> > > candidate is
> > > dirty at boot-time and cannot be locked by any session until a
> > > discard-changes is invoked.
> > > There is also no explicit requirement to boot with any particular
> > candidate
> > > contents, so
> > > booting with the contents of running is compliant.
> > >
> > >
> > >
> > > > Lada
> > > >
> > >
> > > Andy
> > >
> > >
> > > >
> > > > >
> > > > > The XMLCONF design team (pre-4741) tried very hard to
> > > > > get the router vendors to agree on a single transaction model
> > > > > but it was way too big a change, and (of course) each vendor
> > > > > thought their way was better, so the standard should use that.
> > > > > We ended up with 3 configuration datastores (candidate,
running,
> > > > startup).
> > > > > The transaction models that can be used with these datastores
> > > > > are compatible with specific router CLI architectures.
> > > > >
> > > > > Two particular vendors do not agree on how to recover
> > > > > from the "unreachable" problem.  If the operator makes
> > > > > config changes that break the connectivity to the device,
> > > > > then the device has to recover somehow.
> > > > >
> > > > >   M1: do not persist the changes until they are proven to
> > > > >         be correct.  Force the device to reboot with the saved
> > > > >         (known good) config if things go bad.
> > > > >
> > > > >   M2: persist the changes right away.  Pick some timeout
> > > > >         and if the client does not follow up with a
confirmation
> > > > >         before the timeout, automatically revert to the
version
> > > > >         that was running before the transaction started.
> > > > >
> > > > > RFC 6241 could be more clear on the motivation for the
> > > > > capabilities and operations that support various transaction
> > models.
> > > > > Maybe that is what you meant by 'ill-defined'.
> > > > >
> > > > >
> > > > > Andy
> > > > >
> > > > > So the two objects controlling Notifications seem clearly
> > configuration,
> > > > >> whether or not the setting of them persists or is lost on
reboot.
> > You
> > > > >> could create a YANG module which controls the setting of
these
> > two
> > > > >> objects for SNMP usage but I think that even the IESG might
see
> > that
> > > > >> that is an unusual approach, as opposed to making them
read-write
> > in
> > > > >> SMI!
> > > > >>
> > > > >> When I first read the draft IESG statement, it was unclear to
me
> > whether
> > > > >> or not the authors fully understood what they had written.
> > > > >>
> > > > >> Tom Petch
> > > > >>
> > > > >> > (*1)
> > http://www.ietf.org/iesg/statement/writable-mib-module.html
> > > > >> > (*2)
http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00
> > > > >> >
> > > > >> > Hirochika
> > > > >> >
> > > > >> >
> > > > >> > On May 27, 2014, at 3:55 AM, joel jaeggli

> > wrote:
> > > > >> >
> > > > >> > > yeah if you want to discuss it with the ops/management
ADs
> > and the
> > > > >> > > chairs that's fine.
> > > > >> > >
> > > > >> > > I don't think there's a reason to involve the whole iesg.
> > > > >> > >
> > > > >> > > Thanks
> > > > >> > > joel
> > > > >> > >
> > > > >> > > On 5/26/14, 10:48 AM, Hirochika Asai wrote:
> > > > >> > >> js and Joel,
> > > > >> > >>
> > > > >> > >> Thank you for your comments.
> > > > >> > >>
> > > > >> > >> I agree that the IESG statement seems to be talking
about
> > > > >> configuration,
> > > > >> > >> but I cannot definitely say that the objects I listed in
my
> > > > >> previous E-mail
> > > > >> > >> are out of the IESG statement's scope.
> > > > >> > >>
> > > > >> > >> I think it would be better to move this issue to the
IESG,
> > but I
> > > > >> don't keep
> > > > >> > >> up the procedure.  May I, as an author of the draft,
send an
> > E-mail
> > > > >> > >> stating this issue to iesg@ietf.org, CCing WG? Or ask WG
> > chairs to
> > > > >> > >> handle it?
> > > > >> > >>
> > > > >> > >> Thank you.
> > > > >> > >> Hirochika
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli

> > > > wrote:
> > > > >> > >>
> > > > >> > >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> > > > >> > >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli
> > wrote:
> > > > >> > >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:
> > > > >> > >>>>>> Asai,
> > > > >> > >>>>>>
> > > > >> > >>>>>> the IESG statement is here:
> > > > >> > >>>>>>
> > > > >> > >>>>>>
> > http://www.ietf.org/iesg/statement/writable-mib-module.html
> > > > >> > >>>>>>
> > > > >> > >>>>>> My reading is that it specifically talks about
> > configuration.
> > > > >> While
> > > > >> > >>>>>> the discussion started with "lets ban all write
access",
> > it may
> > > > >> be
> > > > >> > >>>>>> important to note that the final statement does not
say
> > this.
> > > > >> Hence,
> > > > >> > >>>>>> I am not sure we have to remove the MAX-ACCESS
> > read-write.
> > > > >> > >>>>>
> > > > >> > >>>>> some of the vm options do cause me existential peril.
The
> > > > >> remaining
> > > > >> > >>>>> one's however do not. so I think Juergen's assessment
is
> > a
> > > > >> correct one.
> > > > >> > >>>>> The statement seems to be serving it's purpose!
> > > > >> >>>>
> > > > >> > >>>> Joel, can you please decrypt your message so that it
> > becomes
> > > > >> perhaps
> > > > >> > >>>> actionable?
> > > > >> > >>>
> > > > >> > >>> I'm agreeing with you.
> > > > >> > >>>
> > > > >> > >>>> /js
> > > > >> > --
> > > > >> > Hirochika Asai , The University of
> > Tokyo
> > > > >> >
> > > > >> > _______________________________________________
> > > > >> > OPSAWG mailing list
> > > > >> > OPSAWG@ietf.org
> > > > >> > https://www.ietf.org/mailman/listinfo/opsawg
> > > > >>
> > > > >> _______________________________________________
> > > > >> OPSAWG mailing list
> > > > >> OPSAWG@ietf.org
> > > > >> https://www.ietf.org/mailman/listinfo/opsawg
> > > > >>
> > > > > _______________________________________________
> > > > > OPSAWG mailing list
> > > > > OPSAWG@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/opsawg
> > > >
> > > > --
> > > > Ladislav Lhotka, CZ.NIC Labs
> > > > PGP Key ID: E74E8C0C
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> > >
> >
> >
>
> ----------------------------------------------------------------------
--
> > --------
> >
> >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> >
> >
>


From nobody Fri May 30 11:19:14 2014
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 BD4E51A043F for ; Fri, 30 May 2014 11:19:11 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] 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 uUfe8lZL4EZn for ; Fri, 30 May 2014 11:19:10 -0700 (PDT)
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 CDE6C1A036A for ; Fri, 30 May 2014 11:19:09 -0700 (PDT)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id F17C313F69D; Fri, 30 May 2014 20:19:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401473944; bh=w9GAqVjIx8RtXte4lFTxju/nbZH0n9XW/0WRzryrSYE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nYipXqfcfhd3edvj2zCd1LEcPqvkoLyFzB7inTwQ9wQp+sf+af08yTRTCdxhblOCQ HfenMSZMnBa9JBs7oQclnkvzZkGSLPhupwH8mZuE/1qCIzoloqE8GxY8KQUf0MxNVN zs4N+wW4574VJkqOBfKZ091dgrXlkFN/d2dRCfAg=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 30 May 2014 20:19:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F855883-5314-4B51-A97B-D8D6252FA3A2@nic.cz>
References:    <20140530.170902.287203538.mbj@tail-f.com> <792328BF-54A0-4E6C-96E9-24E1E444642C@nic.cz>  <13629E9D-C837-4127-BDD8-3636DEB8813D@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Jq48DbdTXSYXhVQrqeB9ml2b8-0
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence
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 May 2014 18:19:11 -0000

On 30 May 2014, at 18:30, Andy Bierman  wrote:

>=20
>=20
>=20
> On Fri, May 30, 2014 at 9:10 AM, Ladislav Lhotka  =
wrote:
>=20
> On 30 May 2014, at 17:49, Andy Bierman  wrote:
>=20
> >
> >
> >
> > On Fri, May 30, 2014 at 8:35 AM, Ladislav Lhotka  =
wrote:
> >
> > On 30 May 2014, at 17:09, Martin Bjorklund  wrote:
> >
> > > Ladislav Lhotka  wrote:
> > >>
> > >> On 30 May 2014, at 16:30, Andy Bierman  =
wrote:
> > >>
> > >>> On Fri, May 30, 2014 at 4:11 AM, Ladislav Lhotka  =
wrote:
> > >>> Another thing that puzzles me:
> > >>>
> > >>> Let=92s say a client edits the value of parameter X in running. =
The new value
> > >>> is immediately projected into operational state. Then later the =
state value
> > >>> gets changed by some means external to NETCONF. In what event, =
if any, will
> > >>> the value of X be reset to the value that=92s configured in =
running?
> > >>>
> > >>>
> > >>> If state variables and config variables interact, then the =
description-stmt
> > >>> should explain this data-model specific behavior.
> > >>
> > >> They needn=92t interact within the NETCONF realm. For example: =
configured static
> > >> routes appear in a RIB, but then some of the routes are deleted =
from the RIB
> > >> via I2RS. So the RIB and config are out of sync.
> > >> Will the configured routes ever be re-installed, e.g. after =
running changes
> > >> again?
> > >
> > > As Andy already wrote, there is not a single generic answer.  In =
this
> > > particular case, it is up to I2RS to clearly define.
> >
> > I2RS was just an example, my question simply is: When is the running =
configuration (or parts of it) applied/re-applied? On a Unix system =
configured in init scripts it is usually clear - e.g. any time
> >
> > /etc/init.d/xxxx reload
> >
> > is run. NETCONF has no such explicit push mechanism, so I wonder =
whether/when this might happen anyway.
> > The spec says nothing about it, presumably because running was =
considered to be always in sync with operational parameters.
> >
> >
> > I think NETCONF is explicit about the semantics of the running =
configuration.
> > The system MUST be aware of the desired state of the system as =
embodied
> > in the running datastore.  The system uses that information, along =
with all
> > sorts of other information, to perform its functions.  The resulting =
operational
> > state will be data model and implementation specific.
>=20
> My company implemented NETCONF on OpenWRT so that UCI scripts =
essentially act as the running config. The way how UCI works is that =
=93uci commit=94 may generate a native configuration file for a certain =
service. A user can nonetheless use vi to edit the native configuration =
file directly, so the UCI config gets out of sync and will be =
resynchronised only after next =93uci commit=94 for that service.
>=20
> Are you saying this is not a compliant NETCONF implementation?
>=20
>=20
> If a client requests contents from the running configuration datastore =
via
> NETCONF protocol operations, then your implementation is required to
> return the correct values.  Other protocols can change the running =
config
> outside the scope of NETCONF.  If so, the server still has to return =
the

Other protocols, even if they care (some don=92t), may not able to do it =
if running is locked.

Lada

> correct .  (There could be latency, e.g. the server polls =
the
> last-modified timestamp on the file in your implementation.)
>=20
>=20
> Lada
>=20
> Andy
> =20
>=20
> >
> >
> > Lada
> >
> >
> > Andy
> >
> > >
> > >
> > > /martin
> >
> > --
> > 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





From nobody Fri May 30 16:23:22 2014
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 894C31A0458 for ; Fri, 30 May 2014 16:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, 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 GKokbko4OUjO for ; Fri, 30 May 2014 16:23:19 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D7D1A0450 for ; Fri, 30 May 2014 16:23:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4330; q=dns/txt; s=iport; t=1401492194; x=1402701794; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=kaMTBe3RakH2GgGf/5qRgeBjIl8vBnYrkDwqJm5vcJU=; b=WM7scVdqCXuBUh9teUPzYLnyy4zhB9PNIINed4n1jCmWiBhXcV/lg1VL /IGIiS2nV1wDRwODuPJEeyhy36eVhvrTjmZFqfiKRBn1DyPe2nhAG/FUM r6pJFhPHOfZpRSXzyLgRhVyQhRPNiPpQhYnstjzp003zfkKQJm9GZ+5pj A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjsLAC4SiVOtJV2T/2dsb2JhbABYgkJFgSqqHwaYGgGBChZ0gix5EgEIBHQlAgQBDYhH1xwXhVWIfQeEQASZfpMtgziCLw
X-IronPort-AV: E=Sophos; i="4.98,944,1392163200"; d="scan'208,217"; a="48835120"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP; 30 May 2014 23:23:14 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s4UNNEfj008000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 23:23:14 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.23]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Fri, 30 May 2014 18:23:13 -0500
From: "Alberto Gonzalez Prieto (albertgo)" 
To: Andy Bierman , Ladislav Lhotka 
Thread-Topic: [Netconf] [OPSAWG] config persistence
Thread-Index: AQHPfBkeuMBMvt40okehlIQPTWCmKJtZlSEAgAAEGICAAAlBAA==
Date: Fri, 30 May 2014 23:23:12 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.154.204.237]
Content-Type: multipart/alternative; boundary="_000_CFAE59BE6DDC7albertgociscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zJzqfHSsTrd9zgR6oE1USSE93Y8
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence
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 May 2014 23:23:20 -0000

--_000_CFAE59BE6DDC7albertgociscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



I think NETCONF is explicit about the semantics of the running configuratio=
n.
The system MUST be aware of the desired state of the system as embodied
in the running datastore.  The system uses that information, along with all
sorts of other information, to perform its functions.  The resulting operat=
ional
state will be data model and implementation specific.

I understand the text above identifies running datastore with "desired stat=
e" (vs. operational state ?)

>From RFC 6241:
"running configuration datastore: A configuration datastore holding
      the complete configuration currently active on the device."
"A configuration datastore is defined as the complete set of configuration =
data that
   is required to get a device from its initial default state into a desire=
d operational state."


I could not find a definition of "active configuration" in the RFC.
But considering the second snippet, I understand that, in the absence of st=
imuli, the contents of the running datastore and the operational state must=
 be eventually consistent.
Is this correct?
That would mean that if the desired state would stop being operational (say=
 this is caused by some permanent failure) or could not be made operational=
, the running datastore contents should change.

Thanks,

Alberto






--_000_CFAE59BE6DDC7albertgociscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable























I think NETCONF is explicit about the semantics of the running configu=
ration.


The system MUST be aware of the desired state of the system as embodie=
d


in the running datastore.  The system uses that information, alon=
g with all


sorts of other information, to perform its functions.  The result=
ing operational


state will be data model and implementation specific.





















I understand the text above identifies running d=
atastore with "desired state" (vs. operational state ?)












From RFC 6241: 


"running configuration datastore: A configuration datastore holdi=
ng


      the complete configuration currently active on th=
e device."




"A configuration datastore is defined as the complete set of=
 configuration data that


   is required to get a device from its initial default stat=
e into a desired operational state."














I could not find a definition of "active configuration" in t=
he RFC. 


But considering the second snippet, I understand that, in th=
e absence of stimuli, the contents of the running datastore and the operati=
onal state must be eventually consistent.


Is this correct?


That would mean that if the desired state would stop being operational=
 (say this is caused by some permanent failure) or could not be made operat=
ional, the running datastore contents should change.







Thanks,







Alberto





























--_000_CFAE59BE6DDC7albertgociscocom_--


From nobody Sat May 31 02:29:27 2014
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 05E3F1A07CF for ; Sat, 31 May 2014 02:29:26 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.651] 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 6CpRYJ9i02Fq for ; Sat, 31 May 2014 02:29:24 -0700 (PDT)
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 8015B1A07CC for ; Sat, 31 May 2014 02:29:23 -0700 (PDT)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9BA0F13FB1F; Sat, 31 May 2014 11:29:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1401528556; bh=6aOlpLEDRsw7RyrdBiThs5Ulz2JAU8709n0sC2sdAns=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=szb5p7MuqAOJmiGQStVSBbgfHaoyoJszynTLF0UBVwrgOaJ7U3o1BSiQcPygd2/GX JH8DbXc1ubv4qIkgQjqds8gM2r6buxlX/l0zv+FCsbWu0NCBX5Gy83rsWyiSJl53ip WoMGwdhJz9d6w7aII7Q6EjJJystx4Kc1ygCgXjhE=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Sat, 31 May 2014 11:29:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <815628C8-6E41-4F9B-8995-05120B9C7D67@nic.cz>
References: 
To: "Alberto Gonzalez Prieto (albertgo)" 
X-Mailer: Apple Mail (2.1878.2)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Af5SA9mDds33eM7iUxsxJyYa2cU
Cc: Netconf 
Subject: Re: [Netconf] [OPSAWG] config persistence
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 May 2014 09:29:26 -0000

On 31 May 2014, at 01:23, Alberto Gonzalez Prieto (albertgo) =
 wrote:

>>=20
>>=20
>> I think NETCONF is explicit about the semantics of the running =
configuration.
>> The system MUST be aware of the desired state of the system as =
embodied
>> in the running datastore.  The system uses that information, along =
with all
>> sorts of other information, to perform its functions.  The resulting =
operational
>> state will be data model and implementation specific.
>=20
> I understand the text above identifies running datastore with "desired =
state" (vs. operational state ?)
>=20
> =46rom RFC 6241:=20
> "running configuration datastore: A configuration datastore holding
>       the complete configuration currently active on the device."
> "A configuration datastore is defined as the complete set of =
configuration data that
>    is required to get a device from its initial default state into a =
desired operational state."
>=20
>=20
> I could not find a definition of "active configuration" in the RFC.=20
> But considering the second snippet, I understand that, in the absence =
of stimuli, the contents of the running datastore and the operational =
state must be eventually consistent.
> Is this correct?

I don=92t think this is correct, unless eventually means =93sometimes, =
maybe". If it was true, the dual config and state values as defined in =
ietf-ip and ietf-routing would not be needed.

Lada

> That would mean that if the desired state would stop being operational =
(say this is caused by some permanent failure) or could not be made =
operational, the running datastore contents should change.
>=20
> Thanks,
>=20
> Alberto
>=20
>=20
>=20
>=20
>=20

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





From nobody Sat May 31 04:25:14 2014
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 DBF4B1A084B; Sat, 31 May 2014 04:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG_oE8IlD767; Sat, 31 May 2014 04:25:04 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7D61A0874; Sat, 31 May 2014 04:25:04 -0700 (PDT)
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.4.2.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140531112504.9472.58713.idtracker@ietfa.amsl.com>
Date: Sat, 31 May 2014 04:25:04 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WD1PVm2CPSgBgNprLri6S_LUyM4
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action: draft-ietf-netconf-server-model-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 May 2014 11:25:08 -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 Server Configuration Model
        Authors         : Kent Watsen
                          Juergen Schoenwaelder
	Filename        : draft-ietf-netconf-server-model-00.txt
	Pages           : 29
	Date            : 2014-05-30

Abstract:
   This draft defines a NETCONF server configuration data model.  This
   data model enables configuration of the NETCONF service itself,
   including which transports it supports, what ports they listen on,
   whether they support device-initiated connections, and associated
   parameters.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netconf-server-model-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/