From swmike@swm.pp.se Thu Oct 3 00:15:19 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5898C21F9E6C for ; Thu, 3 Oct 2013 00:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vol8FVD+2Uv for ; Thu, 3 Oct 2013 00:15:12 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8874B21F9E33 for ; Thu, 3 Oct 2013 00:15:10 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 090E9A5; Thu, 3 Oct 2013 09:15:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id EC8A3A3 for ; Thu, 3 Oct 2013 09:15:05 +0200 (CEST) Date: Thu, 3 Oct 2013 09:15:05 +0200 (CEST) From: Mikael Abrahamsson To: netconf@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [Netconf] call home X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 07:15:19 -0000 Hello. We have a use case where we want end systems and routers to be configured via Netconf/YANG and some of these might not be connectable from the Internet directly. The Reverse-SSH and rfc5539bis documents seem very relevant to implementation of this use case. I am currently in process of trying to document/develop architecture document for everything from bootstrap (key/certificate/other information distribution for a factory defaulted system) up until the device is fully provisioned and delivering services. There are quite a lot of question marks and gaps that need to be filled, where the ability to have the provision system being able to provision services, for instance via call-home is one part. There seems to have been very little progress on the reverse-SSH and TLS drafts in the past months? What's the current thinking on these? According to the time schedule in the charter the WGLC proposed time is long over. Is there anything I can do to help things along? I have read draft-ietf-netconf-reverse-ssh-01 and it seems perfectly viable for our deployment case as it is. Current thinking is to exchange cryptographic (and other) information via DHCPv6 to bootstrap ability for the netconf client and server to authenticate each other, and use public keys/host keys for login. I read some concerns that would interesting to hear more about. I will be attending IETF88 in Vancouver, but I would be a lot happier if the call home part at least had passed WGLC by then :) -- Mikael Abrahamsson email: swmike@swm.pp.se From kwatsen@juniper.net Thu Oct 3 09:17:31 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B2821E8082 for ; Thu, 3 Oct 2013 09:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd2OLglZnEzl for ; Thu, 3 Oct 2013 09:17:20 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8EB21E809C for ; Thu, 3 Oct 2013 09:04:34 -0700 (PDT) Received: from mail82-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Thu, 3 Oct 2013 16:04:33 +0000 Received: from mail82-tx2 (localhost [127.0.0.1]) by mail82-tx2-R.bigfish.com (Postfix) with ESMTP id 335A22C00ED; Thu, 3 Oct 2013 16:04:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI62a3I98dI9371I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail82-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(252514010)(164054003)(377454003)(479174003)(199002)(24454002)(189002)(51704005)(76482001)(53806001)(49866001)(81816001)(59766001)(74502001)(54316002)(47736001)(69226001)(56776001)(77982001)(4396001)(79102001)(65816001)(63696002)(80976001)(85306002)(47976001)(83506001)(47446002)(66066001)(31966008)(74876001)(46102001)(80022001)(81342001)(51856001)(50986001)(81686001)(74706001)(74366001)(77096001)(36756003)(19580395003)(83322001)(19580405001)(56816003)(76796001)(76786001)(54356001)(74662001)(81542001)(76176001)(83072001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB126; H:BY2PR05MB125.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail82-tx2 (localhost.localdomain [127.0.0.1]) by mail82-tx2 (MessageSwitch) id 1380816271109736_31416; Thu, 3 Oct 2013 16:04:31 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.240]) by mail82-tx2.bigfish.com (Postfix) with ESMTP id 0AA6DE0049; Thu, 3 Oct 2013 16:04:31 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 3 Oct 2013 16:04:27 +0000 Received: from BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.359.1; Thu, 3 Oct 2013 16:04:25 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 3 Oct 2013 16:04:23 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.180]) by BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.180]) with mapi id 15.00.0775.005; Thu, 3 Oct 2013 16:04:22 +0000 From: Kent Watsen To: Mikael Abrahamsson , "netconf@ietf.org" Thread-Topic: [Netconf] call home Thread-Index: AQHOwAhjlfKwabhkFkWRMbnCKOHAzpni4U+A Date: Thu, 3 Oct 2013 16:04:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [66.129.232.2] x-forefront-prvs: 09888BC01D Content-Type: text/plain; charset="us-ascii" Content-ID: <1CC5F04D06731D45AB44CE263C928830@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Netconf] call home X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 16:17:31 -0000 Hi Mikael, I'm currently working on a Reverse SSH reference implementation, which I hope to have completed in a few days. I then need to get it blessed by Juniper's Open Source Software committee before I can post it - hopefully that won't take too long. I also plan to update draft-ietf-netconf-reverse-ssh - really just need to clarify a few points and add an Applicability Statement that declares it only suitable for Network Management. Regarding how device discovery and secure key distribution can be implemented is outside the scope of the Reverse SSH draft, but it is exactly what the "ZeroConf" draft will address. ZeroConf was discussed during the Reverse SSH presentation in Berlin. Stephen Hanna and I took an action item to submit a draft for it. We went ahead and met with Russ Mundy and Wes Hardaker and sketched out a solution, which I hope to write a draft for shortly, but can't promise it'll make the Vancouver cut-off date. PS: I also plan to be in Vancouver and look forward to seeing you there. Thanks, Kent On 10/3/13 3:15 AM, "Mikael Abrahamsson" wrote: > >Hello. > >We have a use case where we want end systems and routers to be configured >via Netconf/YANG and some of these might not be connectable from the >Internet directly. The Reverse-SSH and rfc5539bis documents seem very >relevant to implementation of this use case. > >I am currently in process of trying to document/develop architecture >document for everything from bootstrap (key/certificate/other information >distribution for a factory defaulted system) up until the device is fully >provisioned and delivering services. There are quite a lot of question >marks and gaps that need to be filled, where the ability to have the >provision system being able to provision services, for instance via >call-home is one part. > >There seems to have been very little progress on the reverse-SSH and TLS >drafts in the past months? What's the current thinking on these? >According=20 >to the time schedule in the charter the WGLC proposed time is long over. > >Is there anything I can do to help things along? I have read >draft-ietf-netconf-reverse-ssh-01 and it seems perfectly viable for our >deployment case as it is. > >Current thinking is to exchange cryptographic (and other) information via >DHCPv6 to bootstrap ability for the netconf client and server to >authenticate each other, and use public keys/host keys for login. I read >some concerns that would interesting to hear more about. > >I will be attending IETF88 in Vancouver, but I would be a lot happier if >the call home part at least had passed WGLC by then :) > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From bertietf@bwijnen.net Fri Oct 4 04:17:28 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB1D21F9697 for ; Fri, 4 Oct 2013 04:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHZLFn1dnxRY for ; Fri, 4 Oct 2013 04:17:17 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 2879021F99F3 for ; Fri, 4 Oct 2013 04:16:11 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VS3Mc-0004Mb-VK; Fri, 04 Oct 2013 13:16:10 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=guest29.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VS3Mc-0007Oe-Rr; Fri, 04 Oct 2013 13:16:06 +0200 Message-ID: <524EA375.9060304@bwijnen.net> Date: Fri, 04 Oct 2013 13:16:05 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20131004 clean 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: 86ab03e524994f79ca2c75a176445dd43d969666f1693e8f29a3307fb080a6ea Cc: "netconf@ietf.org" Subject: Re: [Netconf] call home X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 11:17:28 -0000 Rmember that revision -00 drafts cutoff for Vancouver is 2013-10-07 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. 2013-10-11 (Friday): Final agenda to be published. 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00, upload using IETF ID Submission Tool. SO if you plan to submit a revision-00 draft for the zero-conf, maybe we should prep-approve. However, that would mean that we see it s a WG draft right away. Maybe better as an individual draft first. Bert On 10/3/13 6:04 PM, Kent Watsen wrote: > > Hi Mikael, > > I'm currently working on a Reverse SSH reference implementation, which I > hope to have completed in a few days. I then need to get it blessed by > Juniper's Open Source Software committee before I can post it - hopefully > that won't take too long. > > I also plan to update draft-ietf-netconf-reverse-ssh - really just need to > clarify a few points and add an Applicability Statement that declares it > only suitable for Network Management. > > Regarding how device discovery and secure key distribution can be > implemented is outside the scope of the Reverse SSH draft, but it is > exactly what the "ZeroConf" draft will address. ZeroConf was discussed > during the Reverse SSH presentation in Berlin. Stephen Hanna and I took an > action item to submit a draft for it. We went ahead and met with Russ > Mundy and Wes Hardaker and sketched out a solution, which I hope to write > a draft for shortly, but can't promise it'll make the Vancouver cut-off > date. > > PS: I also plan to be in Vancouver and look forward to seeing you there. > > Thanks, > Kent > > > On 10/3/13 3:15 AM, "Mikael Abrahamsson" wrote: > >> >> Hello. >> >> We have a use case where we want end systems and routers to be configured >> via Netconf/YANG and some of these might not be connectable from the >> Internet directly. The Reverse-SSH and rfc5539bis documents seem very >> relevant to implementation of this use case. >> >> I am currently in process of trying to document/develop architecture >> document for everything from bootstrap (key/certificate/other information >> distribution for a factory defaulted system) up until the device is fully >> provisioned and delivering services. There are quite a lot of question >> marks and gaps that need to be filled, where the ability to have the >> provision system being able to provision services, for instance via >> call-home is one part. >> >> There seems to have been very little progress on the reverse-SSH and TLS >> drafts in the past months? What's the current thinking on these? >> According >> to the time schedule in the charter the WGLC proposed time is long over. >> >> Is there anything I can do to help things along? I have read >> draft-ietf-netconf-reverse-ssh-01 and it seems perfectly viable for our >> deployment case as it is. >> >> Current thinking is to exchange cryptographic (and other) information via >> DHCPv6 to bootstrap ability for the netconf client and server to >> authenticate each other, and use public keys/host keys for login. I read >> some concerns that would interesting to hear more about. >> >> I will be attending IETF88 in Vancouver, but I would be a lot happier if >> the call home part at least had passed WGLC by then :) >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> _______________________________________________ >> 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 mehmet.ersue@nsn.com Mon Oct 7 04:24:26 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0F21E81C1 for ; Mon, 7 Oct 2013 04:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPbErZXkibEl for ; Mon, 7 Oct 2013 04:24:22 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDC821E8063 for ; Mon, 7 Oct 2013 04:24:21 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r97BOJ3q002794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 7 Oct 2013 13:24:19 +0200 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r97BOIFt011124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Oct 2013 13:24:18 +0200 Received: from DEMUHTC017.nsn-intra.net (10.159.42.48) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Oct 2013 13:24:18 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.164]) by DEMUHTC017.nsn-intra.net ([10.159.42.48]) with mapi id 14.03.0123.003; Mon, 7 Oct 2013 13:24:18 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: NOMCOM 2013 - Second Call for Nominations - two weeks left Thread-Index: AQHOw08YDH+KTQy6FkqEFkK1i1njd5npGHzA Date: Mon, 7 Oct 2013 11:24:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.123] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81BB9F1DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 25576 X-purgate-ID: 151667::1381145059-00005753-02FF2406/0-0/0-0 Subject: [Netconf] FW: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:24:27 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81BB9F1DEMUMBX005nsnintr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGNvbnNpZGVyIHRvIG5vbWluYXRlIHBlb3BsZSB5b3UgdGhpbmsgYXJlIGFwcHJvcHJp YXRlIGZvciB0aGUgb3BlbiBwb3NpdGlvbnMuDQoNCk1laG1ldA0KDQotLS0tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpOT01DT00gMjAxMyAtIFNlY29uZCBDYWxs IGZvciBOb21pbmF0aW9ucyAtIHR3byB3ZWVrcyBsZWZ0DQoNCkRhdGU6DQoNCkZyaSwgNCBPY3Qg MjAxMyAxMDozMTo0OSAtMDcwMA0KDQpGcm9tOg0KDQpOb21Db20gQ2hhaXIgMjAxMyA8bm9tY29t LWNoYWlyLTIwMTNAaWV0Zi5vcmc+PG1haWx0bzpub21jb20tY2hhaXItMjAxM0BpZXRmLm9yZz4N Cg0KUmVwbHktVG86DQoNCjxpZXRmQGlldGYub3JnPjxtYWlsdG86aWV0ZkBpZXRmLm9yZz4sIDxO b21jb21AaWV0ZmEuYW1zbC5jb20+PG1haWx0bzpOb21jb21AaWV0ZmEuYW1zbC5jb20+LCA8Q2hh aXJAaWV0ZmEuYW1zbC5jb20+PG1haWx0bzpDaGFpckBpZXRmYS5hbXNsLmNvbT4sIDwiMjAxMyA8 bm9tY29tLWNoYWlyLTIwMTMiQGlldGYub3JnPG1haWx0bzolMjIyMDEzJTIwJTNjbm9tY29tLWNo YWlyLTIwMTMlMjJAaWV0Zi5vcmc+Pg0KDQpUbzoNCg0KSUVURiBBbm5vdW5jZW1lbnQgTGlzdCA8 aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz48bWFpbHRvOmlldGYtYW5ub3VuY2VAaWV0Zi5vcmc+DQoN CkNDOg0KDQpJRVRGIERpc2N1c3MgTGlzdCA8aWV0ZkBpZXRmLm9yZz48bWFpbHRvOmlldGZAaWV0 Zi5vcmc+DQoNCg0KDQpOb21pbmF0aW9ucyBmb3IgdGhlIElFU0csIElBQiwgYW5kIElBT0MgYXJl IGR1ZSB0byB0aGUgTm9tY29tIGJ5IEZyaWRheSwgMTggT2N0b2JlciwgMjAxMy4NCg0KDQoNCklz IHRoZXJlIHNvbWVvbmUgeW91IHdvcmsgd2l0aCBhdCBJRVRGIHdobyBoYXMgbGVhZGVyc2hpcCBw b3RlbnRpYWwgYW5kIGEgZ3Jvd2luZyB0cmFjayByZWNvcmQ/IFBsZWFzZSByZWFkIHRoZSBOb21j b20gY2FsbCBmb3Igbm9taW5hdGlvbnMgYW5kIGNvbnNpZGVyIG5vbWluYXRpbmcgaGVyIG9yIGhp bS4gT3Igc2V2ZXJhbCBmb2xrcyEgRGVhZGxpbmUgZm9yIG5vbWluYXRpb25zIGlzIE9jdG9iZXIg MTguICBOb21pbmF0ZSBzb29uIHRvIGdpdmUgeW91ciBub21pbmVlKHMpIHBsZW50eSB0aW1lIHRv IGZpbGwgaW4gdGhlIHF1ZXN0aW9ubmFpcmUuIEluZm9ybWF0aW9uIGFib3V0IHRoZSBkZXNpcmVk IGV4cGVydGlzZSBmb3IgcG9zaXRpb25zIGlzIGhlcmU6DQoNCiAgICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxMy9leHBlcnRpc2UNCg0KDQoNCkxvdHMgbW9y ZSwgaW5jbHVkaW5nIHdoaWNoIHBvc2l0aW9ucyBhcmUgb3BlbiwgaG93IHRvIG1ha2UgYSBub21p bmF0aW9uLCBhbmQgaG93IHRvDQoNCnNlbmQgdXMgeW91ciBmZWVkYmFjayBvbiB0aGUgZGVzaXJl ZCBleHBlcnRpc2UsIGZvbGxvd3MuDQoNCg0KDQpJRVRGZXJzLCBsZXQncyBoZWFyIGZyb20geW91 ISAgTWFrZSBub21pbmF0aW9ucywgYWNjZXB0IG5vbWluYXRpb25zIQ0KDQoNCg0KSWYgeW91IGhh dmUgYW55IHF1ZXN0aW9ucyBhYm91dCB0aGUgcHJvY2VzcywgZmVlbCBmcmVlIHRvIGdldCBpbiB0 b3VjaCB3aXRoIG1lLg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KDQoNCg0KQWxsaXNvbiBmb3IgdGhl IE5vbWNvbQ0KDQoNCg0KQWxsaXNvbiBNYW5raW4NCg0KTm9tY29tIENoYWlyIDIwMTMtMTQNCg0K DQoNCi0tLS0tIFRoZSBJbmZvIFlvdSBOZWVkIGZvciBOb21pbmF0aW5nIC0tLS0tDQoNCg0KDQpU aGUgMjAxMy0xNCBOb21pbmF0aW5nIENvbW1pdHRlZSAoTm9tY29tKSBpcyBzZWVraW5nIG5vbWlu YXRpb25zDQoNCmZyb20gbm93IHVudGlsIE9jdG9iZXIgMTgsIDIwMTMuIFRoZSBvcGVuIHBvc2l0 aW9ucyBiZWluZyBjb25zaWRlcmVkDQoNCmJ5IHRoaXMgeWVhcidzIE5vbWNvbSBjYW4gYmUgZm91 bmQgbGF0ZXIgaW4gdGhpcyBzZWN0aW9uLCBhbmQgYWxzbyBvbg0KDQp0aGlzIHllYXIncyBOb21j b20gd2Vic2l0ZToNCg0KDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIw MTMvDQoNCg0KDQpOb21pbmF0aW9ucyBtYXkgYmUgbWFkZSBieSBzZWxlY3RpbmcgdGhlIE5vbWlu YXRlIGxpbmsgYXQgdGhlIHRvcCBvZg0KDQp0aGUgTm9tY29tIDIwMTMgaG9tZSBwYWdlLCBvciBi eSB2aXNpdGluZyB0aGUgZm9sbG93aW5nIFVSTDoNCg0KDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbm9tY29tLzIwMTMvbm9taW5hdGUvDQoNCg0KDQpOb3RlIHRoYXQgbm9taW5hdGlv bnMgbWFkZSB1c2luZyB0aGUgd2ViIHRvb2wgcmVxdWlyZSBhbiBpZXRmLm9yZw0KDQpkYXRhdHJh Y2tlciBhY2NvdW50LiBZb3UgY2FuIGNyZWF0ZSBhIGRhdGF0cmFja2VyIGlldGYub3JnIGFjY291 bnQNCg0KaWYgeW91IGRvbid0IGhhdmUgb25lIGFscmVhZHkgYnkgdmlzaXRpbmcgdGhlIGZvbGxv d2luZyBVUkw6DQoNCg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2FjY291bnRzL2Ny ZWF0ZS8NCg0KDQoNCk5vbWluYXRpb25zIG1heSBhbHNvIGJlIG1hZGUgYnkgZW1haWwgdG8gbm9t Y29tMTMgYXQgaWV0Zi5vcmcuDQoNCklmIHlvdSBub21pbmF0ZSBieSBlbWFpbCwgcGxlYXNlIGlu Y2x1ZGUgdGhlIHdvcmQgIk5vbWluYXRlIiBpbiB0aGUgU3ViamVjdA0KDQphbmQgaW5kaWNhdGUg aW4gdGhlIGVtYWlsIHdobyBpcyBiZWluZyBub21pbmF0ZWQsIHRoZWlyIGVtYWlsIGFkZHJlc3Mg KHRvDQoNCmNvbmZpcm0gYWNjZXB0YW5jZSBvZiB0aGUgbm9taW5hdGlvbiksIGFuZCB0aGUgcG9z aXRpb24gZm9yIHdoaWNoIHlvdQ0KDQphcmUgbWFraW5nIHRoZSBub21pbmF0aW9uLiBJZiB5b3Ug dXNlIGVtYWlsLCBwbGVhc2UgdXNlIGEgc2VwYXJhdGUgZW1haWwgZm9yDQoNCmVhY2ggcGVyc29u IHlvdSBub21pbmF0ZSwgYW5kIGZvciBlYWNoIHBvc2l0aW9uIChpZiB5b3UgYXJlIG5vbWluYXRp bmcgb25lDQoNCnBlcnNvbiBmb3IgbXVsdGlwbGUgcG9zaXRpb25zKS4NCg0KDQoNClNlbGYtbm9t aW5hdGlvbiBpcyB3ZWxjb21lISAgTm8gbmVlZCB0byBiZSBzaHkuDQoNCg0KDQpOb21jb20gMjAx My0xNCB3aWxsIGZvbGxvdyB0aGUgcG9saWN5IGZvciAiT3BlbiBEaXNjbG9zdXJlIG9mIFdpbGxp bmcNCg0KTm9taW5lZXMiIGRlc2NyaWJlZCBpbiBSRkMgNTY4MC4gIEFzIHN0YXRlZCBpbiBSRkMg NTY4MDogIlRoZSBsaXN0IG9mDQoNCm5vbWluZWVzIHdpbGxpbmcgdG8gYmUgY29uc2lkZXJlZCBm b3IgcG9zaXRpb25zIHVuZGVyIHJldmlldyBpbiB0aGUNCg0KY3VycmVudCBOb21jb20gY3ljbGUg aXMgbm90IGNvbmZpZGVudGlhbCIuIFdpbGxpbmcgbm9taW5lZXMgZm9yIGVhY2gNCg0KcG9zaXRp b24gd2lsbCBiZSBsaXN0ZWQgaW4gYSBwdWJsaWNseSBhY2Nlc3NpYmxlIHdheSAtIGFueW9uZSB3 aXRoIGENCg0KZGF0YXRyYWNrZXIgYWNjb3VudCBtYXkgYWNjZXNzIHRoZSBsaXN0cy4gIEluIGFs bCBvdGhlciB3YXlzLCB0aGUNCg0KY29uZmlkZW50aWFsaXR5IHJlcXVpcmVtZW50cyBvZiBSRkMg Mzc3Ny9CQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxsDQoNCmZlZWRiYWNrIGFuZCBhbGwgTm9t Y29tIGRlbGliZXJhdGlvbnMgd2lsbCByZW1haW4gY29uZmlkZW50aWFsIGFuZCB3aWxsDQoNCm5v dCBiZSBkaXNjbG9zZWQuDQoNCg0KDQpJbiBvcmRlciB0byBlbnN1cmUgdGltZSB0byBjb2xsZWN0 IHN1ZmZpY2llbnQgY29tbXVuaXR5IGZlZWRiYWNrIGFib3V0DQoNCmVhY2ggb2YgdGhlIHdpbGxp bmcgbm9taW5lZXMsIG5vbWluYXRpb25zIG11c3QgYmUgcmVjZWl2ZWQgYnkgdGhlDQoNCk5vbWNv bSBvbiBvciBiZWZvcmUgT2N0b2JlciAxOCwgMjAxMy4gIFBsZWFzZSBzdWJtaXQgeW91ciBub21p bmF0aW9ucw0KDQphcyBlYXJseSBhcyBwb3NzaWJsZSBmb3IgdGhlIHNha2Ugb2YgeW91ciBub21p bmVlcywgYXMgd2UndmUgc2V0IHRoZQ0KDQpxdWVzdGlvbm5haXJlIHN1Ym1pc3Npb24gZGVhZGxp bmUgZm9yIE9jdG9iZXIgMjUsIDIwMTMuDQoNCg0KDQpUaGUgbGlzdCBvZiBwZW9wbGUgYW5kIHBv c3RzIHdob3NlIHRlcm1zIGVuZCB3aXRoIHRoZSBNYXJjaCAyMDE0IElFVEYgbWVldGluZywNCg0K YW5kIHRodXMgdGhlIHBvc2l0aW9ucyBmb3Igd2hpY2ggd2UgYXJlIGFjY2VwdGluZyBub21pbmF0 aW9uczoNCg0KDQoNCklBT0MNCg0KQ2hyaXMgR3JpZmZpdGhzDQoNCg0KDQpJQUINCg0KQmVybmFy ZCBBYm9iYQ0KDQpNYXJjIEJsYW5jaGV0DQoNClJvc3MgQ2FsbG9uDQoNCkVsaW90IExlYXINCg0K SGFubmVzIFRzY2hvZmVuaWcNCg0KDQoNCklFU0cNCg0KQmFycnkgTGVpYmEgKEFwcGxpY2F0aW9u cykNCg0KQnJpYW4gSGFiZXJtYW4gKEludGVybmV0KQ0KDQpCZW5vaXQgQ2xhaXNlIChPcGVyYXRp b25zIGFuZCBNYW5hZ2VtZW50KQ0KDQpHb256YWxvIENhbWFyaWxsbyAoUkFJKQ0KDQpTdGV3YXJ0 IEJyeWFudCAoUm91dGluZykNCg0KU2VhbiBUdXJuZXIgKFNlY3VyaXR5KQ0KDQpNYXJ0aW4gU3Rp ZW1lcmxpbmcgKFRyYW5zcG9ydCkNCg0KDQoNClBsZWFzZSBiZSByZXNvdXJjZWZ1bCBpbiBpZGVu dGlmeWluZyBwb3NzaWJsZSBjYW5kaWRhdGVzIGZvciB0aGVzZQ0KDQpwb3NpdGlvbnMsIGFzIGRl dmVsb3Bpbmcgb3VyIHRhbGVudCBpcyBhIHZlcnkgY3J1Y2lhbCByZXF1aXJlbWVudCBmb3INCg0K dGhlIElFVEYuICBBbHNvLCBwbGVhc2UgZ2l2ZSBzZXJpb3VzIGNvbnNpZGVyYXRpb24gdG8gYWNj ZXB0aW5nIG5vbWluYXRpb25zDQoNCnlvdSByZWNlaXZlLg0KDQoNCg0KVGhlIHN1bW1hcmllcyBv ZiB0aGUgZGVzaXJlZCBleHBlcnRpc2UgZm9yIHRoZSBwb3NpdGlvbnMsIGRldmVsb3BlZCBieSB0 aGUNCg0KcmVzcGVjdGl2ZSBib2RpZXMsIGFyZSBmb3VuZCBhdDoNCg0KDQoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTMvZXhwZXJ0aXNlLw0KDQoNCg0KSW4gYWRkaXRp b24gdG8gbm9taW5hdGlvbnMsIHRoZSBOb21jb20gc2Vla3MgY29tbXVuaXR5IGlucHV0IG9uDQoN CnRoZSBwb3NpdGlvbnMgdGhlbXNlbHZlcy4gIFdlIG5lZWQgYW5kIHdlbGNvbWUgdGhlIGNvbW11 bml0eSdzDQoNCnZpZXdzIGFuZCBpbnB1dCBvbiB0aGUgam9icyB3aXRoaW4gZWFjaCBvcmdhbml6 YXRpb24uIElmIHlvdQ0KDQpoYXZlIGlkZWFzIG9uIHRoZSBwb3NpdGlvbnMnIHJlc3BvbnNpYmls aXRpZXMgKG1vcmUsIGxlc3MsDQoNCmRpZmZlcmVudCksIHBsZWFzZSBsZXQgdXMga25vdy4gIFlv dSBjYW4gc2VuZCB1cyBlbWFpbCBhYm91dCB0aGlzIHRvDQoNCm5vbWNvbTEzIGF0IGlldGYub3Jn LCBhbmQgd2Ugd2lsbCB1c2UgdGhpcyBmZWVkYmFjayBhY3RpdmVseS4NCg0KDQoNClRoYW5rIHlv dSBmb3IgeW91ciBoZWxwIGluIG5vbWluYXRpbmcgYSBncmVhdCBwb29sIG9mIHN0cm9uZyBhbmQg aW50ZXJlc3RpbmcNCg0Kbm9taW5lZXMhDQoNCg0KDQoNCg0KDQoNCi4NCg0KDQoNCg0K --_000_E4DE949E6CE3E34993A2FF8AE79131F81BB9F1DEMUMBX005nsnintr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiVmVyZGFuYSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOmJsdWU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlBsZWFzZSBjb25zaWRl ciB0byBub21pbmF0ZSBwZW9wbGUgeW91IHRoaW5rIGFyZSBhcHByb3ByaWF0ZSBmb3IgdGhlIG9w ZW4gcG9zaXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5NZWhtZXQ8L3NwYW4+PHNwYW4gbGFu Zz0iREUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0tLS0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0gPG86cD48L286cD48L3A+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGlu Zz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0i cGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJp Z2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+U3ViamVjdDogPG86cD48L286cD48L2I+ PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Tk9NQ09NIDIwMTMgLSBTZWNvbmQgQ2FsbCBmb3IgTm9taW5hdGlvbnMg LSB0d28gd2Vla3MgbGVmdDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQg bm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdo dCI+PGI+RGF0ZTogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGlu ZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJpLCA0IE9jdCAyMDEz IDEwOjMxOjQ5IC0wNzAwPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBu b3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0 Ij48Yj5Gcm9tOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5n OjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob21Db20gQ2hhaXIgMjAx MyA8YSBocmVmPSJtYWlsdG86bm9tY29tLWNoYWlyLTIwMTNAaWV0Zi5vcmciPg0KJmx0O25vbWNv bS1jaGFpci0yMDEzQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRl eHQtYWxpZ246cmlnaHQiPjxiPlJlcGx5LVRvOiA8bzpwPjwvbzpwPjwvYj48L3A+DQo8L3RkPg0K PHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+Jmx0O2lldGZAaWV0Zi5vcmcmZ3Q7PC9h PiwgPGEgaHJlZj0ibWFpbHRvOk5vbWNvbUBpZXRmYS5hbXNsLmNvbSI+DQombHQ7Tm9tY29tQGll dGZhLmFtc2wuY29tJmd0OzwvYT4sIDxhIGhyZWY9Im1haWx0bzpDaGFpckBpZXRmYS5hbXNsLmNv bSI+Jmx0O0NoYWlyQGlldGZhLmFtc2wuY29tJmd0OzwvYT4sICZsdDs8YSBocmVmPSJtYWlsdG86 JTIyMjAxMyUyMCUzY25vbWNvbS1jaGFpci0yMDEzJTIyQGlldGYub3JnIj4mcXVvdDsyMDEzICZs dDtub21jb20tY2hhaXItMjAxMyZxdW90O0BpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+ DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJw YWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmln aHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5UbzogPG86cD48L286cD48L2I+PC9wPg0K PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SUVURiBBbm5vdW5jZW1lbnQgTGlzdCA8YSBocmVmPSJtYWlsdG86aWV0Zi1hbm5v dW5jZUBpZXRmLm9yZyI+DQombHQ7aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZyZndDs8L2E+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3Ai IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5DQzogPG86cD48L286cD48 L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SUVURiBEaXNjdXNzIExpc3QgPGEgaHJlZj0ibWFpbHRvOmlldGZA aWV0Zi5vcmciPiZsdDtpZXRmQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHByZT5Ob21pbmF0 aW9ucyBmb3IgdGhlIElFU0csIElBQiwgYW5kIElBT0MgYXJlIGR1ZSB0byB0aGUgTm9tY29tIGJ5 IEZyaWRheSwgMTggT2N0b2JlciwgMjAxMy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JcyB0aGVyZSBzb21lb25lIHlvdSB3b3JrIHdpdGggYXQg SUVURiB3aG8gaGFzIGxlYWRlcnNoaXAgcG90ZW50aWFsIGFuZCBhIGdyb3dpbmcgdHJhY2sgcmVj b3JkPyBQbGVhc2UgcmVhZCB0aGUgTm9tY29tIGNhbGwgZm9yIG5vbWluYXRpb25zIGFuZCBjb25z aWRlciBub21pbmF0aW5nIGhlciBvciBoaW0uIE9yIHNldmVyYWwgZm9sa3MhIERlYWRsaW5lIGZv ciBub21pbmF0aW9ucyBpcyBPY3RvYmVyIDE4LiZuYnNwOyBOb21pbmF0ZSBzb29uIHRvIGdpdmUg eW91ciBub21pbmVlKHMpIHBsZW50eSB0aW1lIHRvIGZpbGwgaW4gdGhlIHF1ZXN0aW9ubmFpcmUu IEluZm9ybWF0aW9uIGFib3V0IHRoZSBkZXNpcmVkIGV4cGVydGlzZSBmb3IgcG9zaXRpb25zIGlz IGhlcmU6IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTMvZXhwZXJ0aXNlIj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDEzL2V4cGVydGlzZTwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Mb3RzIG1vcmUsIGluY2x1ZGlu ZyB3aGljaCBwb3NpdGlvbnMgYXJlIG9wZW4sIGhvdyB0byBtYWtlIGEgbm9taW5hdGlvbiwgYW5k IGhvdyB0byA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZW5kIHVzIHlvdXIgZmVlZGJhY2sgb24g dGhlIGRlc2lyZWQgZXhwZXJ0aXNlLCBmb2xsb3dzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPklFVEZlcnMsIGxldCdzIGhlYXIgZnJvbSB5b3Uh Jm5ic3A7IE1ha2Ugbm9taW5hdGlvbnMsIGFjY2VwdCBub21pbmF0aW9ucyE8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JZiB5b3UgaGF2ZSBhbnkg cXVlc3Rpb25zIGFib3V0IHRoZSBwcm9jZXNzLCBmZWVsIGZyZWUgdG8gZ2V0IGluIHRvdWNoIHdp dGggbWUuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPkFsbGlzb24gZm9yIHRoZSBOb21jb208bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BbGxpc29uIE1hbmtpbiA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5Ob21jb20gQ2hhaXIgMjAxMy0xNDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0tIFRoZSBJbmZvIFlvdSBOZWVkIGZv ciBOb21pbmF0aW5nIC0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+VGhlIDIwMTMtMTQgTm9taW5hdGluZyBDb21taXR0ZWUgKE5vbWNvbSkg aXMgc2Vla2luZyBub21pbmF0aW9uczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmZyb20gbm93IHVu dGlsIE9jdG9iZXIgMTgsIDIwMTMuIFRoZSBvcGVuIHBvc2l0aW9ucyBiZWluZyBjb25zaWRlcmVk PG86cD48L286cD48L3ByZT4NCjxwcmU+YnkgdGhpcyB5ZWFyJ3MgTm9tY29tIGNhbiBiZSBmb3Vu ZCBsYXRlciBpbiB0aGlzIHNlY3Rpb24sIGFuZCBhbHNvIG9uPG86cD48L286cD48L3ByZT4NCjxw cmU+dGhpcyB5ZWFyJ3MgTm9tY29tIHdlYnNpdGU6IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbm9tY29tLzIwMTMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNv bS8yMDEzLzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5Ob21pbmF0aW9ucyBtYXkgYmUgbWFkZSBieSBzZWxlY3RpbmcgdGhlIE5vbWluYXRl IGxpbmsgYXQgdGhlIHRvcCBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSBOb21jb20gMjAx MyBob21lIHBhZ2UsIG9yIGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOiA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDEzL25vbWluYXRlLyI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxMy9ub21pbmF0ZS88L2E+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Tm90ZSB0aGF0IG5vbWlu YXRpb25zIG1hZGUgdXNpbmcgdGhlIHdlYiB0b29sIHJlcXVpcmUgYW4gaWV0Zi5vcmcgPG86cD48 L286cD48L3ByZT4NCjxwcmU+ZGF0YXRyYWNrZXIgYWNjb3VudC4gWW91IGNhbiBjcmVhdGUgYSBk YXRhdHJhY2tlciBpZXRmLm9yZyBhY2NvdW50IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlmIHlv dSBkb24ndCBoYXZlIG9uZSBhbHJlYWR5IGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvYWNjb3VudHMvY3JlYXRlLyI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9hY2NvdW50cy9jcmVhdGUvPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5vbWluYXRpb25zIG1heSBh bHNvIGJlIG1hZGUgYnkgZW1haWwgdG8gbm9tY29tMTMgYXQgaWV0Zi5vcmcuPG86cD48L286cD48 L3ByZT4NCjxwcmU+SWYgeW91IG5vbWluYXRlIGJ5IGVtYWlsLCBwbGVhc2UgaW5jbHVkZSB0aGUg d29yZCAmcXVvdDtOb21pbmF0ZSZxdW90OyBpbiB0aGUgU3ViamVjdDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPmFuZCBpbmRpY2F0ZSBpbiB0aGUgZW1haWwgd2hvIGlzIGJlaW5nIG5vbWluYXRlZCwg dGhlaXIgZW1haWwgYWRkcmVzcyAodG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jb25maXJtIGFj Y2VwdGFuY2Ugb2YgdGhlIG5vbWluYXRpb24pLCBhbmQgdGhlIHBvc2l0aW9uIGZvciB3aGljaCB5 b3U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hcmUgbWFraW5nIHRoZSBub21pbmF0aW9uLiBJZiB5 b3UgdXNlIGVtYWlsLCBwbGVhc2UgdXNlIGEgc2VwYXJhdGUgZW1haWwgZm9yPG86cD48L286cD48 L3ByZT4NCjxwcmU+ZWFjaCBwZXJzb24geW91IG5vbWluYXRlLCBhbmQgZm9yIGVhY2ggcG9zaXRp b24gKGlmIHlvdSBhcmUgbm9taW5hdGluZyBvbmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wZXJz b24gZm9yIG11bHRpcGxlIHBvc2l0aW9ucykuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+U2VsZi1ub21pbmF0aW9uIGlzIHdlbGNvbWUhJm5ic3A7 IE5vIG5lZWQgdG8gYmUgc2h5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPk5vbWNvbSAyMDEzLTE0IHdpbGwgZm9sbG93IHRoZSBwb2xpY3kgZm9y ICZxdW90O09wZW4gRGlzY2xvc3VyZSBvZiBXaWxsaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+ Tm9taW5lZXMmcXVvdDsgZGVzY3JpYmVkIGluIFJGQyA1NjgwLiZuYnNwOyBBcyBzdGF0ZWQgaW4g UkZDIDU2ODA6ICZxdW90O1RoZSBsaXN0IG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+bm9taW5l ZXMgd2lsbGluZyB0byBiZSBjb25zaWRlcmVkIGZvciBwb3NpdGlvbnMgdW5kZXIgcmV2aWV3IGlu IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmN1cnJlbnQgTm9tY29tIGN5Y2xlIGlzIG5vdCBj b25maWRlbnRpYWwmcXVvdDsuIFdpbGxpbmcgbm9taW5lZXMgZm9yIGVhY2g8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5wb3NpdGlvbiB3aWxsIGJlIGxpc3RlZCBpbiBhIHB1YmxpY2x5IGFjY2Vzc2li bGUgd2F5IC0gYW55b25lIHdpdGggYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRhdGF0cmFja2Vy IGFjY291bnQgbWF5IGFjY2VzcyB0aGUgbGlzdHMuJm5ic3A7IEluIGFsbCBvdGhlciB3YXlzLCB0 aGUgPG86cD48L286cD48L3ByZT4NCjxwcmU+Y29uZmlkZW50aWFsaXR5IHJlcXVpcmVtZW50cyBv ZiBSRkMgMzc3Ny9CQ1AxMCByZW1haW4gaW4gZWZmZWN0LiZuYnNwOyBBbGw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5mZWVkYmFjayBhbmQgYWxsIE5vbWNvbSBkZWxpYmVyYXRpb25zIHdpbGwgcmVt YWluIGNvbmZpZGVudGlhbCBhbmQgd2lsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5vdCBiZSBk aXNjbG9zZWQuJm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPkluIG9yZGVyIHRvIGVuc3VyZSB0aW1lIHRvIGNvbGxlY3Qgc3VmZmljaWVu dCBjb21tdW5pdHkgZmVlZGJhY2sgYWJvdXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5lYWNoIG9m IHRoZSB3aWxsaW5nIG5vbWluZWVzLCBub21pbmF0aW9ucyBtdXN0IGJlIHJlY2VpdmVkIGJ5IHRo ZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ob21jb20gb24gb3IgYmVmb3JlIE9jdG9iZXIgMTgs IDIwMTMuJm5ic3A7IFBsZWFzZSBzdWJtaXQgeW91ciBub21pbmF0aW9ucyZuYnNwOyA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5hcyBlYXJseSBhcyBwb3NzaWJsZSBmb3IgdGhlIHNha2Ugb2YgeW91 ciBub21pbmVlcywgYXMgd2UndmUgc2V0IHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5xdWVz dGlvbm5haXJlIHN1Ym1pc3Npb24gZGVhZGxpbmUgZm9yIE9jdG9iZXIgMjUsIDIwMTMuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIGxpc3Qg b2YgcGVvcGxlIGFuZCBwb3N0cyB3aG9zZSB0ZXJtcyBlbmQgd2l0aCB0aGUgTWFyY2ggMjAxNCBJ RVRGIG1lZXRpbmcsIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFuZCB0aHVzIHRoZSBwb3NpdGlv bnMgZm9yIHdoaWNoIHdlIGFyZSBhY2NlcHRpbmcgbm9taW5hdGlvbnM6Jm5ic3A7IDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPklBT0M8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5DaHJpcyBHcmlmZml0aHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JQUI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5C ZXJuYXJkIEFib2JhPG86cD48L286cD48L3ByZT4NCjxwcmU+TWFyYyBCbGFuY2hldDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlJvc3MgQ2FsbG9uPG86cD48L286cD48L3ByZT4NCjxwcmU+RWxpb3Qg TGVhcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhhbm5lcyBUc2Nob2ZlbmlnPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SUVTRzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPkJhcnJ5IExlaWJhIChBcHBsaWNhdGlvbnMpPG86cD48L286cD48L3ByZT4N CjxwcmU+QnJpYW4gSGFiZXJtYW4gKEludGVybmV0KTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJl bm9pdCBDbGFpc2UgKE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQpPG86cD48L286cD48L3ByZT4N CjxwcmU+R29uemFsbyBDYW1hcmlsbG8gKFJBSSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdGV3 YXJ0IEJyeWFudCAoUm91dGluZyk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZWFuIFR1cm5lciAo U2VjdXJpdHkpPG86cD48L286cD48L3ByZT4NCjxwcmU+TWFydGluIFN0aWVtZXJsaW5nIChUcmFu c3BvcnQpPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+UGxlYXNlIGJlIHJlc291cmNlZnVsIGluIGlkZW50aWZ5aW5nIHBvc3NpYmxlIGNhbmRpZGF0 ZXMgZm9yIHRoZXNlPG86cD48L286cD48L3ByZT4NCjxwcmU+cG9zaXRpb25zLCBhcyBkZXZlbG9w aW5nIG91ciB0YWxlbnQgaXMgYSB2ZXJ5IGNydWNpYWwgcmVxdWlyZW1lbnQgZm9yPG86cD48L286 cD48L3ByZT4NCjxwcmU+dGhlIElFVEYuJm5ic3A7IEFsc28sIHBsZWFzZSBnaXZlIHNlcmlvdXMg Y29uc2lkZXJhdGlvbiB0byBhY2NlcHRpbmcgbm9taW5hdGlvbnM8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT55b3UgcmVjZWl2ZS4mbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86 cD48L286cD48L3ByZT4NCjxwcmU+VGhlIHN1bW1hcmllcyBvZiB0aGUgZGVzaXJlZCBleHBlcnRp c2UgZm9yIHRoZSBwb3NpdGlvbnMsIGRldmVsb3BlZCBieSB0aGUgPG86cD48L286cD48L3ByZT4N CjxwcmU+cmVzcGVjdGl2ZSBib2RpZXMsIGFyZSBmb3VuZCBhdDo8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDEzL2V4cGVydGlzZS8iPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTMvZXhwZXJ0aXNlLzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JbiBhZGRpdGlvbiB0byBub21pbmF0 aW9ucywgdGhlIE5vbWNvbSBzZWVrcyBjb21tdW5pdHkgaW5wdXQgb24gPG86cD48L286cD48L3By ZT4NCjxwcmU+dGhlIHBvc2l0aW9ucyB0aGVtc2VsdmVzLiZuYnNwOyBXZSBuZWVkIGFuZCB3ZWxj b21lIHRoZSBjb21tdW5pdHkncyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT52aWV3cyBhbmQgaW5w dXQgb24gdGhlIGpvYnMgd2l0aGluIGVhY2ggb3JnYW5pemF0aW9uLiBJZiB5b3UgPG86cD48L286 cD48L3ByZT4NCjxwcmU+aGF2ZSBpZGVhcyBvbiB0aGUgcG9zaXRpb25zJyByZXNwb25zaWJpbGl0 aWVzIChtb3JlLCBsZXNzLCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kaWZmZXJlbnQpLCBwbGVh c2UgbGV0IHVzIGtub3cuJm5ic3A7IFlvdSBjYW4gc2VuZCB1cyBlbWFpbCBhYm91dCB0aGlzIHRv PG86cD48L286cD48L3ByZT4NCjxwcmU+bm9tY29tMTMgYXQgaWV0Zi5vcmcsIGFuZCB3ZSB3aWxs IHVzZSB0aGlzIGZlZWRiYWNrIGFjdGl2ZWx5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdSBmb3IgeW91ciBoZWxwIGluIG5vbWlu YXRpbmcgYSBncmVhdCBwb29sIG9mIHN0cm9uZyBhbmQgaW50ZXJlc3Rpbmc8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5ub21pbmVlcyE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT4uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E4DE949E6CE3E34993A2FF8AE79131F81BB9F1DEMUMBX005nsnintr_-- From bclaise@cisco.com Mon Oct 7 15:03:57 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AACD11E8171; Mon, 7 Oct 2013 15:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGclJvdVX2Yt; Mon, 7 Oct 2013 15:03:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CA56411E8142; Mon, 7 Oct 2013 15:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=458; q=dns/txt; s=iport; t=1381183433; x=1382393033; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=isLyEex9WsGEMA1sT1eMJ4ygXn9LKqFilxzkd4UZPUI=; b=e+papz95NswVP/JOl49jYREE6at2Fv9gB6jDCq9Ba+7MfnLH+tKIKNcp vcZbn5RTTqB34OiX1qGfVacQa+w41hWP4QvYyXzf+W0lEq7aD8jctO7h8 yy6R3QpEBON83msicPy3Qy3gxuPu918Yg9l81NLITWkbxpJ7fOWkce6hu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAGkvU1KQ/khN/2dsb2JhbABZgwc4wGKBBwGBKhZ0glMRQD0WGAMCAQIBSwEMCAEBGIdqDLsyk3sDmAGBL4UHi0qDJjo X-IronPort-AV: E=Sophos;i="4.90,1051,1371081600"; d="scan'208";a="160428086" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2013 22:03:51 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r97M3kB7021203; Mon, 7 Oct 2013 22:03:48 GMT Message-ID: <52532FC2.9000804@cisco.com> Date: Tue, 08 Oct 2013 00:03:46 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Netconf] NETCONF/YANG tutorial under the training tab in the WG wiki X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 22:03:57 -0000 Dear all, From http://datatracker.ietf.org/wg/netmod/charter/ Or from http://datatracker.ietf.org/wg/netconf/charter/ -> Tools WG page -> Training tab Alternatively, directly go to http://trac.tools.ietf.org/wg/netmod/trac/wiki/TrainingMaterials (or http://trac.tools.ietf.org/wg/netconf/trac/wiki/TrainingMaterials. You will find a home for training material related to the WG charter, developed at the IETF. Regards, Benoit From kwatsen@juniper.net Tue Oct 8 09:39:09 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFB921E826D for ; Tue, 8 Oct 2013 09:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33kfcBpDqS-2 for ; Tue, 8 Oct 2013 09:39:03 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6684C21E8221 for ; Tue, 8 Oct 2013 09:38:57 -0700 (PDT) Received: from mail213-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Oct 2013 16:38:56 +0000 Received: from mail213-va3 (localhost [127.0.0.1]) by mail213-va3-R.bigfish.com (Postfix) with ESMTP id 6ED7F880119; Tue, 8 Oct 2013 16:38:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI62a3I98dI9371I936eI1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de097h186068h8275dhz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail213-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(24454002)(164054003)(51704005)(252514010)(189002)(199002)(377424004)(47736001)(81816001)(49866001)(15975445006)(76796001)(59766001)(46102001)(56816003)(50986001)(47976001)(76786001)(76482001)(85306002)(77982001)(51856001)(53806001)(4396001)(77096001)(56776001)(65816001)(76176001)(19580405001)(54316002)(80022001)(69226001)(83322001)(19580395003)(66066001)(54356001)(74366001)(31966008)(81342001)(83072001)(74706001)(79102001)(80976001)(74662001)(83506001)(81686001)(47446002)(63696002)(74876001)(81542001)(74502001)(36756003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB127; H:BY2PR05MB125.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail213-va3 (localhost.localdomain [127.0.0.1]) by mail213-va3 (MessageSwitch) id 138125033554047_10933; Tue, 8 Oct 2013 16:38:55 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.228]) by mail213-va3.bigfish.com (Postfix) with ESMTP id 009B1340048; Tue, 8 Oct 2013 16:38:55 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 8 Oct 2013 16:38:54 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 8 Oct 2013 16:38:53 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 8 Oct 2013 16:38:49 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.180]) by BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.171]) with mapi id 15.00.0775.005; Tue, 8 Oct 2013 16:38:48 +0000 From: Kent Watsen To: "Bert Wijnen (IETF)" Thread-Topic: [Netconf] call home Thread-Index: AQHOwAhjlfKwabhkFkWRMbnCKOHAzpni4U+AgAGE24CABmBjgA== Date: Tue, 8 Oct 2013 16:38:48 +0000 Message-ID: In-Reply-To: <524EA375.9060304@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [66.129.232.2] x-forefront-prvs: 0993689CD1 Content-Type: text/plain; charset="us-ascii" Content-ID: <7C2D22D92DD00349ADAD5C9A4BF5F6A3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "netconf@ietf.org" Subject: Re: [Netconf] call home X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:39:09 -0000 Just a quick update, the ZeroConf draft is written but is now going through an internal review. Since yesterday was the cutoff for WG -00 drafts, I'll submit this as an I-D and we can discuss in Vancouver if the WG is interested in chartering it... Thanks, Kent On 10/4/13 7:16 AM, "Bert Wijnen (IETF)" wrote: >Rmember that revision -00 drafts cutoff for Vancouver is > >2013-10-07 (Monday): Working Group Chair approval for initial document >(Version -00) submissions appreciated by UTC 24:00. >2013-10-11 (Friday): Final agenda to be published. >2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, >including -00) by UTC 24:00, upload using IETF ID Submission >Tool. > >SO if you plan to submit a revision-00 draft for the zero-conf, maybe we >should >prep-approve. However, that would mean that we see it s a WG draft right >away. >Maybe better as an individual draft first. > >Bert > >On 10/3/13 6:04 PM, Kent Watsen wrote: >> >> Hi Mikael, >> >> I'm currently working on a Reverse SSH reference implementation, which I >> hope to have completed in a few days. I then need to get it blessed by >> Juniper's Open Source Software committee before I can post it - >>hopefully >> that won't take too long. >> >> I also plan to update draft-ietf-netconf-reverse-ssh - really just need >>to >> clarify a few points and add an Applicability Statement that declares it >> only suitable for Network Management. >> >> Regarding how device discovery and secure key distribution can be >> implemented is outside the scope of the Reverse SSH draft, but it is >> exactly what the "ZeroConf" draft will address. ZeroConf was discussed >> during the Reverse SSH presentation in Berlin. Stephen Hanna and I took >>an >> action item to submit a draft for it. We went ahead and met with Russ >> Mundy and Wes Hardaker and sketched out a solution, which I hope to >>write >> a draft for shortly, but can't promise it'll make the Vancouver cut-off >> date. >> >> PS: I also plan to be in Vancouver and look forward to seeing you there. >> >> Thanks, >> Kent >> >> >> On 10/3/13 3:15 AM, "Mikael Abrahamsson" wrote: >> >>> >>> Hello. >>> >>> We have a use case where we want end systems and routers to be >>>configured >>> via Netconf/YANG and some of these might not be connectable from the >>> Internet directly. The Reverse-SSH and rfc5539bis documents seem very >>> relevant to implementation of this use case. >>> >>> I am currently in process of trying to document/develop architecture >>> document for everything from bootstrap (key/certificate/other >>>information >>> distribution for a factory defaulted system) up until the device is >>>fully >>> provisioned and delivering services. There are quite a lot of question >>> marks and gaps that need to be filled, where the ability to have the >>> provision system being able to provision services, for instance via >>> call-home is one part. >>> >>> There seems to have been very little progress on the reverse-SSH and >>>TLS >>> drafts in the past months? What's the current thinking on these? >>> According >>> to the time schedule in the charter the WGLC proposed time is long >>>over. >>> >>> Is there anything I can do to help things along? I have read >>> draft-ietf-netconf-reverse-ssh-01 and it seems perfectly viable for our >>> deployment case as it is. >>> >>> Current thinking is to exchange cryptographic (and other) information >>>via >>> DHCPv6 to bootstrap ability for the netconf client and server to >>> authenticate each other, and use public keys/host keys for login. I >>>read >>> some concerns that would interesting to hear more about. >>> >>> I will be attending IETF88 in Vancouver, but I would be a lot happier >>>if >>> the call home part at least had passed WGLC by then :) >>> >>> -- >>> Mikael Abrahamsson email: swmike@swm.pp.se >>> _______________________________________________ >>> 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 ietfdbh@comcast.net Tue Oct 8 14:29:20 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0ED321F9C42 for ; Tue, 8 Oct 2013 14:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5341PQ7VvPIw for ; Tue, 8 Oct 2013 14:29:16 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id C58F921F970E for ; Tue, 8 Oct 2013 14:29:15 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta15.westchester.pa.mail.comcast.net with comcast id ac0a1m0021ZXKqc5FlVEfL; Tue, 08 Oct 2013 21:29:14 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta21.westchester.pa.mail.comcast.net with comcast id alVE1m00E2yZEBF3hlVEib; Tue, 08 Oct 2013 21:29:14 +0000 From: "ietfdbh" To: "'Kent Watsen'" , "'Bert Wijnen \(IETF\)'" References: <524EA375.9060304@bwijnen.net> In-Reply-To: Date: Tue, 8 Oct 2013 17:29:18 -0400 Message-ID: <03ef01cec46d$7299e250$57cda6f0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFGu/LzeKhFyVZmZPh0XZEHUPmJYZr7Yg+w Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381267754; bh=/0tNTvTp5GIlfsFlKYZ6/Bqc92pfD+iutRoSgA6Dyds=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=tCpqFxhp8jZZBZFVgLkR06JBPtVEb27udnAha6Kal7bsm5K/4P5ejpqfGQLdfH5WV dhtqK+IjbWDM1ODds+tWlvetnnvhmJhiD1RLmB6H410JqbcrhHYhupGgC3OgfIVkQA Y8pdY1ofNxzi8lPyrMUIhUF2ZCuvCmM10fKO8Uhh21cHrl/VoWxlRUHNaXTDGVeP9b y5JE7v1cUlZ8uo2va6n8zdRhqcCOvOg3Qjd7AnPAWRZ3KORQnc9CgOpxfK2p0xpZmb UgHOA/4No/532bFeIY9R8U6KsgLzr91N8n2RdCo1rNn5fj9x7baFh5QInVJqG6tM6O A3GFbd88KoJyg== Cc: netconf@ietf.org Subject: Re: [Netconf] call home X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 21:29:20 -0000 Hi Kent, According to http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88 The deadline is the same for -00- and -0x- drafts. 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00, upload using IETF ID Submission Tool. 2013-10-07 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by UTC 24:00. Is only a request that WG Chairs approve early, to make the system work smoother. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Kent Watsen > Sent: Tuesday, October 08, 2013 12:39 PM > To: Bert Wijnen (IETF) > Cc: netconf@ietf.org > Subject: Re: [Netconf] call home > > > Just a quick update, the ZeroConf draft is written but is now going > through an internal review. Since yesterday was the cutoff for WG -00 > drafts, I'll submit this as an I-D and we can discuss in Vancouver if the > WG is interested in chartering it... > > Thanks, > Kent > > > On 10/4/13 7:16 AM, "Bert Wijnen (IETF)" wrote: > > >Rmember that revision -00 drafts cutoff for Vancouver is > > > >2013-10-07 (Monday): Working Group Chair approval for initial document > >(Version -00) submissions appreciated by UTC 24:00. > >2013-10-11 (Friday): Final agenda to be published. > >2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, > >including -00) by UTC 24:00, upload using IETF ID Submission > >Tool. > > > >SO if you plan to submit a revision-00 draft for the zero-conf, maybe we > >should > >prep-approve. However, that would mean that we see it s a WG draft right > >away. > >Maybe better as an individual draft first. > > > >Bert > > > >On 10/3/13 6:04 PM, Kent Watsen wrote: > >> > >> Hi Mikael, > >> > >> I'm currently working on a Reverse SSH reference implementation, which > I > >> hope to have completed in a few days. I then need to get it blessed by > >> Juniper's Open Source Software committee before I can post it - > >>hopefully > >> that won't take too long. > >> > >> I also plan to update draft-ietf-netconf-reverse-ssh - really just need > >>to > >> clarify a few points and add an Applicability Statement that declares it > >> only suitable for Network Management. > >> > >> Regarding how device discovery and secure key distribution can be > >> implemented is outside the scope of the Reverse SSH draft, but it is > >> exactly what the "ZeroConf" draft will address. ZeroConf was discussed > >> during the Reverse SSH presentation in Berlin. Stephen Hanna and I took > >>an > >> action item to submit a draft for it. We went ahead and met with Russ > >> Mundy and Wes Hardaker and sketched out a solution, which I hope to > >>write > >> a draft for shortly, but can't promise it'll make the Vancouver cut-off > >> date. > >> > >> PS: I also plan to be in Vancouver and look forward to seeing you there. > >> > >> Thanks, > >> Kent > >> > >> > >> On 10/3/13 3:15 AM, "Mikael Abrahamsson" > wrote: > >> > >>> > >>> Hello. > >>> > >>> We have a use case where we want end systems and routers to be > >>>configured > >>> via Netconf/YANG and some of these might not be connectable from > the > >>> Internet directly. The Reverse-SSH and rfc5539bis documents seem very > >>> relevant to implementation of this use case. > >>> > >>> I am currently in process of trying to document/develop architecture > >>> document for everything from bootstrap (key/certificate/other > >>>information > >>> distribution for a factory defaulted system) up until the device is > >>>fully > >>> provisioned and delivering services. There are quite a lot of question > >>> marks and gaps that need to be filled, where the ability to have the > >>> provision system being able to provision services, for instance via > >>> call-home is one part. > >>> > >>> There seems to have been very little progress on the reverse-SSH and > >>>TLS > >>> drafts in the past months? What's the current thinking on these? > >>> According > >>> to the time schedule in the charter the WGLC proposed time is long > >>>over. > >>> > >>> Is there anything I can do to help things along? I have read > >>> draft-ietf-netconf-reverse-ssh-01 and it seems perfectly viable for our > >>> deployment case as it is. > >>> > >>> Current thinking is to exchange cryptographic (and other) information > >>>via > >>> DHCPv6 to bootstrap ability for the netconf client and server to > >>> authenticate each other, and use public keys/host keys for login. I > >>>read > >>> some concerns that would interesting to hear more about. > >>> > >>> I will be attending IETF88 in Vancouver, but I would be a lot happier > >>>if > >>> the call home part at least had passed WGLC by then :) > >>> > >>> -- > >>> Mikael Abrahamsson email: swmike@swm.pp.se > >>> _______________________________________________ > >>> 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 mehmet.ersue@nsn.com Thu Oct 10 12:28:29 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C4711E80E7 for ; Thu, 10 Oct 2013 12:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d37vYDjajscg for ; Thu, 10 Oct 2013 12:28:20 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A41D621E8097 for ; Thu, 10 Oct 2013 12:28:07 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r9AJS2Ke001967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Oct 2013 21:28:02 +0200 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9AJS195003721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 21:28:01 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.164]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Thu, 10 Oct 2013 21:28:01 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: Preliminary agenda for IETF #88 Netconf session Thread-Index: Ac7F7tST+4GtNRgSTXijt8ag4I4DVQ== Date: Thu, 10 Oct 2013 19:28:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.123] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81C0A3EDEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2609 X-purgate-ID: 151667::1381433282-00004A43-CBF94D71/0-0/0-0 Subject: [Netconf] Preliminary agenda for IETF #88 Netconf session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 19:28:29 -0000 X-List-Received-Date: Thu, 10 Oct 2013 19:28:29 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81C0A3EDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, please find below the preliminary agenda for the Netconf session in IETF #8= 8. http://www.ietf.org/proceedings/88/agenda/agenda-88-netconf Please let us know your comments and whether there is any interest for othe= r topics to discuss. Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F81C0A3EDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
please find below the preliminary agenda for the = Netconf session in IETF #88.
 
 
Please let us know your comments and whether ther= e is any interest for other topics to discuss.
 
Mehmet
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F81C0A3EDEMUMBX005nsnintr_-- From j.schoenwaelder@jacobs-university.de Mon Oct 14 23:34:07 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A0711E815C for ; Mon, 14 Oct 2013 23:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R09vtkCTEjDW for ; Mon, 14 Oct 2013 23:34:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 428B511E8172 for ; Mon, 14 Oct 2013 23:33:59 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F54A2004E; Tue, 15 Oct 2013 08:33:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 68Pk8IscRhwQ; Tue, 15 Oct 2013 08:33:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7D0E2004D; Tue, 15 Oct 2013 08:33:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 23BC628D894D; Tue, 15 Oct 2013 08:33:52 +0200 (CEST) Date: Tue, 15 Oct 2013 08:33:51 +0200 From: Juergen Schoenwaelder To: Mikael Abrahamsson Message-ID: <20131015063351.GC24078@elstar.local> Mail-Followup-To: Mikael Abrahamsson , netconf@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] call home X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 06:34:07 -0000 On Thu, Oct 03, 2013 at 09:15:05AM +0200, Mikael Abrahamsson wrote: > > There seems to have been very little progress on the reverse-SSH and > TLS drafts in the past months? What's the current thinking on these? > According to the time schedule in the charter the WGLC proposed time > is long over. > The TLS draft needs an update to reflect the changes discussed in Berlin (namely doing the role swap before TLS starts). I hope to get this done by the I-D deadline. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From balazs.lengyel@ericsson.com Thu Oct 17 08:43:19 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D4A11E8266 for ; Thu, 17 Oct 2013 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZgUOo9kqeSO for ; Thu, 17 Oct 2013 08:43:12 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 765EA11E825D for ; Thu, 17 Oct 2013 08:43:12 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-d2-5260058f4b12 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8E.EC.03802.F8500625; Thu, 17 Oct 2013 17:43:11 +0200 (CEST) Received: from [159.107.197.203] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Thu, 17 Oct 2013 17:43:10 +0200 Message-ID: <5260058E.1060302@ericsson.com> Date: Thu, 17 Oct 2013 17:43:10 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOJMWRmVeSWpSXmKPExsUyM+JvjW4/a0KQwalXUhZTN91mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoGJm5kLfrBXnJj1nbWBsZOti5GTQ0LAROLc8h3MELaYxIV7 64HiXBxCAocZJdb9OsoC4axllNjzYTcTSBWvgLbE5PdXwGwWAVWJm/3vwSaxCRhJTO0/zwJi iwpESWzYfoEFol5Q4uTMJ2C2CNCGj+cfgm0TFrCQaLq5CayXWcBW4sKc6ywQtrzE9rdzwGqE BDQkHl74yzqBkW8WklGzkLTMQtKygJF5FSN7bmJmTnq50SZGYOAc3PJbdQfjnXMihxilOViU xHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC43dlKgT3rcaF8+61Ta2z+LWnb6bbU UX0lX+HXnhil4tC3S3jZuer/aHhZZKRasjfbNs3N+3SnKjFzZXLmzLmBmt3ttpVLyqOdvc4f 63/+921+1PtnnutW7Fi/VWPZI9Zk811Mns5y/ibCxzb+8mC9lKIuaNbSnqniWekqdH/rE+OO 3CXxMkosxRmJhlrMRcWJAGH0+T3qAQAA Subject: [Netconf] Global lock - is it good - do you implement it? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 15:43:19 -0000 Hello, Maybe this has been asked already, in this case sorry? We see a number of problems with the global lock - you might want multiple operators working on different part of the system, global lock can't be used - data set by automation (on-board or off-board)/SON/SDN conflicts with a global lock, If you lock the datastore the automated algorithms stop - access control for global locking is a problem. You either don't use lock or you need to give every operator the right to block configuration of the full node. Neither is good. - many systems have database style automatic implicit locking, these don't need explicit locking, it just makes life difficult Considering all these, why is explicit global locking mandatory? Also do you really implement it? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From j.schoenwaelder@jacobs-university.de Thu Oct 17 09:01:50 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7479311E827B for ; Thu, 17 Oct 2013 09:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pxq1g2ovcmRr for ; Thu, 17 Oct 2013 09:01:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9377811E8283 for ; Thu, 17 Oct 2013 09:00:51 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C974D2002F; Thu, 17 Oct 2013 18:00:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id F0MNAmgAOkGa; Thu, 17 Oct 2013 18:00:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B4342002E; Thu, 17 Oct 2013 18:00:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D292A28DE0A2; Thu, 17 Oct 2013 18:00:43 +0200 (CEST) Date: Thu, 17 Oct 2013 18:00:43 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20131017160043.GA32446@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf@ietf.org References: <5260058E.1060302@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5260058E.1060302@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Global lock - is it good - do you implement it? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:01:51 -0000 On Thu, Oct 17, 2013 at 05:43:10PM +0200, Balazs Lengyel wrote: [...] > Considering all these, why is explicit global locking mandatory? > Also do you really implement it? I do not understand the question. Global locks are mandatory to implement, not mandatory to use. If partial locks (RFC 5717) work better for you, then use them. Or is the question you really want to get at whether partial locks should be mandatory? That question I would understand given your motiviation (that I trimmed). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Oct 17 09:23:57 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B1411E827C for ; Thu, 17 Oct 2013 09:23:57 -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=[AWL=-0.690, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9XCcYNM8lp3 for ; Thu, 17 Oct 2013 09:23:53 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id DC26A11E8278 for ; Thu, 17 Oct 2013 09:23:38 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kl14so3030055pab.11 for ; Thu, 17 Oct 2013 09:23: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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=i2wxWSZMyXZgOs4mtAa7Y1NOduk289rACNBsepPYLMI=; b=RGHSKp/8kOYk39xxnOyAqKTZhu276G6okuusqySAyQYO8YN+ayMWTtPLmO3K7vZ5po XUO1QuWhHpgukn1z0Ma7suWo5mZR6D/9woUQSduspsJC+nSFlg0yxRm0vHBUerS0YjHs yOwG+IkDMs6YyE6ovtPXcCqh33ot24i8du4Yn0qKB/L9Q9i+2TudAqJt+JaezjnwUyaU h6hyQY9zUKgG5KNBDWg4YiI3AvGawE1RX+UIYrmJSbdF2wBaBb+ihyHbHxPpmHbU4lh2 1v73dtwWKFg0KQnkbriBf28sFOQLwXfl22QXQ1V3IV+C+hvne5fEsmO2LtYRv/cftjCi 6XhA== X-Gm-Message-State: ALoCoQnoShQF3kNGxgpdTa9fuL3/rUWP258X5tgakf591IlkDRjMtv8nBQuSDGhOtMZPcic6uQ57 MIME-Version: 1.0 X-Received: by 10.66.102.100 with SMTP id fn4mr10063840pab.71.1382027017120; Thu, 17 Oct 2013 09:23:37 -0700 (PDT) Received: by 10.70.9.33 with HTTP; Thu, 17 Oct 2013 09:23:36 -0700 (PDT) In-Reply-To: <5260058E.1060302@ericsson.com> References: <5260058E.1060302@ericsson.com> Date: Thu, 17 Oct 2013 09:23:36 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=047d7bd9036c6d083f04e8f23d98 Cc: Netconf Subject: Re: [Netconf] Global lock - is it good - do you implement it? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:23:57 -0000 --047d7bd9036c6d083f04e8f23d98 Content-Type: text/plain; charset=ISO-8859-1 Hi Balazs, You are mixing apples and oranges. NETCONF locking provides a crude exclusive write access mechanism. It does not provide any concurrent writing features. Its sole purpose is to prevent concurrent writes on a datastore. An architecture that provides implicit locking and concurrent writes is difficult to integrate into the current NETCONF locking model. I haven't figured that part out. I don't think it is possible. BTW, you forgot to mention that global locks also cause a security hole because a user with no write access can still (by default) lock any datastore. And you forgot my other pet problem with global locks -- client deadlock, because a client can only lock 1 datastore at a time. E.g. - server supports candidate and running - client 1 gets a lock on running - client 2 gets a lock on candidate - client 1 is blocked trying over and over to get a lock on candidate (or it releases running and starts over) - client 2 is also stuck, but waiting for the lock on running to clear Andy On Thu, Oct 17, 2013 at 8:43 AM, Balazs Lengyel wrote: > Hello, > Maybe this has been asked already, in this case sorry? > We see a number of problems with the global lock > - you might want multiple operators working on different part of the > system, global lock can't be used > - data set by automation (on-board or off-board)/SON/SDN conflicts with a > global lock, If you lock the datastore the automated algorithms stop > - access control for global locking is a problem. You either don't use > lock or you need to give every operator the right to block configuration of > the full node. Neither is good. > - many systems have database style automatic implicit locking, these don't > need explicit locking, it just makes life difficult > > Considering all these, why is explicit global locking mandatory? Also do > you really implement it? > regards Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > ______________________________**_________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/**listinfo/netconf > --047d7bd9036c6d083f04e8f23d98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Balazs,

You are mixing apples and or= anges.
NETCONF locking provides a crude exclusive write access me= chanism.
It does not provide any concurrent writing features. Its= sole purpose
is to prevent concurrent writes on a datastore.

An architecture that provides implicit locking and concurrent writes
is difficult to integrate into the current NETCONF locking model.
I haven't figured that part out. =A0I don't think it is possib= le.

BTW, you forgot to mention that global locks a= lso cause a security hole
because a user with no write access can= still (by default) lock any datastore.

And you forgot my other pet problem with global locks -= - client deadlock,
because a client can only lock 1 datastore at = a time. =A0E.g.

=A0 =A0- server supports candidate= and running
=A0 =A0- client 1 gets a lock on running
=A0 =A0- client 2 g= ets a lock on candidate
=A0 =A0- client 1 is blocked trying over = and over to get a lock on
=A0 =A0 =A0candidate (or it releases ru= nning and starts over)
=A0 =A0- client 2 is also stuck, but waiting for the lock on running t= o clear


Andy




On Thu= , Oct 17, 2013 at 8:43 AM, Balazs Lengyel <balazs.lengyel@ericss= on.com> wrote:
Hello,
Maybe this has been asked already, in this case sorry?
We see a number of problems with the global lock
- you might want multiple operators working on different part of the system= , global lock can't be used
- data set by automation (on-board or off-board)/SON/SDN =A0conflicts with = a global lock, If you lock the datastore the automated algorithms stop
- access control for global locking is a problem. You either don't use = lock or you need to give every operator the right to block configuration of= the full node. Neither is good.
- many systems have database style automatic implicit locking, these don= 9;t need explicit locking, it just makes life difficult

Considering all these, why is explicit global locking mandatory? Also do yo= u really implement it?
regards Balazs

--
Balazs Lengyel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ericsson Hungary= Ltd.
System Manager
ECN: 831 7320 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tel: +36-1-437= -7320
Mobile: +36-70-330-7909 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: Balazs.Lengyel@ericsson.com=

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

--047d7bd9036c6d083f04e8f23d98-- From j.schoenwaelder@jacobs-university.de Thu Oct 17 10:18:38 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F5E11E81A2 for ; Thu, 17 Oct 2013 10:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.214 X-Spam-Level: X-Spam-Status: No, score=-103.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ8N9lmWNq+t for ; Thu, 17 Oct 2013 10:18:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D119221F943C for ; Thu, 17 Oct 2013 10:18:32 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5103620030; Thu, 17 Oct 2013 19:18:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id v9Tk1AFl9JHH; Thu, 17 Oct 2013 19:18:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE5B02002F; Thu, 17 Oct 2013 19:18:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BDD4828DE22B; Thu, 17 Oct 2013 19:18:24 +0200 (CEST) Date: Thu, 17 Oct 2013 19:18:23 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20131017171823.GA32616@elstar.local> Mail-Followup-To: Andy Bierman , Balazs Lengyel , Netconf References: <5260058E.1060302@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Global lock - is it good - do you implement it? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:18:38 -0000 On Thu, Oct 17, 2013 at 09:23:36AM -0700, Andy Bierman wrote: > BTW, you forgot to mention that global locks also cause a security hole > because a user with no write access can still (by default) lock any > datastore. Simply deny the lock operation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Oct 17 10:26:02 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDE011E8287 for ; Thu, 17 Oct 2013 10:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ1UQbB4L6vB for ; Thu, 17 Oct 2013 10:25:57 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id E68ED11E8146 for ; Thu, 17 Oct 2013 10:25:39 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so2589049pbb.41 for ; Thu, 17 Oct 2013 10:25:39 -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:content-type; bh=PexhW2Ji3c/QC7VvXtQfTbXrfscbTcb8SYreIouvmmc=; b=d2D4naHKnOLeS8NPgx/9x0+fZnLjcUXd97PWAxThYW167+K3MK132nQ6+XAusdMMja 7sGm5ZYcwimA+jrqGNOtEESZupV0envyNjjHV5VCHvTHmCdPeSgxe6s9zVAXBb8ZNWBE RBbmp/XXI/B5ROFII3lHld8xl+HY6k0DNV/BP0CTJcOT+hxkLBm88PO1ye/9GCP/uoT7 DVHzj2cq0dLeQtVbmJMkIQmiJVGpKcJ5CrvnVc/oUy3QCNJq4v8f+NIfqLMg0ihnWy+F GQJb4GmnVBjkAYH7EMFPVFTkRjar/8c+eJoYIUxLJuvEp5h4VFxE1rvD5xwzUzQ49V8p Nu8Q== X-Gm-Message-State: ALoCoQkeon/C8tkBC1VfPEDgOUcNG/VCbXyFbLGW/MIQjLT2hqFd6vhUcA0rmYQoTwLNkUMa6Elw MIME-Version: 1.0 X-Received: by 10.66.230.233 with SMTP id tb9mr10471374pac.38.1382030739438; Thu, 17 Oct 2013 10:25:39 -0700 (PDT) Received: by 10.70.9.33 with HTTP; Thu, 17 Oct 2013 10:25:39 -0700 (PDT) In-Reply-To: <20131017171823.GA32616@elstar.local> References: <5260058E.1060302@ericsson.com> <20131017171823.GA32616@elstar.local> Date: Thu, 17 Oct 2013 10:25:39 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Balazs Lengyel , Netconf Content-Type: multipart/alternative; boundary=047d7b111f3b4b0f1404e8f31bf4 Subject: Re: [Netconf] Global lock - is it good - do you implement it? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:26:02 -0000 --047d7b111f3b4b0f1404e8f31bf4 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 17, 2013 at 10:18 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Oct 17, 2013 at 09:23:36AM -0700, Andy Bierman wrote: > > > BTW, you forgot to mention that global locks also cause a security hole > > because a user with no write access can still (by default) lock any > > datastore. > > Simply deny the lock operation. > > I suppose. Actually, taking a lock if the session has read access to the datastore is fine. I meant to say that a session with no read or write access at all is very likely to have exec access to . This is the NACM default. > /js > Andy --047d7b111f3b4b0f1404e8f31bf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Oct 17, 2013 at 10:18 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Oct 17, 2013 at 09:23:36AM -0700, An= dy Bierman wrote:

> BTW, you forgot to mention that global locks also cause a security hol= e
> because a user with no write access can still (by default) lock any > datastore.

Simply deny the lock operation.



I suppose. =A0Actually, taking a lock= if the session has read access
to the datastore is fine. =A0I me= ant to say that a session with no
read or write access at all is very likely to have exec access to <= lock>.
This is the NACM default.

=A0<= /div>
/js

Andy
=A0
--047d7b111f3b4b0f1404e8f31bf4-- From andy@yumaworks.com Sat Oct 19 11:29:15 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ECE11E8265 for ; Sat, 19 Oct 2013 11:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.833 X-Spam-Level: X-Spam-Status: No, score=-2.833 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz8-E+hm1+Kg for ; Sat, 19 Oct 2013 11:29:11 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id EB7F111E8262 for ; Sat, 19 Oct 2013 11:29:08 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id k15so1541683qaq.5 for ; Sat, 19 Oct 2013 11:29:08 -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:content-type; bh=mv20ttlLXVaOPoKNLW8g6gbdiptPapRkq+YaURjqfdw=; b=NolkvWFjIB+b1tXQ6LY6bVYzn6EsXXQoTobfW9QjRakWP0eHMI3VLfUH5jvQH4r/bL q0ASmDUwTjWrsrEW47yCF/hqQ6L1rLGxaoruu0UF0s8Oos/mLQGA8t5bK82NO3tm0fx1 HH96PhbsBrU94tW2MPSSp7fcKd8wmsfBUoQKPCjlnXBqK5RNe6CyjODI3wEzodJ69YFF f9fV0WlCQEbIJu6fHqsybzh/wlLHCObq7rNypN2KiHLgDq0Hfwzw3MsYZDcKbxbPiuvV +nm9KKB+Rionu6mKGLh+ZQo9WbahOGQRM2+wwH2y4+2wACUwfhvadt2mn5VX5U7hPpF/ b4+Q== X-Gm-Message-State: ALoCoQlYQNB1zCD8O9vixi+Zl3SyYOPFsA1bvG57e2fAkQwAa01u5f9Tgd1wLAXCMifYvOpgxZYA MIME-Version: 1.0 X-Received: by 10.229.251.201 with SMTP id mt9mr3238216qcb.26.1382207348234; Sat, 19 Oct 2013 11:29:08 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Sat, 19 Oct 2013 11:29:08 -0700 (PDT) In-Reply-To: <20131019182501.9630.90227.idtracker@ietfa.amsl.com> References: <20131019182501.9630.90227.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 11:29:08 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a1134a8e2ff9f5804e91c393b Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 18:29:15 -0000 --001a1134a8e2ff9f5804e91c393b Content-Type: text/plain; charset=ISO-8859-1 Hi, The RESTCONF draft has been updated with several changes (see draft for list). The biggest changes: - add notification support - split 'datastore' into 'config' and 'operational' thanks, Andy ---------- Forwarded message ---------- From: Date: Sat, Oct 19, 2013 at 11:25 AM Subject: I-D Action: draft-bierman-netconf-restconf-02.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RESTCONF Protocol Author(s) : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-bierman-netconf-restconf-02.txt Pages : 109 Date : 2013-10-19 Abstract: This document describes a RESTful protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netconf-restconf-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-restconf-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a1134a8e2ff9f5804e91c393b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The RESTCONF draft has been updated= with several changes (see draft for list).
The biggest changes:<= /div>
=A0 - add notification support
=A0 - split 'datasto= re' into 'config' and 'operational'

thanks,
Andy


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sat, Oct 19, 2013 at 11:25 AM
Subject: I-D Action: draft-bierman-n= etconf-restconf-02.txt
To: i-d-= announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RESTCONF Protocol
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Andy Bierman
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Bjorklund
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kent Watsen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rex Fernando
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netconf-restconf-02= .txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 109
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-19

Abstract:
=A0 =A0This document describes a RESTful protocol that provides a
=A0 =A0programmatic interface over HTTP for accessing data defined in YANG,=
=A0 =A0using the datastores defined in NETCONF.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-r= estconf

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-restconf-0= 2

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-ne= tconf-restconf-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a1134a8e2ff9f5804e91c393b-- From andy@yumaworks.com Sat Oct 19 11:34:34 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2C321F9F45 for ; Sat, 19 Oct 2013 11:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.836 X-Spam-Level: X-Spam-Status: No, score=-2.836 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVWBe3qv6ipu for ; Sat, 19 Oct 2013 11:34:29 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id B900721F9EF6 for ; Sat, 19 Oct 2013 11:34:17 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id j15so1547974qaq.6 for ; Sat, 19 Oct 2013 11:34:17 -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:content-type; bh=DhqVGf/UYIu/LZzkljPK+QzsWYKwXcsMWOagcI5VysE=; b=Dt02cfz1l0daclebP+t6/ouA9iPbmkNw84vaip7EE6xivAxCKkIhM1zq98NGfqWWCi YOl8BAoNrxkcacDUBg0H9Yv/R8SqBda6Jx3946daUAxH31KbusSgeRIuuLFp95KBNhFs 6SbUGGg8f+SSCJ2jbsGc/kO1yFNp4NqikEa+DgPTopNzZdwuJIL6RTNP8CnPx4M5D792 DL6Cnf1nRR+i5a0Voq+vqUWoTo14ImlrZyrVG1x0zYcI6XfKDreMi8l5HBojG/JWTmr1 Nq/SQYhaov52Wfmw7UFuFZ2Q11mM1szeK7eBemMyBw/lnPA8QpfycBdr5Jq49I1Oy26N NL5A== X-Gm-Message-State: ALoCoQm9BXiodGQl/9XzmwdENV34VRyekXygPHFtuWlmqrvDjE9F9ghbPBYy256fyUgyqmDpig98 MIME-Version: 1.0 X-Received: by 10.224.51.199 with SMTP id e7mr12550465qag.41.1382207656999; Sat, 19 Oct 2013 11:34:16 -0700 (PDT) Received: by 10.140.21.175 with HTTP; Sat, 19 Oct 2013 11:34:16 -0700 (PDT) In-Reply-To: <20131019182625.9578.25416.idtracker@ietfa.amsl.com> References: <20131019182625.9578.25416.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 11:34:16 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c29f4066cadf04e91c4cdf Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-efficiency-extensions-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 18:34:34 -0000 --001a11c29f4066cadf04e91c4cdf Content-Type: text/plain; charset=ISO-8859-1 Hi, I have written a draft called NETCONF Efficiency Extensions (NETCONF-EX) to propose some optimizations designed to maintain or increase functionality but with significantly less network usage. The goal is to make NETCONF useful in deployments where network resources are severely constrained wrt/ bandwidth, stability, and/or latency. Andy ---------- Forwarded message ---------- From: Date: Sat, Oct 19, 2013 at 11:26 AM Subject: I-D Action: draft-bierman-netconf-efficiency-extensions-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NETCONF Efficiency Extensions Author(s) : Andy Bierman Filename : draft-bierman-netconf-efficiency-extensions-00.txt Pages : 76 Date : 2013-10-19 Abstract: This document describes protocol extensions to improve the efficiency of the Network Configuration Protocol (NETCONF). Protocol capabilities and operations are defined to reduce network usage and transaction complexity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netconf-efficiency-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11c29f4066cadf04e91c4cdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have written a draft called NETCO= NF Efficiency Extensions
(NETCONF-EX) to propose some optimizatio= ns designed to
maintain or increase functionality but with signif= icantly less
network usage. =A0The goal is to make NETCONF useful
in depl= oyments where network resources are severely constrained
wrt/ ban= dwidth, stability, and/or latency.


Andy


---------- Forwarded mess= age ----------
From: <internet-drafts@ietf.org<= /a>>
Date: Sat, Oct 19, 2013 at 11:26 AM
Subject: I-D Action: draft-bierman-n= etconf-efficiency-extensions-00.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : NETCONF Efficiency Extensions =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Andy Bierman
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netconf-efficiency-= extensions-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 76
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-19

Abstract:
=A0 =A0This document describes protocol extensions to improve the efficienc= y
=A0 =A0of the Network Configuration Protocol (NETCONF). =A0Protocol
=A0 =A0capabilities and operations are defined to reduce network usage and<= br> =A0 =A0transaction complexity.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bier= man-netconf-efficiency-extensions

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netco= nf-efficiency-extensions-00


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11c29f4066cadf04e91c4cdf-- From swmike@swm.pp.se Mon Oct 21 01:01:39 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906A011E834C for ; Mon, 21 Oct 2013 01:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT+LGdYPTLTo for ; Mon, 21 Oct 2013 01:01:35 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 24BB611E835C for ; Mon, 21 Oct 2013 01:01:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5C2F79C; Mon, 21 Oct 2013 10:01:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 53CA19A for ; Mon, 21 Oct 2013 10:01:33 +0200 (CEST) Date: Mon, 21 Oct 2013 10:01:33 +0200 (CEST) From: Mikael Abrahamsson To: netconf@ietf.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Subject: [Netconf] FW: New Version Notification for draft-fa-netconf-dhcpv6-option-00.txt (fwd) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 08:01:39 -0000 Hello. We would like a 5-10 minute slot in Vancouver to present this draft. Thanks. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: den 21 oktober 2013 09:59 To: Mikael Abrahamsson; Ian Farrer Subject: New Version Notification for draft-fa-netconf-dhcpv6-option-00.txt A new version of I-D, draft-fa-netconf-dhcpv6-option-00.txt has been successfully submitted by Ian Farrer and posted to the IETF repository. Filename: draft-fa-netconf-dhcpv6-option Revision: 00 Title: NETCONF DHCPv6 Option Creation date: 2013-10-20 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-fa-netconf-dhcpv6-option-00.txt Status: http://datatracker.ietf.org/doc/draft-fa-netconf-dhcpv6-option Htmlized: http://tools.ietf.org/html/draft-fa-netconf-dhcpv6-option-00 Abstract: This document defines DHCPv6 options for bootstrapping the NETCONF protocol on devices. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From internet-drafts@ietf.org Mon Oct 21 12:25:02 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4493111E8242; Mon, 21 Oct 2013 12:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTNcWvVMdq78; Mon, 21 Oct 2013 12:25:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3DC11E8247; Mon, 21 Oct 2013 12:24:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021192458.32495.42732.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 12:24:58 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:25:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group of th= e IETF. Title : Using the NETCONF Protocol over Transport Layer Security= (TLS) Author(s) : Mohamad Badra Alan Luchuk Juergen Schoenwaelder Filename : draft-ietf-netconf-rfc5539bis-04.txt Pages : 26 Date : 2013-10-21 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure the exchange of NETCONF messages. This document obsoletes RFC 5539. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From robert.varga@pantheon.sk Wed Oct 23 02:16:06 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2624C11E8341 for ; Wed, 23 Oct 2013 02:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD6SpngZFnOR for ; Wed, 23 Oct 2013 02:16:01 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0C01211E8335 for ; Wed, 23 Oct 2013 02:15:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 1A8282145A for ; Wed, 23 Oct 2013 11:15:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=pass (1024-bit key) header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ccA82pa48M5 for ; Wed, 23 Oct 2013 11:15:51 +0200 (CEST) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Wed, 23 Oct 2013 11:15:51 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 15546132DD9 for ; Wed, 23 Oct 2013 11:15:51 +0200 (CEST) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fxkE-YRpYYwg for ; Wed, 23 Oct 2013 11:15:50 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 4EE98133189 for ; Wed, 23 Oct 2013 11:15:50 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local 4EE98133189 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1382519750; bh=EEMJFC8VHU2fC9895XBhvZFqBCnVoit5hqXeygUXnQU=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=EhkldpL/RAWhJJehfl5yWrtPLm1mt4gjb5Rooh6DB7qdCy+h7b4ZDcgEklk59ssI+ vA55XyAW7wh1gpnmwFRGpRSkyf81rFlj6QnvKgPTchgWJoDsaX+Dz6huTdJjc+yTXq nxqlh1r/KliJThdoRWAEDrXNtcaiiK9Oz5C4s5e0= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sMPYkXuWk45d for ; Wed, 23 Oct 2013 11:15:50 +0200 (CEST) Received: from [172.16.4.157] (unknown [172.16.4.157]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id 1FE28132DD9 for ; Wed, 23 Oct 2013 11:15:50 +0200 (CEST) Message-ID: <526793C3.1090208@pantheon.sk> Date: Wed, 23 Oct 2013 11:15:47 +0200 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130911 Thunderbird/17.0.9 MIME-Version: 1.0 To: netconf@ietf.org References: <20131021202210.32574.9993.idtracker@ietfa.amsl.com> In-Reply-To: <20131021202210.32574.9993.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131021202210.32574.9993.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080503000701000907000709" Subject: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:16:06 -0000 This is a multi-part message in MIME format. --------------080503000701000907000709 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, this is just a minor refresh of the draft, with a YANG model of the RPCs and fix of a previously-omitted argument. Comments are welcome. Thanks, Robert -------- Original Message -------- Subject: New Version Notification for draft-varga-netconf-exi-capability-01.txt Date: Mon, 21 Oct 2013 13:22:10 -0700 From: internet-drafts@ietf.org To: Robert Varga A new version of I-D, draft-varga-netconf-exi-capability-01.txt has been successfully submitted by Robert Varga and posted to the IETF repository. Filename: draft-varga-netconf-exi-capability Revision: 01 Title: Efficient XML Interchange Capability for NETCONF Creation date: 2013-10-21 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-varga-netconf-exi-capability-01.txt Status: http://datatracker.ietf.org/doc/draft-varga-netconf-exi-capability Htmlized: http://tools.ietf.org/html/draft-varga-netconf-exi-capability-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-varga-netconf-exi-capability-01 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices via exchange of XML messages in textual representation. Efficient XML Interchange (EXI) is a W3C-recommended binary representation of XML Information Set, which is more efficient from both CPU and bandwidth utilization perspective. This document defines a capability-based extension to the NETCONF protocol that allows peers to agree to exchange protocol messages using EXI encoding. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------080503000701000907000709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello,

this is just a minor refresh of the draft, with a YANG model of the RPCs and fix of a previously-omitted argument.

Comments are welcome.

Thanks,
Robert


-------- Original Message --------
Subject: New Version Notification for draft-varga-netconf-exi-capability-01.txt
Date: Mon, 21 Oct 2013 13:22:10 -0700
From: internet-drafts@ietf.org
To: Robert Varga <robert.varga@pantheon.sk> 


A new version of I-D, draft-varga-netconf-exi-capability-01.txt
has been successfully submitted by Robert Varga and posted to the
IETF repository.

Filename:	 draft-varga-netconf-exi-capability
Revision:	 01
Title:		 Efficient XML Interchange Capability for NETCONF
Creation date:	 2013-10-21
Group:		 Individual Submission
Number of pages: 10
URL:             http://www.ietf.org/internet-drafts/draft-varga-netconf-exi-capability-01.txt
Status:          http://datatracker.ietf.org/doc/draft-varga-netconf-exi-capability
Htmlized:        http://tools.ietf.org/html/draft-varga-netconf-exi-capability-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-varga-netconf-exi-capability-01

Abstract:
   The Network Configuration Protocol (NETCONF) provides mechanisms to
   install, manipulate, and delete the configuration of network devices
   via exchange of XML messages in textual representation.  Efficient
   XML Interchange (EXI) is a W3C-recommended binary representation of
   XML Information Set, which is more efficient from both CPU and
   bandwidth utilization perspective.  This document defines a
   capability-based extension to the NETCONF protocol that allows peers
   to agree to exchange protocol messages using EXI encoding.


                                                                                  


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

The IETF Secretariat


--------------080503000701000907000709-- From kwatsen@juniper.net Fri Oct 25 15:35:09 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF6311E819C for ; Fri, 25 Oct 2013 15:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkEX6cHWBOpb for ; Fri, 25 Oct 2013 15:35:02 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5D05811E81B8 for ; Fri, 25 Oct 2013 15:35:02 -0700 (PDT) Received: from mail7-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Fri, 25 Oct 2013 22:35:01 +0000 Received: from mail7-va3 (localhost [127.0.0.1]) by mail7-va3-R.bigfish.com (Postfix) with ESMTP id 79BD02E011A; Fri, 25 Oct 2013 22:35:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzc85fh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h177df4h17326ah8275bh18c673h1de097h186068hz2fh2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h1155h) Received-SPF: pass (mail7-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(164054003)(199002)(189002)(51856001)(80976001)(76176001)(36756003)(85306002)(54356001)(76796001)(76786001)(53806001)(50986001)(47976001)(83072001)(47736001)(49866001)(83322001)(19580395003)(46102001)(77096001)(4396001)(56816003)(80022001)(65816001)(66066001)(81816001)(16236675002)(15395725003)(74876001)(54316002)(79102001)(56776001)(76482001)(77982001)(59766001)(558084003)(74706001)(74662001)(47446002)(74502001)(74366001)(63696002)(83506001)(31966008)(69226001)(81542001)(81686001)(81342001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB322; H:BY2PR05MB125.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail7-va3 (localhost.localdomain [127.0.0.1]) by mail7-va3 (MessageSwitch) id 1382740500207939_28317; Fri, 25 Oct 2013 22:35:00 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.230]) by mail7-va3.bigfish.com (Postfix) with ESMTP id 2D32E220049; Fri, 25 Oct 2013 22:35:00 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 25 Oct 2013 22:35:00 +0000 Received: from BLUPR05MB322.namprd05.prod.outlook.com (10.141.24.25) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 25 Oct 2013 22:34:59 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BLUPR05MB322.namprd05.prod.outlook.com (10.141.24.25) with Microsoft SMTP Server (TLS) id 15.0.810.5; Fri, 25 Oct 2013 22:34:58 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.128]) by BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.137]) with mapi id 15.00.0785.001; Fri, 25 Oct 2013 22:34:56 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: draft-kwatsen-netconf-zerotouch Thread-Index: AQHO0dJuD3W8i4+gjkmkr6qjDN4wpQ== Date: Fri, 25 Oct 2013 22:34:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.232.2] x-forefront-prvs: 0010D93EFE Content-Type: multipart/alternative; boundary="_000_CE906A50498EAkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Stephen Hanna Subject: [Netconf] draft-kwatsen-netconf-zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 22:35:09 -0000 --_000_CE906A50498EAkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This draft slipped the submission deadline, so I posted it to another site. http://softnami.com/draft-kwatsen-netconf-zerotouch-00.txt http://softnami.com/draft-kwatsen-netconf-zerotouch-00.html Hopefully we can still discuss it on the list before the meeting in Vancouv= er. Thanks, Kent --_000_CE906A50498EAkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <5E9049598C78E04C834CB0535987BB36@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

All,

This draft slipped the submission deadline, so I posted it to another site.=

http://softnami.com/= draft-kwatsen-netconf-zerotouch-00.txt
http://softnami.com/= draft-kwatsen-netconf-zerotouch-00.html

Hope= fully we can still discuss it on the list before the meeting in Vancouver.<= /div>

Than= ks,
Kent=


--_000_CE906A50498EAkwatsenjunipernet_-- From kwatsen@juniper.net Fri Oct 25 15:41:37 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545C011E810A for ; Fri, 25 Oct 2013 15:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXq2NacBWjTU for ; Fri, 25 Oct 2013 15:41:31 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8572921F9D53 for ; Fri, 25 Oct 2013 15:41:31 -0700 (PDT) Received: from mail184-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE016.bigfish.com (10.43.70.66) with Microsoft SMTP Server id 14.1.225.22; Fri, 25 Oct 2013 22:41:31 +0000 Received: from mail184-ch1 (localhost [127.0.0.1]) by mail184-ch1-R.bigfish.com (Postfix) with ESMTP id 17B423201DE for ; Fri, 25 Oct 2013 22:41:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzc85dh4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h177df4h17326ah8275bh18c673h1de097h186068hz2fh2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h1155h) Received-SPF: pass (mail184-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(164054003)(69226001)(56816003)(19580395003)(15975445006)(77096001)(76482001)(59766001)(77982001)(79102001)(15395725003)(83072001)(66066001)(85306002)(4396001)(36756003)(83322001)(56776001)(76796001)(76786001)(54316002)(76176001)(16236675002)(50986001)(47976001)(49866001)(47736001)(81542001)(46102001)(80022001)(65816001)(51856001)(83506001)(63696002)(15202345003)(80976001)(81816001)(81686001)(53806001)(74366001)(54356001)(74876001)(74662001)(81342001)(31966008)(74502001)(47446002)(74706001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB125; H:BY2PR05MB125.namprd05.prod.outlook.com; CLIP:66.129.232.2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail184-ch1 (localhost.localdomain [127.0.0.1]) by mail184-ch1 (MessageSwitch) id 1382740888859192_19317; Fri, 25 Oct 2013 22:41:28 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail184-ch1.bigfish.com (Postfix) with ESMTP id CD71714005D for ; Fri, 25 Oct 2013 22:41:28 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 25 Oct 2013 22:41:28 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 25 Oct 2013 22:41:19 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 25 Oct 2013 22:41:17 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.128]) by BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.137]) with mapi id 15.00.0785.001; Fri, 25 Oct 2013 22:41:17 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: draft-ietf-netconf-reverse-ssh-02 Thread-Index: AQHO0dNQE2uhK7WHNEebO+/qjffz1g== Date: Fri, 25 Oct 2013 22:41:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.232.2] x-forefront-prvs: 0010D93EFE Content-Type: multipart/alternative; boundary="_000_CE906BCC49907kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Netconf] draft-ietf-netconf-reverse-ssh-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 22:41:37 -0000 --_000_CE906BCC49907kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I missed the submission deadline for the update to this draft, so I posted = it to another site: http://softnami.com/draft-ietf-netconf-reverse-ssh-02.txt http://softnami.com/draft-ietf-netconf-reverse-ssh-02.html Hopefully it can get posted to the IETF site as a special exception - we'll= see Changes include: - Added Applicability Statement - Removed references to ZeroConf / ZeroTouch - Clarified the protocol section - Added a section for identification and verification Thanks, Kent --_000_CE906BCC49907kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

I missed the submission deadline for the update to this draft, so I posted = it to another site:


Hopefully it can get posted to the IETF site as a special exception –= we'll see

Changes include:

  &n= bsp; -  Added Applicability Statement
  &n= bsp; -  Removed references to ZeroConf / ZeroTouch
  &n= bsp; -  Clarified the protocol section
  &n= bsp; -  Added a section for identification and verification

Thanks,
Kent

--_000_CE906BCC49907kwatsenjunipernet_-- From Internet-Drafts@ietf.org Tue Oct 29 13:14:42 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F28911E8136; Tue, 29 Oct 2013 13:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeJrBUCeqRb6; Tue, 29 Oct 2013 13:14:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7377611E8153; Tue, 29 Oct 2013 13:14:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131029201431.21377.43537.idtracker@ietfa.amsl.com> Date: Tue, 29 Oct 2013 13:14:31 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:14:42 -0000 --NextPart 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 : Reverse Secure Shell (Reverse SSH) Author(s) : K. Watsen Filename : draft-ietf-netconf-reverse-ssh Pages : 15 Date : Oct. 29, 2013 This memo 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". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-reverse-ssh-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-reverse-ssh"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-10-29131431.I-D@ietf.org> --NextPart-- From touch@isi.edu Tue Oct 29 13:29:15 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BE621E80AB for ; Tue, 29 Oct 2013 13:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.647 X-Spam-Level: X-Spam-Status: No, score=-105.647 tagged_above=-999 required=5 tests=[AWL=0.952, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg4iB3U8Gual for ; Tue, 29 Oct 2013 13:29:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id B30FF21E8087 for ; Tue, 29 Oct 2013 13:29:10 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9TKSj69028367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Oct 2013 13:28:45 -0700 (PDT) Message-ID: <52701ACC.7000600@isi.edu> Date: Tue, 29 Oct 2013 13:30:04 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "netconf@ietf.org" , Kent Watsen References: <20131029201431.21377.43537.idtracker@ietfa.amsl.com> In-Reply-To: <20131029201431.21377.43537.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:29:15 -0000 Hi, Kent, et al.: As we discussed several years ago, why is this still requesting a new port vs. reusing #22?ssh At the very least, there needs to be a thorough discussion of that issue in this doc, and it appears to be missing. I considered this issue in 2009, and still feel that there is insufficient justification for a separate assignment for this service. Additionally, this doc uses 7022 as the configuration example; that is inappropriate, esp. because 7022 is currently assigned to another service. unassigned numbers should never be used as examples. Joe On 10/29/2013 1:14 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 : Reverse Secure Shell (Reverse SSH) > Author(s) : K. Watsen > Filename : draft-ietf-netconf-reverse-ssh > Pages : 15 > Date : Oct. 29, 2013 > > This memo 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". > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-reverse-ssh-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mehmet.ersue@nsn.com Tue Oct 29 15:04:24 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BF821E8087 for ; Tue, 29 Oct 2013 15:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.094 X-Spam-Level: X-Spam-Status: No, score=-106.094 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKuktzvsyrTj for ; Tue, 29 Oct 2013 15:04:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 239F521E809A for ; Tue, 29 Oct 2013 15:04:18 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r9TM4HN5005989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Oct 2013 23:04:17 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9TM4HFv026993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Oct 2013 23:04:17 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Oct 2013 23:04:17 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Tue, 29 Oct 2013 23:04:16 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: Updated agenda for IETF 88 NETCONF session Thread-Index: Ac7U8s5Xs7AAEcsnRYWHbJoCCgABGQ== Date: Tue, 29 Oct 2013 22:04:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.102] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81E22D5DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2255 X-purgate-ID: 151667::1383084257-00005753-7F80D1A2/0-0/0-0 Subject: [Netconf] Updated agenda for IETF 88 NETCONF session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 22:04:24 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81E22D5DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, please find on the IETF server the updated agenda for the NETCONF session i= n IETF #88. http://www.ietf.org/proceedings/88/agenda/agenda-88-netconf Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F81E22D5DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
please find on the IETF server the updated agenda for the NETCONF sess= ion in IETF #88.
&nbs= p;
&nbs= p;
Cheers,
Mehmet
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F81E22D5DEMUMBX005nsnintr_-- From bclaise@cisco.com Wed Oct 30 05:37:14 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CABB21E8098 for ; Wed, 30 Oct 2013 05:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzJH+7EFl5lc for ; Wed, 30 Oct 2013 05:37:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5983521E808D for ; Wed, 30 Oct 2013 05:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9701; q=dns/txt; s=iport; t=1383136610; x=1384346210; h=message-id:date:from:mime-version:to:subject; bh=sshX0XiMcjObJJJHU9gbud6tJxmMwOc12FBSo8DMCnQ=; b=aQqw0YjSDyj1PhFTtmaHI5yEnd2QUw60j09oPyGVtODiFIB5yWl0KmHA 8NTia6QfEToSXc0hirDvwbZyMrPdQy6edPEvTu3n8eDzBnUfYiMFt8OhY bj8xTtiAtHpgDQjP/3MoMHIM/8d8Fuv1GgCcBIGuLVLDXuYTNJa3z9VRJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucFAA/9cFKQ/khL/2dsb2JhbABQCYMHOIlErhCJcxZ0gxcNPRYYAwIBAgFLDQgBAYgDDZkVoWCODYV1A5Qqg2CBL4UOi0yDJzs X-IronPort-AV: E=Sophos;i="4.93,601,1378857600"; d="scan'208,217";a="161196325" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2013 12:36:35 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9UCaV7P017678 for ; Wed, 30 Oct 2013 12:36:33 GMT Message-ID: <5270FD4F.8070001@cisco.com> Date: Wed, 30 Oct 2013 13:36:31 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NETCONF Content-Type: multipart/alternative; boundary="------------090202090409060209030908" Subject: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 12:37:14 -0000 This is a multi-part message in MIME format. --------------090202090409060209030908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I browsed through the draft. Here is some feedback. Disclaimer: I'm not a security expert, so no feedback on the security aspects. - 2.3 . Connection Closure A NETCONF server will process NETCONF messages from the NETCONF client in the order in which they are received. A NETCONF session is closed using the operation. When the NETCONF server processes a operation, the NETCONF server SHALL respond and close the TLS session as described in [RFC5246 ]Section 7.2.1 . The NETCONF server MUST NOT process any NETCONF messages received after the operation. Can the NETCONF server close the call-home function (I mean gracefully, not with a kill-session)? - From +--rw netconf +--rw tls +--rw enabled? boolean +--rw cert-maps {tls-map-certificates}? | +--rw cert-to-name* [id] | +--rw id uint32 | +--rw fingerprint x509c2n:tls-fingerprint | +--rw map-type identityref | +--rw name string +--rw psk-maps {tls-map-pre-shared-keys}? | +--rw psk-map* [psk-identity] | +--rw psk-identity string | +--rw user-name nacm:user-name-type | +--rw not-valid-before? yang:date-and-time | +--rw not-valid-after? yang:date-and-time | +--rw key yang:hex-string +--rw call-home {tls-call-home}? +--rw client* [address port] +--rw address inet:host +--rw port inet:port-number +--rw (connection-type)? | +--:(persistent) | | +--rw persistent-connection? empty | +--:(periodic) | +--rw periodic | +--rw interval? uint16 | +--rw linger? uint16 +--rw reconnect-strategy +--rw retry-interval? uint16 +--rw max-attempts? uint16 If the enabled boolean is yes, then both TLS AND call-home are enabled? Don't we need a boolean for call-home? At first glance, it seems like a flag to be set during the pre-staging phase. I guess my question is more: how will the call home feature will be used? Maybe it's covered by: http://datatracker.ietf.org/doc/draft-kwatsen-netconf-zerotouch/ ? I haven't read it yet. - Update the subject to include call home. - Wrong draft number below A.1 .draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . .24 A.2 .draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . .25 A.3 .draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . .25 A.4 .draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . .26 - you mentioned "middle box". You might need to refer to RFC 3234 Regards, Benoit (as a contributor) --------------090202090409060209030908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I browsed through the draft.
Here is some feedback.
Disclaimer: I'm not a security expert, so no feedback on the security aspects.

- 
2.3.  Connection Closure


   A NETCONF server will process NETCONF messages from the NETCONF
   client in the order in which they are received.  A NETCONF session is
   closed using the <close-session> operation.  When the NETCONF server
   processes a <close-session> operation, the NETCONF server SHALL
   respond and close the TLS session as described in [RFC5246] Section
   7.2.1.  The NETCONF server MUST NOT process any NETCONF messages
   received after the <close-session> operation.
Can the NETCONF server close the call-home function (I mean gracefully, not with a kill-session)?

- 
From
      +--rw netconf
         +--rw tls
            +--rw enabled?     boolean
            +--rw cert-maps {tls-map-certificates}?
            |  +--rw cert-to-name* [id]
            |     +--rw id             uint32
            |     +--rw fingerprint    x509c2n:tls-fingerprint
            |     +--rw map-type       identityref
            |     +--rw name           string
            +--rw psk-maps {tls-map-pre-shared-keys}?
            |  +--rw psk-map* [psk-identity]
            |     +--rw psk-identity        string
            |     +--rw user-name           nacm:user-name-type
            |     +--rw not-valid-before?   yang:date-and-time
            |     +--rw not-valid-after?    yang:date-and-time
            |     +--rw key                 yang:hex-string
            +--rw call-home {tls-call-home}?
               +--rw client* [address port]
                  +--rw address                  inet:host
                  +--rw port                     inet:port-number
                  +--rw (connection-type)?
                  |  +--:(persistent)
                  |  |  +--rw persistent-connection?   empty
                  |  +--:(periodic)
                  |     +--rw periodic
                  |        +--rw interval?   uint16
                  |        +--rw linger?     uint16
                  +--rw reconnect-strategy
                     +--rw retry-interval?   uint16
                     +--rw max-attempts?     uint16

If the enabled boolean is yes, then both TLS AND call-home are enabled?
Don't we need a boolean for call-home?
At first glance, it seems like a flag to be set during the pre-staging phase.
I guess my question is more: how will the call home feature will be used?
Maybe it's covered by: http://datatracker.ietf.org/doc/draft-kwatsen-netconf-zerotouch/ ?
I haven't read it yet.

- Update the subject to include call home.

- Wrong draft number below
     A.1.  draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . . 24
     A.2.  draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . . 25
     A.3.  draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . . 25
     A.4.  draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . . 26
- you mentioned "middle box". You might need to refer to RFC 3234

Regards, Benoit (as a contributor)
--------------090202090409060209030908-- From j.schoenwaelder@jacobs-university.de Wed Oct 30 05:56:08 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB2511E8196 for ; Wed, 30 Oct 2013 05:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.223 X-Spam-Level: X-Spam-Status: No, score=-103.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyeteieyDrdv for ; Wed, 30 Oct 2013 05:56:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CB70411E8171 for ; Wed, 30 Oct 2013 05:55:42 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6EAA200BF; Wed, 30 Oct 2013 13:55:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CuYBzUIvxb9L; Wed, 30 Oct 2013 13:55:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECCDF200B9; Wed, 30 Oct 2013 13:55:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6015A2918FD2; Wed, 30 Oct 2013 13:55:32 +0100 (CET) Date: Wed, 30 Oct 2013 13:55:32 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20131030125532.GA55395@elstar.local> Mail-Followup-To: Benoit Claise , NETCONF References: <5270FD4F.8070001@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5270FD4F.8070001@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETCONF Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 12:56:08 -0000 On Wed, Oct 30, 2013 at 01:36:31PM +0100, Benoit Claise wrote: > > Can the NETCONF server close the call-home function (I mean > gracefully, not with a kill-session)? > What does "NETCONF server close the call-home function" mean to you? I think I do not understand the question. [...] > If the enabled boolean is yes, then both TLS AND call-home are enabled? Yes. If there are no clients configured, no call-home will take place. > Don't we need a boolean for call-home? Maybe. To be discussed. I personally prefer to have this config consistent between the TLS and SSH transport (ideally a single grouping to be used by both). What I have is inspired by the SSH document with some fixes applied. Would be nice to get it sorted out in Vancouver how call home is configured for a NETCONF transport. > At first glance, it seems like a flag to be set during the > pre-staging phase. I guess my question is more: how will the call > home feature will be used? You either ship boxes with pre-configured call-home addresses or the call-home address is provided via some bootstrapping mechanism (e.g. DHCP). (We once worked on an I-D discussing such bootstrapping issues but it was shutdown in OPSAWG.) > - Update the subject to include call home. Not sure what to update. > - Wrong draft number below Fixed > - you mentioned "middle box". You might need to refer to RFC 3234 OK /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Wed Oct 30 06:25:32 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DBB11E813D for ; Wed, 30 Oct 2013 06:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.517 X-Spam-Level: X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPurwY9lsspA for ; Wed, 30 Oct 2013 06:25:26 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BEA6111E8226 for ; Wed, 30 Oct 2013 06:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2558; q=dns/txt; s=iport; t=1383139482; x=1384349082; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=lyf/l2n0idCN8XfoLPoq9PCzruWylIMskQwUhu7WnuM=; b=hFx9e+rDFKl8QaB5AC2Nwq+DBuXU0aQ2Dj+PAP6x6Plv/Nao/+RiVHid W9sQP8Rfu1/PqW/haVH5UbsVVB1iYrXm3TdRFY0SlIsU4SUQeWVsjb3lV SUiy7YH5G5oUuRa09G/rMsMXN1dAE1q4jMzLaMcbNMJh5KU9uZvd7xj+A 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAAMIcVKQ/khM/2dsb2JhbABZgwfAWYElFnSCJQEBAQQyAQU6FwsYCSUPAkYGDQgBAYgDunWPVoQsA5gKhj2LTIMnOw X-IronPort-AV: E=Sophos;i="4.93,601,1378857600"; d="scan'208";a="18650703" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 30 Oct 2013 13:24:41 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9UDObOS028152 for ; Wed, 30 Oct 2013 13:24:38 GMT Message-ID: <52710895.30301@cisco.com> Date: Wed, 30 Oct 2013 14:24:37 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NETCONF References: <5270FD4F.8070001@cisco.com> <20131030125532.GA55395@elstar.local> In-Reply-To: <20131030125532.GA55395@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 13:25:32 -0000 Jürgen, > On Wed, Oct 30, 2013 at 01:36:31PM +0100, Benoit Claise wrote: >> Can the NETCONF server close the call-home function (I mean >> gracefully, not with a kill-session)? >> > What does "NETCONF server close the call-home function" mean to you? > I think I do not understand the question. Currently reading draft-kwatsen-netconf-zerotouch-00.txt, so reusing some text from that draft: Call home function is a technique for how to establish a secure network management relationship between a newly delivered network device, configured with just its factory default settings, and the new owner's Network Management System (NMS). When the newly delivered network device is fully operational, then the call home function should be closed, right? Who initiate this closure: only the NETCONF client, or could the NETCONF server also initiate it. Your text seems to indicate only the NETCONF client. Or maybe you expect this call-home NETCONF session to remain up all the time? I'm trying to look for answers in draft-kwatsen-netconf-zerotouch-00.txt, but I can only find "its ZeroTouch logic would be disabled the next time it boots." > > [...] > >> If the enabled boolean is yes, then both TLS AND call-home are enabled? > Yes. If there are no clients configured, no call-home will take place. > >> Don't we need a boolean for call-home? > Maybe. To be discussed. I personally prefer to have this config > consistent between the TLS and SSH transport (ideally a single > grouping to be used by both). Make sense. > What I have is inspired by the SSH > document with some fixes applied. Would be nice to get it sorted out > in Vancouver how call home is configured for a NETCONF transport. > >> At first glance, it seems like a flag to be set during the >> pre-staging phase. I guess my question is more: how will the call >> home feature will be used? > You either ship boxes with pre-configured call-home addresses or the > call-home address is provided via some bootstrapping mechanism > (e.g. DHCP). (We once worked on an I-D discussing such bootstrapping > issues but it was shutdown in OPSAWG.) > >> - Update the subject to include call home. > Not sure what to update. This draft doesn't only obsolete RFC 5539, it adds an important call home function Basically add to the abstract a sentence such as It also provides an optional mechanism to establish the underlying TCP connection from the NETCONF server to the NETCONF client (call home). Regards, Benoit From j.schoenwaelder@jacobs-university.de Wed Oct 30 07:45:52 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A4111E8233 for ; Wed, 30 Oct 2013 07:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0wORaj3vxRW for ; Wed, 30 Oct 2013 07:45:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5981C11E8232 for ; Wed, 30 Oct 2013 07:45:32 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C424C200B2; Wed, 30 Oct 2013 15:45:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kaKG0l0IGysd; Wed, 30 Oct 2013 15:45:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47341200B3; Wed, 30 Oct 2013 15:45:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D7CCB291933F; Wed, 30 Oct 2013 15:45:25 +0100 (CET) Date: Wed, 30 Oct 2013 15:45:25 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20131030144525.GB55617@elstar.local> Mail-Followup-To: Benoit Claise , NETCONF References: <5270FD4F.8070001@cisco.com> <20131030125532.GA55395@elstar.local> <52710895.30301@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52710895.30301@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETCONF Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 30 Oct 2013 14:45:52 -0000 On Wed, Oct 30, 2013 at 02:24:37PM +0100, Benoit Claise wrote: > When the newly delivered network device is fully operational, then > the call home function should be closed, right? Who initiate this > closure: only the NETCONF client, or could the NETCONF server also > initiate it. Your text seems to indicate only the NETCONF client. > Or maybe you expect this call-home NETCONF session to remain up all > the time? I think this depends on the deployment. If you NC server is behind a middlebox, you likely want to keep it calling home since otherwise there is no way to talk to it. As things are right now, once you remove the call home config entries, call home attempts will stop. Hence, the NC client has always full control over this. Should the server itself modify the configuration? I don't know. > >>- Update the subject to include call home. > >Not sure what to update. > This draft doesn't only obsolete RFC 5539, it adds an important call > home function > Basically add to the abstract a sentence such as > > It also provides > an optional mechanism to establish the underlying TCP connection from > the NETCONF server to the NETCONF client (call home). OK. I updated the abstract. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Wed Oct 30 11:15:29 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957F721E8135 for ; Wed, 30 Oct 2013 11:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khg2l6l7bbwG for ; Wed, 30 Oct 2013 11:15:22 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id D6E8111E82C4 for ; Wed, 30 Oct 2013 11:15:21 -0700 (PDT) Received: from mail64-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Wed, 30 Oct 2013 18:15:21 +0000 Received: from mail64-ch1 (localhost [127.0.0.1]) by mail64-ch1-R.bigfish.com (Postfix) with ESMTP id 248052E011A; Wed, 30 Oct 2013 18:15:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail64-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(24454002)(164054003)(479174003)(377454003)(74706001)(56816003)(76796001)(74876001)(77096001)(76786001)(80976001)(19580405001)(19580395003)(83322001)(53806001)(54356001)(85306002)(81816001)(81686001)(74366001)(36756003)(83072001)(47446002)(74502001)(74662001)(31966008)(56776001)(54316002)(76482001)(79102001)(81342001)(80022001)(77982001)(59766001)(63696002)(81542001)(76176001)(65816001)(66066001)(69226001)(46102001)(4396001)(47736001)(50986001)(51856001)(47976001)(83506001)(49866001)(87266001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail64-ch1 (localhost.localdomain [127.0.0.1]) by mail64-ch1 (MessageSwitch) id 1383156918980139_24016; Wed, 30 Oct 2013 18:15:18 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail64-ch1.bigfish.com (Postfix) with ESMTP id E07F34004C; Wed, 30 Oct 2013 18:15:18 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 30 Oct 2013 18:15:15 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 30 Oct 2013 18:15:14 +0000 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.810.5; Wed, 30 Oct 2013 18:15:12 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) with mapi id 15.00.0810.005; Wed, 30 Oct 2013 18:15:12 +0000 From: Kent Watsen To: Juergen Schoenwaelder , Benoit Claise Thread-Topic: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments Thread-Index: AQHO1Wzga6wvKSH+8kyfK43a9URzF5oNM8gAgAAIIICAABaUgP//94kA Date: Wed, 30 Oct 2013 18:15:11 +0000 Message-ID: In-Reply-To: <20131030144525.GB55617@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.241.13] x-forefront-prvs: 00159D1518 Content-Type: text/plain; charset="us-ascii" Content-ID: <902E447C0A2C914C9EFADFD7B9D440AF@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: NETCONF Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:15:29 -0000 On 10/30/13 10:45 AM, "Juergen Schoenwaelder" wrote: >As things are right now, once you remove the call home config entries, >call home attempts will stop. Hence, the NC client has always full >control over this. Should the server itself modify the configuration? >I don't know. Right, this is the way to think about it - so long as the device is configured to call home (using either SSH or TLS), it should continue to do so ad infinitum. ZeroTouch is related but somewhat orthogonal. A device supporting ZeroTouch *knows* when it has "factory default" config and, only when that is the case, on boot, will it try to dynamically lookup an NMS to connect to. Ultimately, ZeroTouch ends with the device persisting the same "call home" configuration, which then causes the above-mentioned call home logic to kick in. It's up to the NMS what it wants to do - it can either leave the device's call-home config intact, letting the device call home again and again, or it can remove that configuration because it plans to connect to the device from that point forward. Makes sense? Thanks, Kent From mehmet.ersue@nsn.com Wed Oct 30 12:21:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E436C21E8091 for ; Wed, 30 Oct 2013 12:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.127 X-Spam-Level: X-Spam-Status: No, score=-106.127 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYQOCaLJEJqA for ; Wed, 30 Oct 2013 12:21:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF8021E815A for ; Wed, 30 Oct 2013 12:21:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r9UJLGmF009635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Oct 2013 20:21:16 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r9UJLFSt009340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Oct 2013 20:21:16 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 30 Oct 2013 20:21:15 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Wed, 30 Oct 2013 20:21:15 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: Opendaylight Requirements on NETCONF/YANG Thread-Index: Ac7VpTGOa4EswMz0RdmOZSv2ZqBcow== Date: Wed, 30 Oct 2013 19:21:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.103] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81E2CADDEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2673 X-purgate-ID: 151667::1383160877-00005753-5D57E842/0-0/0-0 Cc: "david.kessens@gmail.com" Subject: [Netconf] Opendaylight Requirements on NETCONF/YANG X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 19:21:36 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81E2CADDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG Members, the NETCONF co-chairs and our AD assume that organizations like OpenDayligh= t will bring in new requirements into NETCONF and NETMOD WGs. Can any WG member give in IETF #88 NETCONF session, an overview on what the= OpenDaylight project is planning concerning the usage of NETCONF/YANG and = as far as they are known what the requirements on NETCONF/YANG are? Please send the people on CC a private note. Thanks. Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F81E2CADDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG Members,
 
the NETCONF co-chairs and our AD assume that organizations like OpenDa= ylight will bring in new requirements into NETCONF and NETMOD WGs.
&nbs= p;
Can any WG member give in IETF #88 NETCONF session, an overview on wha= t the OpenDaylight project is planning concerning the usage of NETCONF/YANG= and as far as they are known what the requirements on NETCONF/YANG are?
&nbs= p;
Please send the people on CC a private note. Thanks.
&nbs= p;
Cheers,
Mehmet
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F81E2CADDEMUMBX005nsnintr_-- From kwatsen@juniper.net Wed Oct 30 12:48:48 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772E811E81B9 for ; Wed, 30 Oct 2013 12:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXNoJNIWwYUH for ; Wed, 30 Oct 2013 12:48:38 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6247411E81D7 for ; Wed, 30 Oct 2013 12:48:32 -0700 (PDT) Received: from mail18-db9-R.bigfish.com (10.174.16.252) by DB9EHSOBE032.bigfish.com (10.174.14.95) with Microsoft SMTP Server id 14.1.225.22; Wed, 30 Oct 2013 19:48:31 +0000 Received: from mail18-db9 (localhost [127.0.0.1]) by mail18-db9-R.bigfish.com (Postfix) with ESMTP id 7FF5520135; Wed, 30 Oct 2013 19:48:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zzbb2dI98dI9371I146fI4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail18-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(24454002)(164054003)(189002)(199002)(52314003)(74662001)(74366001)(31966008)(47446002)(74502001)(87266001)(83072001)(81542001)(79102001)(77982001)(83322001)(76482001)(54316002)(56776001)(65816001)(80022001)(66066001)(63696002)(59766001)(76796001)(76786001)(77096001)(56816003)(76176001)(69226001)(85306002)(83506001)(36756003)(81342001)(81686001)(80976001)(81816001)(19580405001)(19580395003)(74706001)(54356001)(47736001)(47976001)(51856001)(46102001)(4396001)(53806001)(50986001)(49866001)(74876001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.18; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail18-db9 (localhost.localdomain [127.0.0.1]) by mail18-db9 (MessageSwitch) id 1383162509740311_29061; Wed, 30 Oct 2013 19:48:29 +0000 (UTC) Received: from DB9EHSMHS008.bigfish.com (unknown [10.174.16.241]) by mail18-db9.bigfish.com (Postfix) with ESMTP id A728E180040; Wed, 30 Oct 2013 19:48:29 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS008.bigfish.com (10.174.14.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 30 Oct 2013 19:48:29 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Wed, 30 Oct 2013 19:48:28 +0000 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.810.5; Wed, 30 Oct 2013 19:48:26 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) with mapi id 15.00.0810.005; Wed, 30 Oct 2013 19:48:26 +0000 From: Kent Watsen To: Joe Touch , "netconf@ietf.org" Thread-Topic: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt Thread-Index: AQHO1OPawXUSQhu+mUmffU8BzRNWW5oMIYQAgAFDogA= Date: Wed, 30 Oct 2013 19:48:26 +0000 Message-ID: In-Reply-To: <52701ACC.7000600@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [66.129.241.18] x-forefront-prvs: 00159D1518 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 19:48:48 -0000 On 10/29/13 4:30 PM, "Joe Touch" wrote: >As we discussed several years ago, why is this still requesting a new >port vs. reusing #22?ssh To reuse port 22 would require changing RFC 4253 (the SSH Transport protocol), to add some reversal flag into the SSH handshake. While technically possible, it would be inconsistent with the newly added Applicability Statement (added by folks from the Security Area) limiting the ability to reverse SSH to just NETCONF servers (i.e. it's not a universal solution). BTW, the rfc5539bis draft is also asking IANA for a new port-assignment for call-home using TLS and it also has a similar Applicability Statement recently added to it... >At the very least, there needs to be a thorough discussion of that issue >in this doc, and it appears to be missing. I considered this issue in >2009, and still feel that there is insufficient justification for a >separate assignment for this service. Add a section for why we want a port-assignment? - can that be something that's worked out on a mailing list (such as we're doing right now) and the draft just implements the agreed upon solution? >Additionally, this doc uses 7022 as the configuration example; that is >inappropriate, esp. because 7022 is currently assigned to another >service. unassigned numbers should never be used as examples. Sure, I'll remove the element from the example - it's defined in the YANG module to be optional field anyway, so not having one specified is still valid... Thanks, Kent From touch@isi.edu Wed Oct 30 15:52:40 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0170511E828D for ; Wed, 30 Oct 2013 15:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.642 X-Spam-Level: X-Spam-Status: No, score=-103.642 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI3Lps3qfVvh for ; Wed, 30 Oct 2013 15:52:34 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 31D6811E8176 for ; Wed, 30 Oct 2013 15:52:34 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9UMqD9S009227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Oct 2013 15:52:16 -0700 (PDT) Message-ID: <52718DF2.4050808@isi.edu> Date: Wed, 30 Oct 2013 15:53:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 22:52:40 -0000 Hi, Kent, On 10/30/2013 12:48 PM, Kent Watsen wrote: > > > On 10/29/13 4:30 PM, "Joe Touch" wrote: > >> As we discussed several years ago, why is this still requesting a new >> port vs. reusing #22?ssh > > To reuse port 22 would require changing RFC 4253 (the SSH Transport > protocol), to add some reversal flag into the SSH handshake. Of course, but that's effectively what you're doing except you're obscuring it by using a separate port. > While > technically possible, it would be inconsistent with the newly added > Applicability Statement (added by folks from the Security Area) limiting > the ability to reverse SSH to just NETCONF servers (i.e. it's not a > universal solution). Sure, then it would then use port 830 rather than 22, but that's still a good argument for using port 830 in that case. > BTW, the rfc5539bis draft is also asking IANA for a new port-assignment > for call-home using TLS and it also has a similar Applicability Statement > recently added to it... And for similar reasons I would suggest they use the existing NETCONF TLS port. >> At the very least, there needs to be a thorough discussion of that issue >> in this doc, and it appears to be missing. I considered this issue in >> 2009, and still feel that there is insufficient justification for a >> separate assignment for this service. > > Add a section for why we want a port-assignment? - can that be something > that's worked out on a mailing list (such as we're doing right now) and > the draft just implements the agreed upon solution? Not just why you want a port assignment; why this isn't an extension of the existing NETCCONF SSH service. >> Additionally, this doc uses 7022 as the configuration example; that is >> inappropriate, esp. because 7022 is currently assigned to another >> service. unassigned numbers should never be used as examples. > > Sure, I'll remove the element from the example - it's defined in > the YANG module to be optional field anyway, so not having one specified > is still valid... Thanks. It's always useful to avoid using examples until they're assigned. Joe From jclarke@cisco.com Wed Oct 30 22:30:10 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA7721E80B5 for ; Wed, 30 Oct 2013 22:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVdCda12iTHP for ; Wed, 30 Oct 2013 22:30:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 66F9B21E80C0 for ; Wed, 30 Oct 2013 22:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1998; q=dns/txt; s=iport; t=1383197399; x=1384406999; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=w9eWW5IlbATuk1evTfn60AUnFCx7Mrx4Ms3dCxtno4M=; b=lq9YsA3BxSqVXyEzDRKkt2wQ1TDb1BOqXgcnUQdDTxpRNHDUYBLemUH7 Ow3Y1vS1MPPt9djs5ZtpbweZd6KNcEhk0k0nl0unGqpgBkoEZWUuqDjZG fn9wiqiPvCxrCSdLSbIFNU7g73KyMtKei3v6nltW0nHvP1i28dVcTmzdu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAEXqcVKtJXHA/2dsb2JhbABWA4MHOL9xS4EsFnSCJQEBAQMBAQEBNTUBCgEOAgsOCgkWDwkDAgECAQkMMAYBDAEFAgEBh30GDbsVBI4CgTkQBxGEHAOYC4EvkFqDQiCBNQ X-IronPort-AV: E=Sophos;i="4.93,606,1378857600"; d="scan'208";a="278622627" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 31 Oct 2013 05:29:58 +0000 Received: from sjc-vpn7-417.cisco.com (sjc-vpn7-417.cisco.com [10.21.145.161]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9V5Tp9r025268; Thu, 31 Oct 2013 05:29:52 GMT Message-ID: <5271EACE.4060506@cisco.com> Date: Thu, 31 Oct 2013 01:29:50 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen Hanna Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 05:30:10 -0000 On 10/25/13, 6:34 PM, Kent Watsen wrote: > > All, > > This draft slipped the submission deadline, so I posted it to another site. > > http://softnami.com/draft-kwatsen-netconf-zerotouch-00.txt > http://softnami.com/draft-kwatsen-netconf-zerotouch-00.html > > Hopefully we can still discuss it on the list before the meeting in > Vancouver. Ken et al, why would the device need the FQDN of the vendor's DNS server? Couldn't it use the domain name with an NS query to get this? I'm trying to think of something that may be more scalable over time (i.e., if an older device is deployed that may have an old FQDN). What type of DNS queries will be used to get the NMS name and credentials? It would be helpful to see a query flow diagram in this draft. In the security considerations, you mention the potential threat in a malicious party learning the NMS FQDN, but I think the NMS authn parameters are more sensitive. Additionally, there may be hesitance of customers to store authn parameters within a vendor database. One potential workaround of this might be an alternate DNS address that the new device can query in the customer's network that would provide these bits of info. This would maintain the ability to support customer-unconfigurable DHCP servers while still allowing things like the NMS parameters to be maintained within the customer's network. Nit: your link to rfc5539bis points to 6187 instead. Joe > > Thanks, > Kent > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Wed Oct 30 23:52:11 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E73A21E80AC for ; Wed, 30 Oct 2013 23:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.225 X-Spam-Level: X-Spam-Status: No, score=-103.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTxfGgfOkqu9 for ; Wed, 30 Oct 2013 23:52:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C1BD521E80C0 for ; Wed, 30 Oct 2013 23:52:02 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CE2B200BD; Thu, 31 Oct 2013 07:52:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CbcbNz30Uo5C; Thu, 31 Oct 2013 07:52:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2E69200B8; Thu, 31 Oct 2013 07:52:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ADB4D291A700; Thu, 31 Oct 2013 07:51:54 +0100 (CET) Date: Thu, 31 Oct 2013 07:51:53 +0100 From: Juergen Schoenwaelder To: Joe Touch Message-ID: <20131031065153.GA57570@elstar.local> Mail-Followup-To: Joe Touch , Kent Watsen , "netconf@ietf.org" References: <52718DF2.4050808@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52718DF2.4050808@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 06:52:11 -0000 On Wed, Oct 30, 2013 at 03:53:38PM -0700, Joe Touch wrote: > > And for similar reasons I would suggest they use the existing > NETCONF TLS port. > Joe, if you have a box that runs a regular NETCONF server and a NETCONF client that is used for call-home by other remote NETCONF servers, how are they going to share the port number? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Oct 31 03:24:16 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CEA21F9DA3 for ; Thu, 31 Oct 2013 03:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVeFS1iGw430 for ; Thu, 31 Oct 2013 03:24:10 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id F341521F9FDE for ; Thu, 31 Oct 2013 03:24:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAOEuclLGmAcV/2dsb2JhbABZgmYhOFS/H0uBKBZ0giUBAQEBAwEBAQ8oNAsMBAIBCA0BAgEEAQEBChQJBycLFAkIAgQBDQUIGodlAQyeTp0eBI8eMQcGgxqBDgOeb4slgyaCKg X-IronPort-AV: E=Sophos;i="4.93,608,1378872000"; d="scan'208";a="29835712" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Oct 2013 06:24:04 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Oct 2013 06:18:51 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Thu, 31 Oct 2013 11:24:02 +0100 From: "Romascanu, Dan (Dan)" To: Kent Watsen , Juergen Schoenwaelder , Benoit Claise Thread-Topic: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments Thread-Index: AQHO1WzM61qtsGQa7k+Bj+Ql7btI3poNIwUAgAAIIICAAGplgP//5sqAgAEekZA= Date: Thu, 31 Oct 2013 10:24:02 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1291E915@AZ-FFEXMB04.global.avaya.com> References: <20131030144525.GB55617@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: NETCONF Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 10:24:16 -0000 Hi, It looks to me that there is a clear distinction between the 'ZeroTouch' an= d the 'call home' capabilities which is not articulated clearly in the I-Ds= text right now. I would not call them orthogonal, as it looks to me (pleas= e correct me if I am mistaken) that a device supporting the 'call home' fun= ctionality will support ZeroTouch as a subset.=20 Regards, Dan > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Kent Watsen > Sent: Wednesday, October 30, 2013 8:15 PM > To: Juergen Schoenwaelder; Benoit Claise > Cc: NETCONF > Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments >=20 >=20 >=20 > On 10/30/13 10:45 AM, "Juergen Schoenwaelder" > wrote: >=20 > >As things are right now, once you remove the call home config entries, > >call home attempts will stop. Hence, the NC client has always full > >control over this. Should the server itself modify the configuration? > >I don't know. >=20 >=20 > Right, this is the way to think about it - so long as the device is > configured to call home (using either SSH or TLS), it should continue to > do so ad infinitum. >=20 > ZeroTouch is related but somewhat orthogonal. A device supporting > ZeroTouch *knows* when it has "factory default" config and, only when > that is the case, on boot, will it try to dynamically lookup an NMS to > connect to. Ultimately, ZeroTouch ends with the device persisting the > same "call home" configuration, which then causes the above-mentioned > call home logic to kick in. >=20 > It's up to the NMS what it wants to do - it can either leave the > device's call-home config intact, letting the device call home again and > again, or it can remove that configuration because it plans to connect > to the device from that point forward. >=20 > Makes sense? >=20 > Thanks, > Kent >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bclaise@cisco.com Thu Oct 31 04:53:36 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F82521E80ED for ; Thu, 31 Oct 2013 04:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oim1TZ0u5xU1 for ; Thu, 31 Oct 2013 04:53:32 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5F02821E80F2 for ; Thu, 31 Oct 2013 04:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30881; q=dns/txt; s=iport; t=1383220404; x=1384430004; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=k3P5gvNj6myisdvdcp6KXyK80QTelis4880k+pgWB/I=; b=R8pmvITI38+D+Ehf20IScSycL5aKSQxmRjbPXu183Q6oq/P7Dql3wY0S hUuv55Iye+faYq8e1OaTQ6SYADOCH08t2ysRq4UbzGTkgEEo5Rcc9yia7 ptPJqV0yObgc/YWKu4WlxHXO87QQMB/nn4KR9QCGS47ZDkXnS+vvh+VGI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFALxDclKrRDoG/2dsb2JhbABZgkNEOIlEtnqBJBZ0giUBAQEELVwLGAkXAQ0PAkYGDQgBAYgCDrt3BI9WhC4DmAuGPYtMgyc7 X-IronPort-AV: E=Sophos;i="4.93,608,1378857600"; d="scan'208,217";a="93572091" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 31 Oct 2013 11:53:24 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9VBrKbj015150 for ; Thu, 31 Oct 2013 11:53:20 GMT Message-ID: <527244AF.20203@cisco.com> Date: Thu, 31 Oct 2013 12:53:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NETCONF References: <5270FD4F.8070001@cisco.com> <20131030125532.GA55395@elstar.local> <52710895.30301@cisco.com> <20131030144525.GB55617@elstar.local> In-Reply-To: <20131030144525.GB55617@elstar.local> Content-Type: multipart/alternative; boundary="------------000301040103060104070604" Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 11:53:36 -0000 This is a multi-part message in MIME format. --------------000301040103060104070604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 30/10/2013 07:45, Juergen Schoenwaelder wrote: > On Wed, Oct 30, 2013 at 02:24:37PM +0100, Benoit Claise wrote: > >> When the newly delivered network device is fully operational, then >> the call home function should be closed, right? Who initiate this >> closure: only the NETCONF client, or could the NETCONF server also >> initiate it. Your text seems to indicate only the NETCONF client. >> Or maybe you expect this call-home NETCONF session to remain up all >> the time? > > I think this depends on the deployment. If you NC server is behind a > middlebox, you likely want to keep it calling home since otherwise > there is no way to talk to it. > > As things are right now, once you remove the call home config entries, > call home attempts will stop. Hence, the NC client has always full > control over this. Should the server itself modify the configuration? > I don't know. So basically, my question is around: what is the call home function? 1. Zero touch provisioning, the managed device is operational, then reboots, and that's it: no more call home sessions. 2. Zero touch provisioning, then the call home session is up all the time (because it's behind a middlebox) 3. Zero touch provisioning, then, when there is something wrong, a call home session to the NMS (for example, a crash, looking for a bug), or regular scheduled call home sessions ("Hey NMS, I'm fine") I'm not sure I've seen a clear definition somewhere. And draft-kwatsen-netconf-zerotouch-00 is only 1 AFAICT. Regards, Benoit > >>>> - Update the subject to include call home. >>> Not sure what to update. >> This draft doesn't only obsolete RFC 5539, it adds an important call >> home function >> Basically add to the abstract a sentence such as >> >> It also provides >> an optional mechanism to establish the underlying TCP connection from >> the NETCONF server to the NETCONF client (call home). > OK. I updated the abstract. > > /js > --------------000301040103060104070604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 30/10/2013 07:45, Juergen Schoenwaelder wrote:
On Wed, Oct 30, 2013 at 02:24:37PM +0100, Benoit Claise wrote:


When the newly delivered network device is fully operational, then
the call home function should be closed, right? Who initiate this
closure: only the NETCONF client, or could the NETCONF server also
initiate it. Your text seems to indicate only the NETCONF client.


      

        
Or maybe you expect this call-home NETCONF session to remain up all
the time?


      

      
 
I think this depends on the deployment. If you NC server is behind a
middlebox, you likely want to keep it calling home since otherwise
there is no way to talk to it.

As things are right now, once you remove the call home config entries,
call home attempts will stop. Hence, the NC client has always full
control over this. Should the server itself modify the configuration?
I don't know.

    

    
    

    So basically, my question is around: what is the call home function?

    1.  Zero touch provisioning, the managed device is operational, then
    reboots, and that’s it: no more call home sessions.

    2.  Zero touch provisioning, then the call home session is up all
    the time (because it's behind a middlebox)

    3.  Zero touch provisioning, then, when there is something
    wrong, a call home session to the NMS (for example, a crash, looking
    for a bug), or
    regular scheduled call home sessions ("Hey NMS, I'm fine")

    

    I'm not sure I've seen a clear definition somewhere.

    And draft-kwatsen-netconf-zerotouch-00
    is only 1 AFAICT. 

    

    Regards, Benoit
    
    
    
    
    
    
    
    
    
    

      



      

        

          

            
- Update the subject to include call home.


          

          
Not sure what to update.


        

      

      

      

        
This draft doesn't only obsolete RFC 5539, it adds an important call
home function
Basically add to the abstract a sentence such as

   It also provides
   an optional mechanism to establish the underlying TCP connection from
   the NETCONF server to the NETCONF client (call home).


      

      
OK. I updated the abstract.

/js



    

    

  


--------------000301040103060104070604--

From kwatsen@juniper.net  Thu Oct 31 05:05:46 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AC111E81BC for ; Thu, 31 Oct 2013 05:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.266
X-Spam-Level: 
X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.334,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARlh6Oi+rn4B for ; Thu, 31 Oct 2013 05:04:57 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 356F611E8320 for ; Thu, 31 Oct 2013 05:04:51 -0700 (PDT)
Received: from mail62-tx2-R.bigfish.com (10.9.14.228) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Thu, 31 Oct 2013 12:04:50 +0000
Received: from mail62-tx2 (localhost [127.0.0.1])	by mail62-tx2-R.bigfish.com (Postfix) with ESMTP id 5688E3601E8; Thu, 31 Oct 2013 12:04:50 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
Received-SPF: pass (mail62-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(24454002)(479174003)(377454003)(164054003)(46102001)(74366001)(81542001)(83506001)(81816001)(54316002)(69226001)(50986001)(51856001)(81342001)(80976001)(19580395003)(76482001)(53806001)(54356001)(59766001)(81686001)(74706001)(56776001)(19580405001)(85306002)(83322001)(77982001)(74876001)(47736001)(65816001)(74502001)(47446002)(80022001)(74662001)(31966008)(66066001)(36756003)(47976001)(49866001)(79102001)(83072001)(77096001)(4396001)(76796001)(76176001)(76786001)(63696002)(56816003)(87266001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.53; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail62-tx2 (localhost.localdomain [127.0.0.1]) by mail62-tx2 (MessageSwitch) id 1383221088839600_17247; Thu, 31 Oct 2013 12:04:48 +0000 (UTC)
Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.232])	by mail62-tx2.bigfish.com (Postfix) with ESMTP id B68A024005C; Thu, 31 Oct 2013 12:04:48 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 31 Oct 2013 12:04:47 +0000
Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 31 Oct 2013 12:04:46 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.810.5; Thu, 31 Oct 2013 12:04:44 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) with mapi id 15.00.0810.005; Thu, 31 Oct 2013 12:04:44 +0000
From: Kent Watsen 
To: "Romascanu, Dan (Dan)" , Juergen Schoenwaelder , Benoit Claise 
Thread-Topic: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments
Thread-Index: AQHO1Wzga6wvKSH+8kyfK43a9URzF5oNM8gAgAAIIICAABaUgP//94kAgAFRxAD//9kTgA==
Date: Thu, 31 Oct 2013 12:04:43 +0000
Message-ID: 
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1291E915@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [66.129.224.53]
x-forefront-prvs: 0016DEFF96
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3B91F3E323062A4B8541E4E0BDE70B89@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: NETCONF 
Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-04 comments
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 12:05:46 -0000

Hi Dan,

You're right that one depends on the other.  Specifically, Zero Touch
depends on Call Home (either SSH or TLS), but Call Home can be implemented
without Zero Touch.

In a nutshell:

  * Call Home: the ability for the device to initiate the connection

  * Zero Touch: the ability for a device to bootstrap its Call Home
configuration

Thanks,
Kent


On 10/31/13 6:24 AM, "Romascanu, Dan (Dan)"  wrote:

>Hi,
>
>It looks to me that there is a clear distinction between the 'ZeroTouch'
>and the 'call home' capabilities which is not articulated clearly in the
>I-Ds text right now. I would not call them orthogonal, as it looks to me
>(please correct me if I am mistaken) that a device supporting the 'call
>home' functionality will support ZeroTouch as a subset.
>
>Regards,
>
>Dan



From kwatsen@juniper.net  Thu Oct 31 05:41:45 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B321E80A3 for ; Thu, 31 Oct 2013 05:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.956
X-Spam-Level: 
X-Spam-Status: No, score=-3.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRL5u7iz71OO for ; Thu, 31 Oct 2013 05:41:38 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 45B3811E825A for ; Thu, 31 Oct 2013 05:41:35 -0700 (PDT)
Received: from mail89-co1-R.bigfish.com (10.243.78.254) by CO1EHSOBE018.bigfish.com (10.243.66.81) with Microsoft SMTP Server id 14.1.225.22; Thu, 31 Oct 2013 12:41:34 +0000
Received: from mail89-co1 (localhost [127.0.0.1])	by mail89-co1-R.bigfish.com (Postfix) with ESMTP id 8CBD4360326; Thu, 31 Oct 2013 12:41:34 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -3
X-BigFish: VPS-3(zz103dKd772hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
Received-SPF: pass (mail89-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(41574002)(189002)(199002)(83072001)(53806001)(79102001)(551544002)(76176001)(47736001)(74876001)(49866001)(4396001)(50986001)(47976001)(65816001)(66066001)(76482001)(74366001)(56776001)(85306002)(54316002)(54356001)(80022001)(74706001)(80976001)(87266001)(76786001)(81342001)(77096001)(46102001)(76796001)(51856001)(83506001)(69226001)(81542001)(74662001)(77982001)(36756003)(63696002)(47446002)(74502001)(31966008)(81686001)(83322001)(59766001)(56816003)(81816001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB329; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail89-co1 (localhost.localdomain [127.0.0.1]) by mail89-co1 (MessageSwitch) id 1383223292547877_27163; Thu, 31 Oct 2013 12:41:32 +0000 (UTC)
Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.241])	by mail89-co1.bigfish.com (Postfix) with ESMTP id 82EE1580067; Thu, 31 Oct 2013 12:41:32 +0000 (UTC)
Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 31 Oct 2013 12:41:32 +0000
Received: from CO1PR05MB329.namprd05.prod.outlook.com (10.141.69.25) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 31 Oct 2013 12:41:28 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB329.namprd05.prod.outlook.com (10.141.69.25) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 31 Oct 2013 12:41:25 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) with mapi id 15.00.0810.005; Thu, 31 Oct 2013 12:41:25 +0000
From: Kent Watsen 
To: Joe Marcus Clarke , "netconf@ietf.org" 
Thread-Topic: [Netconf] draft-kwatsen-netconf-zerotouch
Thread-Index: AQHO0dJuD3W8i4+gjkmkr6qjDN4wpZoOUMsAgAA1gwA=
Date: Thu, 31 Oct 2013 12:41:24 +0000
Message-ID: 
In-Reply-To: <5271EACE.4060506@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [66.129.224.36]
x-forefront-prvs: 0016DEFF96
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Stephen Hanna 
Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 12:41:45 -0000

Hi Joe,

>why would the device need the FQDN of the vendor's DNS
>server?  Couldn't it use the domain name with an NS query to get this?
>I'm trying to think of something that may be more scalable over time
>(i.e., if an older device is deployed that may have an old FQDN).

Because we need to support devices connected to ISP networks (think
McDonalds, Radio Shack, etc.), we cannot assume the presence of any
locally-administered server (DHCP, DNS, LDAP, etc.) that a device could
extract deployment-specific information from.  From the device's
perspective, its local DHCP and DNS servers are administered by the ISP,
who is disinclined to allow its customers to insert customer-specific
information into them.



>What type of DNS queries will be used to get the NMS name and
>credentials?  It would be helpful to see a query flow diagram in this
>draft.

I guess it would be the 'A' record for the
. entry.  As pointed out in the Open
Issues section, already we need to extend DNS to accommodate some data, so
including this data in that analysis as well makes sense.  Being a -00
with no implementation as of yet, we're really just fishing to see if the
IETF has interest.  If so, then we'd be sure to lock down all the unknowns
at that time.



>In the security considerations, you mention the potential threat in a
>malicious party learning the NMS FQDN, but I think the NMS authn
>parameters are more sensitive.  Additionally, there may be hesitance of
>customers to store authn parameters within a vendor database.  One
>potential workaround of this might be an alternate DNS address that the
>new device can query in the customer's network that would provide these
>bits of info.  This would maintain the ability to support
>customer-unconfigurable DHCP servers while still allowing things like
>the NMS parameters to be maintained within the customer's network.

Regarding auth parameters, we'd only support storing public keys or hashed
passwords.  As such, the concern for who has access to them is essentially
eliminated.  With large enough keys lengths, even a brute force attack
would be acceptably unlikely.

I like your idea to have the device's lookup in the vendor's DNS server
pull down the FQDN of a customer-specific DNS server that it could then
query for the customer-specific parameters.  For that matter, it wouldn't
have to be a DNS server anymore, it could even be an HTTP server.
However, in order to ensure security, a trust-anchor for *that* server
would have to provided from the lookup in the vendor's DNS server.  Still,
it's less than what the current draft proposes - definitely worth
analyzing!



>Nit: your link to rfc5539bis points to 6187 instead.

Fixed in my local copy - thanks!


Kent






From j.schoenwaelder@jacobs-university.de  Thu Oct 31 05:58:53 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0519221F9E80 for ; Thu, 31 Oct 2013 05:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.226
X-Spam-Level: 
X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdIIJCSX70lk for ; Thu, 31 Oct 2013 05:58:48 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7110111E8172 for ; Thu, 31 Oct 2013 05:58:47 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45F84200B3; Thu, 31 Oct 2013 13:58:47 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U9KuobKHsfpB; Thu, 31 Oct 2013 13:58:47 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BCABB200AB; Thu, 31 Oct 2013 13:58:46 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id EFB3E291D3E1; Thu, 31 Oct 2013 13:58:40 +0100 (CET)
Date: Thu, 31 Oct 2013 13:58:40 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20131031125840.GA59633@elstar.local>
Mail-Followup-To: Kent Watsen , Joe Marcus Clarke , "netconf@ietf.org" , Stephen Hanna 
References: <5271EACE.4060506@cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Stephen Hanna , "netconf@ietf.org" 
Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 12:58:53 -0000

On Thu, Oct 31, 2013 at 12:41:24PM +0000, Kent Watsen wrote:
> 
> Hi Joe,
> 
> >why would the device need the FQDN of the vendor's DNS
> >server?  Couldn't it use the domain name with an NS query to get this?
> >I'm trying to think of something that may be more scalable over time
> >(i.e., if an older device is deployed that may have an old FQDN).
> 
> Because we need to support devices connected to ISP networks (think
> McDonalds, Radio Shack, etc.), we cannot assume the presence of any
> locally-administered server (DHCP, DNS, LDAP, etc.) that a device could
> extract deployment-specific information from.  From the device's
> perspective, its local DHCP and DNS servers are administered by the ISP,
> who is disinclined to allow its customers to insert customer-specific
> information into them.
> 

http://tools.ietf.org/html/draft-ietf-opsawg-automated-network-configuration-05

Probably not the best document but still a pity that it kind of died.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From kwatsen@juniper.net  Thu Oct 31 09:37:51 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927FC21E8129 for ; Thu, 31 Oct 2013 09:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.911
X-Spam-Level: 
X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifmqtcK0eJGc for ; Thu, 31 Oct 2013 09:37:43 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBEC21E8102 for ; Thu, 31 Oct 2013 09:37:04 -0700 (PDT)
Received: from mail40-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE025.bigfish.com (10.243.66.88) with Microsoft SMTP Server id 14.1.225.22; Thu, 31 Oct 2013 16:36:49 +0000
Received: from mail40-co1 (localhost [127.0.0.1])	by mail40-co1-R.bigfish.com (Postfix) with ESMTP id 48686C4037C; Thu, 31 Oct 2013 16:36:49 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -25
X-BigFish: VPS-25(zzbb2dI98dI9371I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
Received-SPF: pass (mail40-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(51704005)(164054003)(479174003)(377454003)(24454002)(80976001)(74366001)(47736001)(49866001)(56816003)(74706001)(77096001)(83506001)(79102001)(47976001)(51856001)(4396001)(81542001)(50986001)(63696002)(74876001)(76786001)(65816001)(69226001)(80022001)(19580395003)(81342001)(74502001)(47446002)(83072001)(77982001)(59766001)(83322001)(19580405001)(81686001)(46102001)(54316002)(56776001)(76482001)(36756003)(31966008)(85306002)(76796001)(54356001)(74662001)(66066001)(53806001)(81816001)(76176001)(87266001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB330; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail40-co1 (localhost.localdomain [127.0.0.1]) by mail40-co1 (MessageSwitch) id 1383237407117048_16781; Thu, 31 Oct 2013 16:36:47 +0000 (UTC)
Received: from CO1EHSMHS030.bigfish.com (unknown [10.243.78.233])	by mail40-co1.bigfish.com (Postfix) with ESMTP id 0F54DC8003F; Thu, 31 Oct 2013 16:36:47 +0000 (UTC)
Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS030.bigfish.com (10.243.66.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 31 Oct 2013 16:36:46 +0000
Received: from CO1PR05MB330.namprd05.prod.outlook.com (10.141.69.15) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 31 Oct 2013 16:36:46 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB330.namprd05.prod.outlook.com (10.141.69.15) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 31 Oct 2013 16:36:44 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) with mapi id 15.00.0810.005; Thu, 31 Oct 2013 16:36:44 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
Thread-Topic: [Netconf] draft-kwatsen-netconf-zerotouch
Thread-Index: AQHO0dJuD3W8i4+gjkmkr6qjDN4wpZoOUMsAgAA1gwCAAEfkAP//+doA
Date: Thu, 31 Oct 2013 16:36:44 +0000
Message-ID: 
In-Reply-To: <20131031125840.GA59633@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [66.129.224.36]
x-forefront-prvs: 0016DEFF96
Content-Type: text/plain; charset="us-ascii"
Content-ID: <62B4122277177E4A90D6E38663604A72@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Stephen Hanna , "netconf@ietf.org" 
Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 16:37:51 -0000

On 10/31/13 8:58 AM, "Juergen Schoenwaelder"
 wrote:

>http://tools.ietf.org/html/draft-ietf-opsawg-automated-network-configurati
>on-05
>
>Probably not the best document but still a pity that it kind of died.


The concern was for the perceived utility of the document.  I didn't fully
understand the issue, especially since it was an Informational document.

Regardless, it could be said that Zero Touch is a specific implementation
for what's discussed in that draft.   If there is interest in Zero Touch,
I will add a section referencing that draft and how Zero Touch
conforms/deviates from it.

Maybe Zero Touch will garner more support, as its focus is specific to
NETCONF, leveraging the recent reverse-TLS/SSH drafts we're working on
now.  Then again, some might say they want a more holistic solution that
works using SNMP too.  We'll see...

Thanks,
Kent



From bertietf@bwijnen.net  Thu Oct 31 09:46:14 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518E911E8173 for ; Thu, 31 Oct 2013 09:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.625
X-Spam-Level: 
X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UxSZbVqAGIL for ; Thu, 31 Oct 2013 09:45:56 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 3E26921F9EC4 for ; Thu, 31 Oct 2013 09:45:53 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VbvNV-0003Eu-UV; Thu, 31 Oct 2013 17:45:52 +0100
Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VbvNV-0006rM-Pu; Thu, 31 Oct 2013 17:45:49 +0100
Message-ID: <5272893D.1030406@bwijnen.net>
Date: Thu, 31 Oct 2013 17:45:49 +0100
From: "Bert Wijnen (IETF)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Kent Watsen ,  Juergen Schoenwaelder 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20131031 clean
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: 86ab03e524994f79ca2c75a176445dd4f8e0db151333b7ced86f36c82ad0eb0f
Cc: Stephen Hanna , "netconf@ietf.org" 
Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 16:46:14 -0000

My personal recommendation would be:

- we failed some years ago to go for a generic/holistic solution.

- let us now focus on a point solution for NETCONF

so we do no re-waste a lot of cycles.

Bert

On 10/31/13 5:36 PM, Kent Watsen wrote:
>
>
> On 10/31/13 8:58 AM, "Juergen Schoenwaelder"
>  wrote:
>
>> http://tools.ietf.org/html/draft-ietf-opsawg-automated-network-configurati
>> on-05
>>
>> Probably not the best document but still a pity that it kind of died.
>
>
> The concern was for the perceived utility of the document.  I didn't fully
> understand the issue, especially since it was an Informational document.
>
> Regardless, it could be said that Zero Touch is a specific implementation
> for what's discussed in that draft.   If there is interest in Zero Touch,
> I will add a section referencing that draft and how Zero Touch
> conforms/deviates from it.
>
> Maybe Zero Touch will garner more support, as its focus is specific to
> NETCONF, leveraging the recent reverse-TLS/SSH drafts we're working on
> now.  Then again, some might say they want a more holistic solution that
> works using SNMP too.  We'll see...
>
> Thanks,
> Kent
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

From touch@isi.edu  Thu Oct 31 09:52:44 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B91B11E825F for ; Thu, 31 Oct 2013 09:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level: 
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gCTA9gqXEnd for ; Thu, 31 Oct 2013 09:52:38 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9225D11E8249 for ; Thu, 31 Oct 2013 09:52:38 -0700 (PDT)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9VGpguv017938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Oct 2013 09:51:44 -0700 (PDT)
Message-ID: <52728AA4.7010104@isi.edu>
Date: Thu, 31 Oct 2013 09:51:48 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Kent Watsen , "netconf@ietf.org" 
References:  <52718DF2.4050808@isi.edu> <20131031065153.GA57570@elstar.local>
In-Reply-To: <20131031065153.GA57570@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 16:52:44 -0000

On 10/30/2013 11:51 PM, Juergen Schoenwaelder wrote:
> On Wed, Oct 30, 2013 at 03:53:38PM -0700, Joe Touch wrote:
>>
>> And for similar reasons I would suggest they use the existing
>> NETCONF TLS port.
>>
>
> Joe,
>
> if you have a box that runs a regular NETCONF server and a NETCONF
> client that is used for call-home by other remote NETCONF servers,
> how are they going to share the port number?

The question isn't whether this makes implementation simpler, it's 
whether this defines a new service.

This situation above isn't addressed at all in the "applicability 
statement" of the doc.

Finally, there are a lot of ways in which a single port can be shared by 
multiple processes, so that's an implementation detail that doesn't 
necessarily justify a new port. E.g., if the two are expected to be 
implemented in a single software system (which would be the case if 
there is expected shared or coordinated state, etc.), then they would 
share a port very easily.

So far, I still have not heard a description of a new service, but 
rather an extension of an existing one.

Joe


From andy@yumaworks.com  Thu Oct 31 10:33:24 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D0C11E823D for ; Thu, 31 Oct 2013 10:33:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.710,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPgEIHMoHrO7 for ; Thu, 31 Oct 2013 10:33:19 -0700 (PDT)
Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3011E8164 for ; Thu, 31 Oct 2013 10:32:53 -0700 (PDT)
Received: by mail-pb0-f47.google.com with SMTP id rq2so3116348pbb.34 for ; Thu, 31 Oct 2013 10:32: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=Dgt2jp3M5fBvrbwvdjg5mx023QHeiqddYOLpwXx0y7o=; b=lwXw9hfgP7rsMMdhEqX+bOuG1GAESoMxzIukxmDrjxzP5argdewyppK7xdW+i2Pb2T G1zR0/D6LYeny+5tYwdklmxJoQ0l9G+ajsTiFeeUYgzD3Tp38ljhqfcS/dk+uz0QApxN C/SyVDLmYvM04T1HkXI7T7N5mMJew+ifyKc9fwSHL0qQGY/AnklY74t2EuQTAECqP7e5 eOZN8qtfWtWbwB/ioXKtK+Y6bp2nlUu19jqgUId2awNSIA9BNX68cdaQkkFL+BjV42PZ Z0Da1kfiRgk2N9FvUH3T+H8bst0rVWqovyK61kyUv8IeH1L3d3EG0lpZ2qHZh4FtZ1ZW TYkw==
X-Gm-Message-State: ALoCoQn2F5EEzLHTYIjD4Nv7ACDv8/0Cb/7yMG1mzi/1F20M4u/2v/zRQgrEq/R2naUpHJzDKuof
MIME-Version: 1.0
X-Received: by 10.66.102.100 with SMTP id fn4mr3132540pab.71.1383240773293; Thu, 31 Oct 2013 10:32:53 -0700 (PDT)
Received: by 10.70.9.33 with HTTP; Thu, 31 Oct 2013 10:32:53 -0700 (PDT)
In-Reply-To: <52728AA4.7010104@isi.edu>
References:  <52718DF2.4050808@isi.edu> <20131031065153.GA57570@elstar.local> <52728AA4.7010104@isi.edu>
Date: Thu, 31 Oct 2013 10:32:53 -0700
Message-ID: 
From: Andy Bierman 
To: Joe Touch 
Content-Type: multipart/alternative; boundary=047d7bd9036cee751804ea0cd6e3
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 17:33:24 -0000

--047d7bd9036cee751804ea0cd6e3
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I think a new port number is needed or else an important use-case
cannot be implemented.

We want to be able to support a mid-level manager that implements
network-wide data models.  An NMS uses NETCONF to manage the
network models (MLM in plain NETCONF server role).  The MLM
manages lots of individual devices with NETCONF, using NETCONF
over Reverse SSH (MLM in NETCONF client role).

The service may be NETCONF, but NETCONF defines a client peer and a server
peer,
and they are very different.  If the same port is used, then the service
deamon
does not know which role is being requested.


Andy


On Thu, Oct 31, 2013 at 9:51 AM, Joe Touch  wrote:

>
>
> On 10/30/2013 11:51 PM, Juergen Schoenwaelder wrote:
>
>> On Wed, Oct 30, 2013 at 03:53:38PM -0700, Joe Touch wrote:
>>
>>>
>>> And for similar reasons I would suggest they use the existing
>>> NETCONF TLS port.
>>>
>>>
>> Joe,
>>
>> if you have a box that runs a regular NETCONF server and a NETCONF
>> client that is used for call-home by other remote NETCONF servers,
>> how are they going to share the port number?
>>
>
> The question isn't whether this makes implementation simpler, it's whether
> this defines a new service.
>
> This situation above isn't addressed at all in the "applicability
> statement" of the doc.
>
> Finally, there are a lot of ways in which a single port can be shared by
> multiple processes, so that's an implementation detail that doesn't
> necessarily justify a new port. E.g., if the two are expected to be
> implemented in a single software system (which would be the case if there
> is expected shared or coordinated state, etc.), then they would share a
> port very easily.
>
> So far, I still have not heard a description of a new service, but rather
> an extension of an existing one.
>
> Joe
>
> ______________________________**_________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/**listinfo/netconf
>

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


Hi,

I think a new port number is needed=
 or else an important use-case
cannot be implemented.
<=
br>
We want to be able to support a mid-level manager that implem=
ents


network-wide data models. =A0An NMS uses NETCONF to manage the
network models (MLM in plain NETCONF server role). =A0The MLM
=
manages lots of individual devices with NETCONF, using NETCONF
ov=
er Reverse SSH (MLM in NETCONF client role).



The service may be NETCONF, but NETCONF defines a clien=
t peer and a server peer,
and they are very different. =A0If the =
same port is used, then the service deamon
does not know which ro=
le is being requested.




<=
div class=3D"gmail_extra">Andy


On Thu, Oct 31, 2013 at 9:51 AM, Joe Touch <touch@isi.e=
du> wrote:






On 10/30/2013 11:51 PM, Juergen Schoenwaelder wrote:



On Wed, Oct 30, 2013 at 03:53:38PM -0700, Joe Touch wrote:





And for similar reasons I would suggest they use the existing

NETCONF TLS port.







Joe,



if you have a box that runs a regular NETCONF server and a NETCONF

client that is used for call-home by other remote NETCONF servers,

how are they going to share the port number?





The question isn't whether this makes implementation simpler, it's =
whether this defines a new service.



This situation above isn't addressed at all in the "applicability =
statement" of the doc.



Finally, there are a lot of ways in which a single port can be shared by mu=
ltiple processes, so that's an implementation detail that doesn't n=
ecessarily justify a new port. E.g., if the two are expected to be implemen=
ted in a single software system (which would be the case if there is expect=
ed shared or coordinated state, etc.), then they would share a port very ea=
sily.




So far, I still have not heard a description of a new service, but rather a=
n extension of an existing one.



Joe



_______________________________________________

Netconf mailing list

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





--047d7bd9036cee751804ea0cd6e3--

From touch@isi.edu  Thu Oct 31 10:46:38 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2A611E822D for ; Thu, 31 Oct 2013 10:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.639
X-Spam-Level: 
X-Spam-Status: No, score=-105.639 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1fasH5PU7uG for ; Thu, 31 Oct 2013 10:46:32 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6120E21F9B21 for ; Thu, 31 Oct 2013 10:46:32 -0700 (PDT)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9VHk2sb028165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Oct 2013 10:46:02 -0700 (PDT)
Message-ID: <5272975A.2030904@isi.edu>
Date: Thu, 31 Oct 2013 10:46:02 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Andy Bierman 
References: 	<52718DF2.4050808@isi.edu>	<20131031065153.GA57570@elstar.local>	<52728AA4.7010104@isi.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 17:46:38 -0000

On 10/31/2013 10:32 AM, Andy Bierman wrote:
> Hi,
>
> I think a new port number is needed or else an important use-case
> cannot be implemented.
>
> We want to be able to support a mid-level manager that implements
> network-wide data models.  An NMS uses NETCONF to manage the
> network models (MLM in plain NETCONF server role).  The MLM
> manages lots of individual devices with NETCONF, using NETCONF
> over Reverse SSH (MLM in NETCONF client role).
>
> The service may be NETCONF, but NETCONF defines a client peer and a
> server peer, and they are very different. If the same port is used,
> then the service deamon does not know which role is being requested.

Why would (should) that not happen in-band, as part of the message type?

Joe

From kwatsen@juniper.net  Thu Oct 31 11:08:03 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220B311E829C for ; Thu, 31 Oct 2013 11:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.377
X-Spam-Level: 
X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InaV7FmO0e5T for ; Thu, 31 Oct 2013 11:07:35 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id BAD8C11E817A for ; Thu, 31 Oct 2013 11:06:40 -0700 (PDT)
Received: from mail3-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE009.bigfish.com (10.174.4.72) with Microsoft SMTP Server id 14.1.225.22; Thu, 31 Oct 2013 18:06:39 +0000
Received: from mail3-db8 (localhost [127.0.0.1])	by mail3-db8-R.bigfish.com (Postfix) with ESMTP id 32C4510009C; Thu, 31 Oct 2013 18:06:39 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -5
X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
Received-SPF: pass (mail3-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(51704005)(199002)(189002)(164054003)(479174003)(377454003)(76176001)(85306002)(69226001)(81686001)(83506001)(56776001)(80022001)(65816001)(79102001)(77982001)(76482001)(54316002)(83322001)(76786001)(77096001)(76796001)(56816003)(66066001)(59766001)(63696002)(53806001)(51856001)(50986001)(46102001)(47976001)(4396001)(74876001)(49866001)(19580405001)(54356001)(19580395003)(36756003)(81342001)(80976001)(74706001)(81816001)(47736001)(31966008)(74366001)(74662001)(74502001)(47446002)(83072001)(81542001)(87266001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail3-db8 (localhost.localdomain [127.0.0.1]) by mail3-db8 (MessageSwitch) id 1383242797716379_30262; Thu, 31 Oct 2013 18:06:37 +0000 (UTC)
Received: from DB8EHSMHS005.bigfish.com (unknown [10.174.8.232])	by mail3-db8.bigfish.com (Postfix) with ESMTP id AB27A480049; Thu, 31 Oct 2013 18:06:37 +0000 (UTC)
Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS005.bigfish.com (10.174.4.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 31 Oct 2013 18:06:35 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 31 Oct 2013 18:06:32 +0000
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.810.5; Thu, 31 Oct 2013 18:06:30 +0000
Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.180]) with mapi id 15.00.0810.005; Thu, 31 Oct 2013 18:06:30 +0000
From: Kent Watsen 
To: Joe Touch , Andy Bierman 
Thread-Topic: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt
Thread-Index: AQHO1OPawXUSQhu+mUmffU8BzRNWW5oMIYQAgAFDogCAAHbQAIAAhZ+AgACnnQCAAAt7gIAAA6wA///CpoA=
Date: Thu, 31 Oct 2013 18:06:30 +0000
Message-ID: 
In-Reply-To: <5272975A.2030904@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [66.129.224.36]
x-forefront-prvs: 0016DEFF96
Content-Type: text/plain; charset="us-ascii"
Content-ID: <817BEC55439435489FFE0F19F83BF5DC@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 18:08:03 -0000

On 10/31/13 1:46 PM, "Joe Touch"  wrote:

>
>Why would (should) that not happen in-band, as part of the message type?

Because it would require updating both the SSH and TLS protocols to enable
reversal before the crypto tunnel is setup.  This is not likely to garner
consensus given the Applicability Statements limiting the solution to just
NETCONF, especially given the option to use a port instead.

Thanks,
Kent






From mbj@tail-f.com  Thu Oct 31 11:14:56 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F9B11E822D for ; Thu, 31 Oct 2013 11:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.013
X-Spam-Level: 
X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 458MPTLXf8id for ; Thu, 31 Oct 2013 11:14:49 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5811E818A for ; Thu, 31 Oct 2013 11:14:49 -0700 (PDT)
Received: from localhost (unknown [193.12.34.23]) by mail.tail-f.com (Postfix) with ESMTPSA id 47B6512000B4; Thu, 31 Oct 2013 19:14:47 +0100 (CET)
Date: Thu, 31 Oct 2013 19:14:46 +0100 (CET)
Message-Id: <20131031.191446.362075100.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: 
References: <5272975A.2030904@isi.edu> 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 18:14:56 -0000

Kent Watsen  wrote:
> 
> 
> On 10/31/13 1:46 PM, "Joe Touch"  wrote:
> 
> >
> >Why would (should) that not happen in-band, as part of the message type?
> 
> Because it would require updating both the SSH and TLS protocols to enable
> reversal before the crypto tunnel is setup.  This is not likely to garner
> consensus given the Applicability Statements limiting the solution to just
> NETCONF, especially given the option to use a port instead.

Agreed.  Also, I think these are fundamentally two different services;
one is a NETCONF server (e.g. some managed device) and the other a
NETCONF client (e.g. a NMS).


/martin

From touch@isi.edu  Thu Oct 31 11:17:59 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAA311E822D for ; Thu, 31 Oct 2013 11:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.636
X-Spam-Level: 
X-Spam-Status: No, score=-103.636 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NI6EoHN7Fea for ; Thu, 31 Oct 2013 11:17:54 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99311E81F0 for ; Thu, 31 Oct 2013 11:17:46 -0700 (PDT)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9VIHegf012683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 31 Oct 2013 11:17:42 -0700 (PDT)
Message-ID: <52729EC4.1050703@isi.edu>
Date: Thu, 31 Oct 2013 11:17:40 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Martin Bjorklund , kwatsen@juniper.net
References: <5272975A.2030904@isi.edu>	 <20131031.191446.362075100.mbj@tail-f.com>
In-Reply-To: <20131031.191446.362075100.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: netconf@ietf.org
Subject: Re: [Netconf] I-D ACTION:draft-ietf-netconf-reverse-ssh-02.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 18:18:00 -0000

On 10/31/2013 11:14 AM, Martin Bjorklund wrote:
> Kent Watsen  wrote:
>>
>>
>> On 10/31/13 1:46 PM, "Joe Touch"  wrote:
>>
>>>
>>> Why would (should) that not happen in-band, as part of the message type?
>>
>> Because it would require updating both the SSH and TLS protocols to enable
>> reversal before the crypto tunnel is setup.  This is not likely to garner
>> consensus given the Applicability Statements limiting the solution to just
>> NETCONF, especially given the option to use a port instead.
>
> Agreed.  Also, I think these are fundamentally two different services;
> one is a NETCONF server (e.g. some managed device) and the other a
> NETCONF client (e.g. a NMS).

First, can any of that be explained in this doc?

In specific:

	- how the services differ

	- why reversing the existing netconf-ssh system
	isn't a useful way forward

	- the specific use case where both a client and server
	would sit on the same device, and why those would be independent

All of these questions are begged by the name "reverse NETCONF". If 
that's not what you're really doing, this needs a better, more accurate 
description.

Joe

From j.schoenwaelder@jacobs-university.de  Thu Oct 31 12:20:48 2013
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02D311E81A8 for ; Thu, 31 Oct 2013 12:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.226
X-Spam-Level: 
X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBDGurHb7Eft for ; Thu, 31 Oct 2013 12:20:44 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4F311E814F for ; Thu, 31 Oct 2013 12:20:40 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1486C200B8; Thu, 31 Oct 2013 20:20:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id szhJlI5fHTJ2; Thu, 31 Oct 2013 20:20:29 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D14B2011A; Thu, 31 Oct 2013 20:20:29 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 9A44E29217E3; Thu, 31 Oct 2013 20:20:23 +0100 (CET)
Date: Thu, 31 Oct 2013 20:20:22 +0100
From: Juergen Schoenwaelder 
To: "Bert Wijnen (IETF)" 
Message-ID: <20131031192022.GA60736@elstar.local>
Mail-Followup-To: "Bert Wijnen (IETF)" , Kent Watsen , Stephen Hanna , "netconf@ietf.org" 
References:  <5272893D.1030406@bwijnen.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5272893D.1030406@bwijnen.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Stephen Hanna , "netconf@ietf.org" 
Subject: Re: [Netconf] draft-kwatsen-netconf-zerotouch
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Oct 2013 19:20:48 -0000

Except that the I-D was never a solution document. It tried to provide
an overview what is out there - anyway, I am over it.

/js

On Thu, Oct 31, 2013 at 05:45:49PM +0100, Bert Wijnen (IETF) wrote:
> My personal recommendation would be:
> 
> - we failed some years ago to go for a generic/holistic solution.
> 
> - let us now focus on a point solution for NETCONF
> 
> so we do no re-waste a lot of cycles.
> 
> Bert
> 
> On 10/31/13 5:36 PM, Kent Watsen wrote:
> >
> >
> >On 10/31/13 8:58 AM, "Juergen Schoenwaelder"
> > wrote:
> >
> >>http://tools.ietf.org/html/draft-ietf-opsawg-automated-network-configurati
> >>on-05
> >>
> >>Probably not the best document but still a pity that it kind of died.
> >
> >
> >The concern was for the perceived utility of the document.  I didn't fully
> >understand the issue, especially since it was an Informational document.
> >
> >Regardless, it could be said that Zero Touch is a specific implementation
> >for what's discussed in that draft.   If there is interest in Zero Touch,
> >I will add a section referencing that draft and how Zero Touch
> >conforms/deviates from it.
> >
> >Maybe Zero Touch will garner more support, as its focus is specific to
> >NETCONF, leveraging the recent reverse-TLS/SSH drafts we're working on
> >now.  Then again, some might say they want a more holistic solution that
> >works using SNMP too.  We'll see...
> >
> >Thanks,
> >Kent
> >
> >
> >_______________________________________________
> >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