From nobody Wed Apr 1 09:43:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BD01A1B48 for ; Wed, 1 Apr 2015 09:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEDr6uRy1cv3 for ; Wed, 1 Apr 2015 09:42:57 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0759E1AD362 for ; Wed, 1 Apr 2015 09:42:30 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-c5-551c1ff43584 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.1F.28347.4FF1C155; Wed, 1 Apr 2015 18:42:29 +0200 (CEST) Received: from [159.107.198.3] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.210.2; Wed, 1 Apr 2015 18:42:28 +0200 Message-ID: <551C1FF4.30302@ericsson.com> Date: Wed, 1 Apr 2015 18:42:28 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "netconf@ietf.org" Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvje5XeZlQg8ZLfBZTN91mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxodPH1gKJvFUrN7bxt7AeIGzi5GTQ0LAROLWj/PsELaYxIV7 69m6GLk4hASOMkrcfbObDSQhJLCKUeLRBykQm1dAU+L5xVVMXYwcHCwCKhK3L/KBhNkEjCSm 9p9nAbFFBaIkev50s0GUC0qcnPkELC4C1No46wMriC0sYCFx/lUTWJxZQEOidc5cdghbXmL7 2znMEGs1JB5e+Ms6gZFvFpJRs5C0zELSsoCReRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZG YEAd3PLbYAfjy+eOhxgFOBiVeHgTOqVDhVgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXAGPzAXenktvNcS++t5+k4caemx6a4M3nt6RumKWtcTMzKA5/xzFzv u6ntqOT26sqtFz/X6q5Kf/EtrKC40Izpi7/M+zfTUtVswk2Ol1obdr7+ecsi9+LbvGt6f08s 8Dp06cnujmzRyavrcyNeurVk8sXuX/9U9NLKkK/BnM9lPBsvVzxpK4ozUmIpzkg01GIuKk4E AF3JAEsJAgAA Archived-At: Subject: [Netconf] YANG models in the RFC 6022 capabilites branch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:42:59 -0000 Hello
Reading RFC6022 I got the impression it contains capabilities for YANG datamodels twice. Once in the capabilities branch and once in the schemas.
Is this interpretation correct? If yes it is somewhat annoying.

RFC6020:
Announcing Conformance Information in the <hello> Message
The namespace URI MUST be advertised as a capability in the NETCONF
   <hello> message to indicate support for the YANG module by a NETCONF
   server.
RFC 6022
2.1.1.  The /netconf-state/capabilities Subtree
   The /netconf-state/capabilities subtree contains the capabilities
   supported by the NETCONF server.  The list MUST include all
   capabilities exchanged during session setup still applicable at the
   time of the request.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Wed Apr 1 09:54:18 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16D61AD362 for ; Wed, 1 Apr 2015 09:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiLkl9IOrhE9 for ; Wed, 1 Apr 2015 09:54:14 -0700 (PDT) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED38D1AD358 for ; Wed, 1 Apr 2015 09:54:13 -0700 (PDT) Received: by lagg8 with SMTP id g8so41458267lag.1 for ; Wed, 01 Apr 2015 09:54:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nWM6XHkm8iUap4ATQ9CEnS2soORLu+oS0+wed1MY8+w=; b=IlN8docN4oVeY9fMRC8gZLkqAr7nB+vARWh9LCh+MF1OIsBPvYx2UmSuCWT/dUE1q+ 12IJxEBMm8LBwawa8TCB5J+zJe6xP02YsvTdPjL9QWxJc4dAHQxpdZp6rHU9z6QlGNuK IKWoaICNkujmsEKsRmWiAl50yoa4yQVpCeG7MCz1LEhx3qWM1PUQOcCQAcmj+o/tJcfo zfxTsrZbhClsgII7RCg2bsC2ob1yeCXKcg66BxQO01pZGqIS4fcxqGNKfVCjjKXQryzv WvzQV6LIdX0YrmOsCBgMjiDiZ4+afXvrb86xzMvUrYdpX+052EBdbwey73tEYRc0Tn24 J1FA== X-Gm-Message-State: ALoCoQkzECOIE43cjZXej6VrdX5IihLpJTvoHaorkj15xRA5dFoJ3AMTrhzE/OrkiG+bGEjwnL0L MIME-Version: 1.0 X-Received: by 10.152.30.8 with SMTP id o8mr9931211lah.37.1427907252240; Wed, 01 Apr 2015 09:54:12 -0700 (PDT) Received: by 10.112.98.168 with HTTP; Wed, 1 Apr 2015 09:54:12 -0700 (PDT) In-Reply-To: <551C1FF4.30302@ericsson.com> References: <551C1FF4.30302@ericsson.com> Date: Wed, 1 Apr 2015 09:54:12 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] YANG models in the RFC 6022 capabilites branch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:54:15 -0000 On Wed, Apr 1, 2015 at 9:42 AM, Balazs Lengyel wrote: > Hello > Reading RFC6022 I got the impression it contains capabilities for YANG > datamodels twice. Once in the capabilities branch and once in the schemas. > Is this interpretation correct? If yes it is somewhat annoying. > yes this is correct. The tables provide different data so IMO it is not annoying. Andy > RFC6020: > > Announcing Conformance Information in the Message > > The namespace URI MUST be advertised as a capability in the NETCONF > message to indicate support for the YANG module by a NETCONF > server. > > RFC 6022 > > 2.1.1. The /netconf-state/capabilities Subtree > > The /netconf-state/capabilities subtree contains the capabilities > supported by the NETCONF server. The list MUST include all > capabilities exchanged during session setup still applicable at the > time of the request. > > Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Apr 2 02:12:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EC21B2C14 for ; Thu, 2 Apr 2015 02:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiIVvnBGhFAj for ; Thu, 2 Apr 2015 02:12:26 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB781B2C1B for ; Thu, 2 Apr 2015 02:12:25 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-7e-551d07f7f954 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 23.5D.01716.7F70D155; Thu, 2 Apr 2015 11:12:24 +0200 (CEST) Received: from [159.107.197.226] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.210.2; Thu, 2 Apr 2015 11:12:23 +0200 Message-ID: <551D07F7.3060206@ericsson.com> Date: Thu, 2 Apr 2015 11:12:23 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Andy Bierman References: <551C1FF4.30302@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvje4PdtlQg2cr+SweHJnFbjF1021W ByaPJUt+Mnm09F9kCWCK4rJJSc3JLEst0rdL4Mr4OuMgS8EV3oqO5vWsDYyHuboYOTkkBEwk Lk28wgRhi0lcuLeerYuRi0NI4CijxMbHKxkhnDWMEsdnv2QBqeIV0Ja4Of01G4jNIqAi8Wfm PmYQm03ASGJq/3mwGlGBKImeP91sEPWCEidnPgGLiwioSlyYOxGsnllAU2Lt349gtrCAm8SW o7fA6oUE8iTefH8LVs8pECixdCfEdcwCFhIz559nhLDlJba/ncMMUa8h8fDCX9YJjIKzkKyb haRlFpKWBYzMqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECA/bglt+6OxhXv3Y8xCjAwajE w/vglkyoEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYl2er V1QJ3xU3m1d7LzJI4PANs8/vvdSW3XscdnaiQ5IA/723As4nF35+J7ZUnFNbISH80NrqA6dN +bXuOGhwv2A33bJypgX3ueXdez6HllpW7lrkqb1gubH37r/t1Su0TmwODlAuvTox2/vxTq5P LM+seP7mqSzbK6EWPa322Pq3n1YGcbk/UGIpzkg01GIuKk4EACbKbUk5AgAA Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] YANG models in the RFC 6022 capabilites branch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 09:12:28 -0000 This way a YANG module is visible in 3 places: RFC6022 schema branch, capabilities branch and the new yang-library module. Seems a bit excessive. Balazs On 2015-04-01 18:54, Andy Bierman wrote: > On Wed, Apr 1, 2015 at 9:42 AM, Balazs Lengyel > wrote: >> Hello >> Reading RFC6022 I got the impression it contains capabilities for YANG >> datamodels twice. Once in the capabilities branch and once in the schemas. >> Is this interpretation correct? If yes it is somewhat annoying. >> > yes this is correct. > The tables provide different data so IMO it is not annoying. > > > Andy > >> RFC6020: >> >> Announcing Conformance Information in the Message >> >> The namespace URI MUST be advertised as a capability in the NETCONF >> message to indicate support for the YANG module by a NETCONF >> server. >> >> RFC 6022 >> >> 2.1.1. The /netconf-state/capabilities Subtree >> >> The /netconf-state/capabilities subtree contains the capabilities >> supported by the NETCONF server. The list MUST include all >> capabilities exchanged during session setup still applicable at the >> time of the request. >> >> Balazs >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> ECN: 831 7320 >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Apr 2 02:20:16 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A281B2C20 for ; Thu, 2 Apr 2015 02:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPpNMbj9k2M0 for ; Thu, 2 Apr 2015 02:20:13 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id D91E51B2C1B for ; Thu, 2 Apr 2015 02:20:12 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id E45B51280477; Thu, 2 Apr 2015 11:20:11 +0200 (CEST) Date: Thu, 02 Apr 2015 11:20:38 +0200 (CEST) Message-Id: <20150402.112038.363779998942540751.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <551D07F7.3060206@ericsson.com> References: <551C1FF4.30302@ericsson.com> <551D07F7.3060206@ericsson.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] YANG models in the RFC 6022 capabilites branch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 09:20:14 -0000 Balazs Lengyel wrote: > This way a YANG module is visible in 3 places: RFC6022 schema branch, > capabilities branch and the new yang-library module. Seems a bit > excessive. Well, a YANG 1.1 module wouldn't be present in the capabilities list. But maybe an update to 6022 should deprecate the schema list. /martin From nobody Thu Apr 2 02:41:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1D81B2C2C for ; Thu, 2 Apr 2015 02:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3n5-AT2khAy for ; Thu, 2 Apr 2015 02:41:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347421B2C29 for ; Thu, 2 Apr 2015 02:41:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t329fARG029372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 2 Apr 2015 09:41:11 GMT 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 t329f83h017619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 Apr 2015 11:41:10 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 2 Apr 2015 11:41:08 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.51]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0224.002; Thu, 2 Apr 2015 11:41:08 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: [Netconf] The use of YANG 1.1 Features in NETCONF Drafts WAS: Summary and AIs from the NETCONF Session in IETF #92 Thread-Index: AQHQbSkkzD0Kcy44H0y2cIO5Q2TlGw== Date: Thu, 2 Apr 2015 09:41:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819679AF1DEMUMBX005nsnin_" 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: 77176 X-purgate-ID: 151667::1427967671-0000328B-3D8F9046/0/0 Archived-At: Subject: Re: [Netconf] The use of YANG 1.1 Features in NETCONF Drafts WAS: Summary and AIs from the NETCONF Session in IETF #92 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 09:41:21 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819679AF1DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, we assume now consensus on the usage of YANG 1.1 features in current NETCON= F WG items. Regards, Mehmet & Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (Nokia - DE/Munich) Sent: Thursday, March 26, 2015 12:50 AM To: netconf@ietf.org Subject: [Netconf] The use of YANG 1.1 Features in NETCONF Drafts WAS: Summ= ary and AIs from the NETCONF Session in IETF #92 Dear NETCONF WG, this email is to verify the opinion poll in IETF 92 NETCONF session concern= ing the use of YANG 1.1 Features in NETCONF Drafts. As reported in the session summary below, the opinion poll for the use of Y= ANG 1.1 features has been supported by 16 and disagreed by 1 person. The disagreement was based on the assumption that the finalization of the Y= ANG 1.1 draft may possibly take longer than currently expected. Please speak up by April 1, 2015 23:59 PT, if you have objections to use YA= NG 1.1 features in current NETCONF drafts. The co-chairs will declare consensus after the deadline. Regards, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (Nokia - DE/Munich) Sent: Thursday, March 26, 2015 12:01 AM To: Benoit Claise; netconf@ietf.org Subject: [Netconf] Summary and AIs from the NETCONF Session in IETF #92 Hi Benoit, NETCONF WG, below is a summary and action items from the NETCONF WG session on March 24= , 2014, Dallas, USA. A Wiki version of this summary will be made available at OPS area Wiki page= soon (at http://trac.tools.ietf.org/area/ops/trac/wiki/IETF92summary). - We had approx. 90+ participants in the 2 hour NETCONF session, - We reviewed the status of the WG (https://www.ietf.org/proceedings/92/sli= des/slides-92-netconf-2.pptx), - We had a discussion on 7 chartered documents. - Note taker was: Lada Lhotka. The Jabber scribe was Mikael Abrahamsson. Many thanks to the note takers and jabber scribe for volunteering. The session agenda is available at: https://www.ietf.org/proceedings/92/age= nda/agenda-92-netconf Following is a summary of the discussion and the decisions taken per show-h= ands. If there is no strong objection we will implement as proposed. * Issues after the WGLC of the RESTCONF and YANG Patch drafts have = been discussed. See https://www.ietf.org/proceedings/92/slides/slides-92-ne= tconf-0.pdf and https://www.ietf.org/proceedings/92/slides/slides-92-netcon= f-1.pdf. * Currently open issues for the YANG Library and RESTCONF Collectio= n Resource drafts have been discussed. See https://www.ietf.org/proceedings= /92/slides/slides-92-netconf-10.pdf and https://www.ietf.org/proceedings/92= /slides/slides-92-netconf-11.pdf. * A few issues are remaining and will be taken to the maillist. If = there is no objection, the solution described on an issue slide will be rea= lized as proposed. WG members are asked to speak up on the maillist if ther= e is any concern on the proposed solution. * RESTCONF, YANG Patch and YANG Library drafts will go to 2nd WGLC = a few weeks after IETF 92 once the drafts are available after issue solving= . * WG co-chairs are asking the chairs of related WGs (e.g. Core, 6lo= , 6tisch) to assign individuals as reviewer. * Issues after the WGLC of the Call Home and Server Model drafts ha= ve been discussed. See https://www.ietf.org/proceedings/92/slides/slides-92= -netconf-4.pptx and https://www.ietf.org/proceedings/92/slides/slides-92-ne= tconf-5.pptx. * If there is no objection, the solution described on an issue slid= e will be realized as proposed. WG members are asked to speak up on the mai= llist if there is any concern on the proposed solution. * Call Home and Server Model drafts will go to 2nd WGLC once the dr= afts are available after issue solving and after finalizing the WGLC for th= e RESTCONF drafts. * During the discussion of the Server Model draft, the use of the Y= ANG 1.1 features in current NETCONF drafts has been proposed. The opinion p= oll showed 16 yes, 1 no from Andy B. * AI: Co-chairs will send an email to the NETCONF maillist to verif= y the poll in the meeting. * The open issues in Zerotouch draft have been discussed briefly. S= ee https://www.ietf.org/proceedings/92/slides/slides-92-netconf-7.pptx. Ken= t W. is discussing the details of the requirements on Zerotouch draft with = ANIMA WG members. ANIMA WG is asked to agree on these requirements first in= their WG before starting a discussion in the NETCONF WG based on a new dra= ft or subsection in an existing draft. * I2RS co-chair Jeff Haas summarized the NETCONF-related issues dis= cussed in I"RS WG, which are Pub-sub requirements, Ephemeral state, Seconda= ry Identity, Priority, Transactions. See https://www.ietf.org/proceedings/9= 2/slides/slides-92-netconf-8.pptx. * Ephemeral state is a particular issue important for I2RS WG. The = volunteers for this issue (Dan B, Martin, Ken and Andy) will restart their = work. * draft-haas-i2rs-netmod-netconf-requirements is serving as a track= ing document for I2RS protocol requirements. Current requirements on epheme= ral state are written down in the architecture draft. * Mehmet proposed a joint conf call to discuss the details of these= issue in a joint conference call. AI: Mehmet to provide a doodle. * Eric Voit presented on draft-ietf-i2rs-pub-sub-requirements-01. S= ee https://www.ietf.org/proceedings/92/slides/slides-92-netconf-9.pdf. * The related solution draft addressing these requirements has been= presented by Alex Clemm. See https://www.ietf.org/proceedings/92/slides/sl= ides-92-netconf-14.pdf. This draft is proposed to adopt in NETCONF WG. 12 h= ave read the draft. 12 support the draft and 0 against. * Mehmet clarified that new WG items can be adopted after finalizin= g current active items. This will be possibly in IETF 93 time frame. * draft-liu-netconf-multiple-replies-00 on Processing Multiple Repl= ies for One Request in NETCONF has been presented by Guangying Zheng. See h= ttps://www.ietf.org/proceedings/92/slides/slides-92-netconf-3.ppt. 5 people= have read the draft. 5 support adopting the draft. Will take it to the mai= ling list. * draft-mm-netconf-time-capability-02 on Time Capability in NETCONF= couldn't be discussed due to lack of time. See https://www.ietf.org/procee= dings/92/slides/slides-92-netconf-13.pdf. * The chair suggested that both, draft-liu and draft-mm, should rai= se discussion on the maillist and get the support of the WG members. Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F819679AF1DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi All,

=  

= we assume now consensus on the usage of YANG 1.1 features in current NETCONF WG items.

=  

= Regards,
Mehmet & Mahesh

=  

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (Nokia - DE/Munich)
Sent: Thursday, March 26, 20= 15 12:50 AM
To: netconf@ietf.org
Subject: [Netconf] The use o= f YANG 1.1 Features in NETCONF Drafts WAS: Summary and AIs from the NETCONF= Session in IETF #92

 

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

=  

= this email is to verif= y the opinion poll in IETF 92 NETCONF session concerning the use of YANG 1.1 Features in NETCONF Drafts.

=  

= As reported in the ses= sion summary below, the opinion poll for the use of YANG 1.1 features has been supported by 16 and disagreed by 1 person.

= The disagreement was b= ased on the assumption that the finalization of the YANG 1.1 draft may possibly take longer than currently expected.=

=  

= Please speak up by Apr= il 1, 2015 23:59 PT, if you have objections to use YANG 1.1 features in current NETCONF drafts.

= The co-chairs will dec= lare consensus after the deadline.

=  

= Regards,
Mehmet

=  

From: Netconf [mailto:netconf-bounce= s@ietf.org] On Behalf Of ext Ersue, Mehm= et (Nokia - DE/Munich)
Sent: Thursday, March 26, 20= 15 12:01 AM
To: Benoit Claise; netconf@ietf.org
Subject: [Netconf] Summary a= nd AIs from the NETCONF Session in IETF #92

 

Hi Benoit, NETCONF WG,<= /o:p>

 

below is a summary and actio= n items from the NETCONF WG session on March 24, 2014, Dallas, USA.

A Wiki version of this summa= ry will be made available at OPS area Wiki page soon (at htt= p://trac.tools.ietf.org/area/ops/trac/wiki/IETF92summary).

 

- We had approx. 90+ par= ticipants in the 2 hour NETCONF session,

- We had a discussion on 7 c= hartered documents.

 

- Note taker was: Lada Lhotk= a. The Jabber scribe was Mikael Abrahamsson.

Many thanks to the note take= rs and jabber scribe for volunteering.

 

 

Following is a summary of th= e discussion and the decisions taken per show-hands.

If there is no strong object= ion we will implement as proposed.

 

·Issues= after the WGLC of the RESTCONF and YANG Patch drafts have been discussed. See https://www.ietf.org/proceedings/92/slides/slides-92-netconf-0.pdf and = https://www.ietf.org/proceedings/92/slides/slides-92-netconf-1.pdf.

·Curren= tly open issues for the YANG Library and RESTCONF Collection Resource drafts have been discussed. See https://www.ietf.org/proceedings/92/slides/slides-92-netconf-10.pdf and= https://www.ietf.org/proceedings/92/slides/slides-92-netconf-11.pdf.

·A few = issues are remaining and will be taken to the maillist. If there is no objection, the solution described on an issue slide will be realized as= proposed. WG members are asked to speak up on the maillist if there is any= concern on the proposed solution.

·RESTCO= NF, YANG Patch and YANG Library drafts will go to 2nd WGLC a few weeks after IETF 92 once the drafts are available after issue solving.

·WG co-= chairs are asking the chairs of related WGs (e.g. Core, 6lo, 6tisch) to assign individuals as reviewer.

=  

·Issues= after the WGLC of the Call Home and Server Model drafts have been discusse= d. See https://www.ietf.org/proceedings/92/slides/slides-92-netconf-4.pptx and= https://www.ietf.org/proceedings/92/slides/slides-92-netconf-5.pptx.

·If the= re is no objection, the solution described on an issue slide will be realized as proposed. WG members are asked to speak up on the maillist if = there is any concern on the proposed solution.

·Call H= ome and Server Model drafts will go to 2nd WGLC once the drafts are available after issue solving and after finalizing the WGLC for the RESTCO= NF drafts.

 

·During= the discussion of the Server Model draft, the use of the YANG 1.1 features in current NETCONF drafts has been proposed. The opinion poll showed 16 ye= s, 1 no from Andy B.

·AI: Co= -chairs will send an email to the NETCONF maillist to verify the poll in the meeting.

·The op= en issues in Zerotouch draft have been discussed briefly. See https://www.ietf.org/proceedings/92/slides/slides-92-netconf-7.pptx. Kent W. is discussing the details of the requirements on Zerotouch draft= with ANIMA WG members. ANIMA WG is asked to agree on these requirements first in their WG before starting a d= iscussion in the NETCONF WG based on a new draft or subsection in an existi= ng draft.

 

·I2RS c= o-chair Jeff Haas summarized the NETCONF-related issues discussed in I”RS WG, which are Pub-sub requirements, Ephemeral state, Secondary = Identity, Priority, Transactions. See https://www.ietf.org/proceedings/92/slides/slides-92-netconf-8.pptx.

·Epheme= ral state is a particular issue important for I2RS WG. The volunteers for this issue (Dan B, Martin, Ken and Andy) will restart their work.=

·draft-= haas-i2rs-netmod-netconf-requirements is serving as a tracking document for I2RS protocol requirements. Current requirements on ephemeral state ar= e written down in the architecture draft.

·Mehmet= proposed a joint conf call to discuss the details of these issue in a joint conference call. AI: Mehmet to provide a doodle.=

 

·Eric V= oit presented on draft-ietf-i2rs-pub-sub-requirements-01. See https://www.ietf.org/proceedings/92/slides/slides-92-netconf-9.pdf.

·The re= lated solution draft addressing these requirements has been presented by Alex Clemm. See https://www.ietf.org/proceedings/92/slides/slides-92-netconf-14.pdf. Th= is draft is proposed to adopt in NETCONF WG. 12 have read the draft. 12 sup= port the draft and 0 against.

·Mehmet= clarified that new WG items can be adopted after finalizing current active items. This will be possibly in IETF 93 time frame.

 

·draft-= liu-netconf-multiple-replies-00 on Processing Multiple Replies for One Request in NETCONF has been presented by Guangying Zheng. See https://www.ietf.org/proceedings/92/slides/slides-92-netconf-3.ppt. 5 p= eople have read the draft. 5 support adopting the draft. Will take it to th= e mailing list.

·draft-= mm-netconf-time-capability-02 on Time Capability in NETCONF couldn’t be discussed due to lack of time. See https://www.ietf.org/proceedings/92/slides/slides-92-netconf-13.pdf.

·The ch= air suggested that both, draft-liu and draft-mm, should raise discussion on the maillist and get the support of the WG members.

=  

= Cheers,
Mehmet

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819679AF1DEMUMBX005nsnin_-- From nobody Thu Apr 2 03:32:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1051B2C4B for ; Thu, 2 Apr 2015 03:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igFh6QDNYOie for ; Thu, 2 Apr 2015 03:32:36 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63641B2C4A for ; Thu, 2 Apr 2015 03:32:35 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-b4-551d1ac14822 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.15.19337.1CA1D155; Thu, 2 Apr 2015 12:32:33 +0200 (CEST) Received: from [159.107.197.226] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.210.2; Thu, 2 Apr 2015 12:32:32 +0200 Message-ID: <551D1ABF.3000307@ericsson.com> Date: Thu, 2 Apr 2015 12:32:31 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Bjorklund References: <551C1FF4.30302@ericsson.com> <551D07F7.3060206@ericsson.com> <20150402.112038.363779998942540751.mbj@tail-f.com> In-Reply-To: <20150402.112038.363779998942540751.mbj@tail-f.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvje5BKdlQg88nhSweHJnFbtHd/Yzd Yuqm26wOzB5Llvxk8tj4azGLR0v/RZYA5igum5TUnMyy1CJ9uwSujGk/+9kKLrBWnL2yirGB cRlLFyMnh4SAicSle/fZIGwxiQv31gPZXBxCAkcZJRY0H2CBcNYwStw+/Yi1i5GDg1dAW2LH H7BmFgEViefLfzOC2GwCRhJT+8+DxUUFoiR6/nSDDeUVEJQ4OfMJWFxEQFXiyc61YDazgI7E vNlrmEFsYQE3iS1Hb0EtPsQo8Wv2YrChnAIOEoc6lzKC7GUWsJd4sLUMoldeYvvbOWC9QgIa Eg8v/GWdwCg4C8m6WQgds5B0LGBkXsUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGMAHt/xW 3cF4+Y3jIUYBDkYlHt4Ht2RChVgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAaLJA6h7/JR41u253llsfX1yzXeazUVDfcv5kX/Gf914439l0vyj474qLq6oP T2BdrtDpeSc1OEHwyIlPsyIV/tUcFPZzdI5m/Vi10Hjnj83rNAJfnfxSzaAbUbLWN1HR8qPy /5M9Pnw3HkfdXGzhf6DKtnVa/ONuk8Sp94w8zXP1353e662cp8RSnJFoqMVcVJwIAF1YFOVB AgAA Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] YANG models in the RFC 6022 capabilites branch? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 10:32:37 -0000 Or maybe we could merge 6022 and the yang-library using a feature to separate schemas and the rest of 6022. Balazs On 2015-04-02 11:20, Martin Bjorklund wrote: > Balazs Lengyel wrote: >> This way a YANG module is visible in 3 places: RFC6022 schema branch, >> capabilities branch and the new yang-library module. Seems a bit >> excessive. > Well, a YANG 1.1 module wouldn't be present in the capabilities list. > > But maybe an update to 6022 should deprecate the schema list. > > > /martin > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Apr 2 06:54:15 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1F71A9031 for ; Thu, 2 Apr 2015 06:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMbc9svBIycD for ; Thu, 2 Apr 2015 06:54:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47131A9048 for ; Thu, 2 Apr 2015 06:54:12 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-df-551d4a02527c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 28.5C.19337.20A4D155; Thu, 2 Apr 2015 15:54:11 +0200 (CEST) Received: from [159.107.197.226] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.210.2; Thu, 2 Apr 2015 15:54:09 +0200 Message-ID: <551D4A01.9070403@ericsson.com> Date: Thu, 2 Apr 2015 15:54:09 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "netconf@ietf.org" Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+JvjS6zl2yowdlfLBZTN91mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsdjy1gKjjNVrG4+yNTA+Jaxi5GTQ0LAROLv1IssELaYxIV7 69lAbCGBo4wS25pquxi5gOw1jBLXF54DK+IV0JZ4caIXrJlFQEViY8c0sDibgJHE1P7zYLao QJREz59uNoh6QYmTM5+AxUUENCUaZ31g7WLk4BAGmnPwlj5ImFnAQmLm/POMELa8xPa3c5gh btCQeHjhL+sERr5ZSCbNQtIyC0nLAkbmVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBAXVw y2/VHYyX3zgeYhTgYFTi4X1wSyZUiDWxrLgy9xCjNAeLkjivnfGhECGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MUxps+Y68urTRVzVdv0k8fddDtSdrH/JnatzPEnkhkackzMHEb+9763/C w6bLraf/VXg/SL7hdIt7+fO7ipOuG7EqdL+8dta5K9JS8tY65oD5rpvVzteYFCYcPDJn88+t pxYLJ2qGShSE+uQENvbuimXwOyK8SvX5rueHFiv6bYnNf+zbu7VHiaU4I9FQi7moOBEASZc4 aQkCAAA= Archived-At: Subject: [Netconf] Entity tags, timestamps in Netconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 13:54:14 -0000 Hello, Would it be interesting to show the entity tags and timestamp (from Restconf) over Netconf as well? It would be very seful. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Apr 2 07:52:56 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D941A9129 for ; Thu, 2 Apr 2015 07:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BacdAVblzzk8 for ; Thu, 2 Apr 2015 07:52:54 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0A11A044D for ; Thu, 2 Apr 2015 07:52:54 -0700 (PDT) Received: by lajy8 with SMTP id y8so61760382laj.0 for ; Thu, 02 Apr 2015 07:52:52 -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=yBURzrzlURXauB8Yd3FXHz3hIiBg7wMuztPV8VAbh08=; b=lGYyAX3Gge942Pmai6gmWWcBQVpxb6lbejeeq6I8eNFjr6j3omfxuTX08CHJsoA/NY G+zQt8Yz8up1nSCcbAWzEgJqPqojs1rwkyJlIn5yEwgwkUFR7pMKnUV4CkjELb2z+Mht /kIkLpakYtoSSEKVpd/d/VLd33k7MDW2d12brKLACHcyMFb32+ZpQd0IO9ul5Ai3Fsyx rW6POq7W4ruTfeCHDkRujuNs7jl412mnSjtA6qOkR78Fjy7tt260vXKlpFfxSjC6jzHn Riy7PW/acc8HZBVVKdY3pb1qWAKHDvl5jkV/zZFfu4pj4WPnNIg2KbI/xOS5CLvrVsjp 6FKg== X-Gm-Message-State: ALoCoQkyQKgnbQUjHIbscB34U/sEOa2DuL2Kbv/brxu1SSH/1dg1tZ4ZnRtr6YRK1l6gp/BArWVD MIME-Version: 1.0 X-Received: by 10.152.1.194 with SMTP id 2mr41168622lao.38.1427986372372; Thu, 02 Apr 2015 07:52:52 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 2 Apr 2015 07:52:52 -0700 (PDT) In-Reply-To: <551D4A01.9070403@ericsson.com> References: <551D4A01.9070403@ericsson.com> Date: Thu, 2 Apr 2015 07:52:52 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Entity tags, timestamps in Netconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 14:52:56 -0000 Hi, NETCONF-EX (now expired) had entity-tags, if-match on the operation, etc. I imagine once it is clear how RESTCONF leap-frogged NETCONF that some people might want NETCONF to catch up. Andy On Thu, Apr 2, 2015 at 6:54 AM, Balazs Lengyel wrote: > Hello, > Would it be interesting to show the entity tags and timestamp (from > Restconf) over Netconf as well? It would be very seful. > regards Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Apr 2 08:00:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16BD1B2CA8 for ; Thu, 2 Apr 2015 08:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7wpVVcAs93R for ; Thu, 2 Apr 2015 08:00:56 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268F81B2C8D for ; Thu, 2 Apr 2015 08:00:56 -0700 (PDT) Received: by lbdc10 with SMTP id c10so61224200lbd.2 for ; Thu, 02 Apr 2015 08:00:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=oU+poVIxsNuFkYWyMY501Wd9P5YSdXaicX3LS1Xu/HQ=; b=OBBMcupmzwQm80HBRfDzdzB82aPQ03K0PR2vdJTokO5Pj+jHpz3jHDjFUXkfatwfiY FPX9m93eOtPmd6eL9MkucQpkRr+qRuy/kngFC/ws/jhBD9iEulZT3TyIf9J3EU6msVvw 6YCj0NEsy82GsHzo2mjTh0nTtgJspu6KCQCsU/L8h4K5NIUYfvYEeXK8Gr5vxt/5pPf+ gNIW0qsqfQkdo5qxS9OvoO7TbBYNREO2wFsi5z/34Wjq4zDaXkSLnOmyUbOY2bzuTAs5 h2aJM9yGaqxX8bjNnYPwByu6ScnLKok98VIYMCWMChfDHxbK3T+dpZR/CRRJqpzfh1NS 8Ovw== X-Gm-Message-State: ALoCoQkWZxpuDUBjfT61lYQ060qyh6o/XSzl/ob7Q2ZmH3kF+4UD9g9BYwTCiHlUm4sNhzNYS67n MIME-Version: 1.0 X-Received: by 10.113.4.105 with SMTP id cd9mr39909023lbd.38.1427986854511; Thu, 02 Apr 2015 08:00:54 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 2 Apr 2015 08:00:54 -0700 (PDT) Date: Thu, 2 Apr 2015 08:00:54 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] rename operation for YANG Patch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:00:58 -0000 Hi, It would be very easy to add a "rename" operation to the YANG Patch draft. This would allow an operator to efficiently change the value of list keys without deleting and re-creating entries. Since deletion and re-creation will cause a disruption in network services, IMO it is important that this is fixed in RESTCONF. Unlike NETCONF (which has a multi-step procedure with locking and candidate config) there is no way to efficiently rename an entry in RESTCONF. The 'move' operation almost does a 'rename', but it is not expected to have a payload. A 'rename' operation would be similar to 'move' except the keys that are changing would be specified. Is there support to add this operation to YANG Patch? Andy From nobody Thu Apr 2 09:20:18 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E270B1B2D3D for ; Thu, 2 Apr 2015 09:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLbikFFKdn3Z for ; Thu, 2 Apr 2015 09:20:15 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 71B0A1B2D44 for ; Thu, 2 Apr 2015 09:20:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=YyVr58LOt0k+E7WZL6ITRpWsqT5PLYcQWKDWdXyMBFdmmvWDqidC99HdFJicL5xh; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Ydhqp-0004rh-3l for netconf@ietf.org; Thu, 02 Apr 2015 12:20:15 -0400 Received: from 76.254.55.210 by webmail.earthlink.net with HTTP; Thu, 2 Apr 2015 12:20:14 -0400 Message-ID: <7837927.1427991615136.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 09:20:14 -0700 (GMT-07:00) From: Randy Presuhn To: Netconf Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f891153775ed08a8806c7f31039e4b82d61cc82f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Archived-At: Subject: Re: [Netconf] rename operation for YANG Patch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:20:17 -0000 Hi - Care to be more specific about referential integrity, both within the managed system and external references to the entry in question? Randy -----Original Message----- >From: Andy Bierman >Sent: Apr 2, 2015 8:00 AM >To: Netconf >Subject: [Netconf] rename operation for YANG Patch > >Hi, > >It would be very easy to add a "rename" operation to the YANG Patch >draft. This would allow an operator to efficiently change the value >of list keys without deleting and re-creating entries. > >Since deletion and re-creation will cause a disruption in network >services, IMO it is important that this is fixed in RESTCONF. >Unlike NETCONF (which has a multi-step procedure with >locking and candidate config) there is no way to efficiently >rename an entry in RESTCONF. > >The 'move' operation almost does a 'rename', but it is not expected >to have a payload. A 'rename' operation would be similar to 'move' >except the keys that are changing would be specified. > > >Is there support to add this operation to YANG Patch? > > >Andy > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Apr 2 09:56:07 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C521ACE83 for ; Thu, 2 Apr 2015 09:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4in8OmhuGvpl for ; Thu, 2 Apr 2015 09:56:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAD21ACE9E for ; Thu, 2 Apr 2015 09:55:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8D6EE1161; Thu, 2 Apr 2015 18:55:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TnUZfeHov8Tw; Thu, 2 Apr 2015 18:55:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Apr 2015 18:55:41 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC8E320013; Thu, 2 Apr 2015 18:55:41 +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 kL6cPT9uEmsj; Thu, 2 Apr 2015 18:55:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D22D82002B; Thu, 2 Apr 2015 18:55:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D869732A71B7; Thu, 2 Apr 2015 18:55:39 +0200 (CEST) Date: Thu, 2 Apr 2015 18:55:39 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20150402165539.GA79774@elstar.local> Mail-Followup-To: Randy Presuhn , Netconf References: <7837927.1427991615136.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7837927.1427991615136.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] rename operation for YANG Patch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:56:07 -0000 I expect that the configuration datastore must validate as usual and this implies that all leafrefs etc. are valid. There is no difference between 'delete foo; create bar' and 'rename foo to bar' in this respect. /js On Thu, Apr 02, 2015 at 09:20:14AM -0700, Randy Presuhn wrote: > Hi - > > Care to be more specific about referential integrity, > both within the managed system and external references > to the entry in question? > > Randy > > -----Original Message----- > >From: Andy Bierman > >Sent: Apr 2, 2015 8:00 AM > >To: Netconf > >Subject: [Netconf] rename operation for YANG Patch > > > >Hi, > > > >It would be very easy to add a "rename" operation to the YANG Patch > >draft. This would allow an operator to efficiently change the value > >of list keys without deleting and re-creating entries. > > > >Since deletion and re-creation will cause a disruption in network > >services, IMO it is important that this is fixed in RESTCONF. > >Unlike NETCONF (which has a multi-step procedure with > >locking and candidate config) there is no way to efficiently > >rename an entry in RESTCONF. > > > >The 'move' operation almost does a 'rename', but it is not expected > >to have a payload. A 'rename' operation would be similar to 'move' > >except the keys that are changing would be specified. > > > > > >Is there support to add this operation to YANG Patch? > > > > > >Andy > > > >_______________________________________________ > >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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 2 09:56:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF1C1ACEB5 for ; Thu, 2 Apr 2015 09:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BF3jkJYEoVx for ; Thu, 2 Apr 2015 09:56:32 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1C31ACE9E for ; Thu, 2 Apr 2015 09:56:31 -0700 (PDT) Received: by labe2 with SMTP id e2so64523896lab.3 for ; Thu, 02 Apr 2015 09:56:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/t6FiCMO6GJlI7u5GQSl9afOs8qQIVWRgRdEe/PWiuU=; b=KOUnbbwgi3XPt0vnxKxu3Dn6f5nlP4YtUtoNsoLgIb5Q0PlWP8DdP8WCSIfAc4VCFk 8r22PBNhHvuRMulMHPbr4/gt8so9y3TCBPe4UvfkAK07rCXheoWAVvTRrpzMLBWs5SjU cDRBI4juwLTPxmhqDMI2KoBirBwHJIb6UbtetT65cd5DfloEEXpy+NCRX2IMJtvIUQFB 8+/uLl+dO683DSPrnVx0i9IfXIXleuHEu+j9E9s15jwieG3e3LLGuqXfwI+eieSgBNUu CGtxFGJjaybcBU/fj3g+be1F3rGOtC5J9BF6NoFF17g4+HIatYgbFZedBYZm6ZLJUCDs 4tWw== X-Gm-Message-State: ALoCoQk+uL0+JvAXvpE2DpzHmXxPY47lGi+SA0o5LRtHILc3yKSl1l5AqLLgH5OVB6TZLpB4sKs8 MIME-Version: 1.0 X-Received: by 10.112.42.164 with SMTP id p4mr41013649lbl.119.1427993790403; Thu, 02 Apr 2015 09:56:30 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 2 Apr 2015 09:56:30 -0700 (PDT) In-Reply-To: <7837927.1427991615136.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <7837927.1427991615136.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 09:56:30 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] rename operation for YANG Patch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:56:34 -0000 On Thu, Apr 2, 2015 at 9:20 AM, Randy Presuhn wrote: > Hi - > > Care to be more specific about referential integrity, > both within the managed system and external references > to the entry in question? > Actually, this is the only solution proposal that is explicit about renaming list instances. If the entry is renamed by deleting and re-creating it, then there is no way for an application to correlate the old name and new name. The server does not even know there is any correlation between the old name and the new name. But if there is a notification for a "rename event" then the applications would have something to use for an automatic mapping. > Randy Andy > > -----Original Message----- >>From: Andy Bierman >>Sent: Apr 2, 2015 8:00 AM >>To: Netconf >>Subject: [Netconf] rename operation for YANG Patch >> >>Hi, >> >>It would be very easy to add a "rename" operation to the YANG Patch >>draft. This would allow an operator to efficiently change the value >>of list keys without deleting and re-creating entries. >> >>Since deletion and re-creation will cause a disruption in network >>services, IMO it is important that this is fixed in RESTCONF. >>Unlike NETCONF (which has a multi-step procedure with >>locking and candidate config) there is no way to efficiently >>rename an entry in RESTCONF. >> >>The 'move' operation almost does a 'rename', but it is not expected >>to have a payload. A 'rename' operation would be similar to 'move' >>except the keys that are changing would be specified. >> >> >>Is there support to add this operation to YANG Patch? >> >> >>Andy >> >>_______________________________________________ >>Netconf mailing list >>Netconf@ietf.org >>https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Apr 2 09:57:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BCE1A92DC for ; Thu, 2 Apr 2015 09:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFKwRA773lPH for ; Thu, 2 Apr 2015 09:57:24 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608411ACD9F for ; Thu, 2 Apr 2015 09:57:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 336E2125D; Thu, 2 Apr 2015 18:57:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fiyyLBiM04aN; Thu, 2 Apr 2015 18:56:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Apr 2015 18:57:08 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67BC62002B; Thu, 2 Apr 2015 18:57:08 +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 JGk1opW9sati; Thu, 2 Apr 2015 18:57:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B09D20013; Thu, 2 Apr 2015 18:57:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 411CA32A71EB; Thu, 2 Apr 2015 18:57:07 +0200 (CEST) Date: Thu, 2 Apr 2015 18:57:07 +0200 From: Juergen Schoenwaelder To: Randy Presuhn , Netconf Message-ID: <20150402165707.GB79774@elstar.local> Mail-Followup-To: Randy Presuhn , Netconf References: <7837927.1427991615136.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> <20150402165539.GA79774@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150402165539.GA79774@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [Netconf] rename operation for YANG Patch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:57:26 -0000 The other possible interpretation would be rename foo to bar and update all references in the datastore accordingly. I am not sure this is what Andy had in mind. On Thu, Apr 02, 2015 at 06:55:39PM +0200, Juergen Schoenwaelder wrote: > I expect that the configuration datastore must validate as usual and > this implies that all leafrefs etc. are valid. There is no difference > between 'delete foo; create bar' and 'rename foo to bar' in this > respect. > > /js > > On Thu, Apr 02, 2015 at 09:20:14AM -0700, Randy Presuhn wrote: > > Hi - > > > > Care to be more specific about referential integrity, > > both within the managed system and external references > > to the entry in question? > > > > Randy > > > > -----Original Message----- > > >From: Andy Bierman > > >Sent: Apr 2, 2015 8:00 AM > > >To: Netconf > > >Subject: [Netconf] rename operation for YANG Patch > > > > > >Hi, > > > > > >It would be very easy to add a "rename" operation to the YANG Patch > > >draft. This would allow an operator to efficiently change the value > > >of list keys without deleting and re-creating entries. > > > > > >Since deletion and re-creation will cause a disruption in network > > >services, IMO it is important that this is fixed in RESTCONF. > > >Unlike NETCONF (which has a multi-step procedure with > > >locking and candidate config) there is no way to efficiently > > >rename an entry in RESTCONF. > > > > > >The 'move' operation almost does a 'rename', but it is not expected > > >to have a payload. A 'rename' operation would be similar to 'move' > > >except the keys that are changing would be specified. > > > > > > > > >Is there support to add this operation to YANG Patch? > > > > > > > > >Andy > > > > > >_______________________________________________ > > >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 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 2 10:00:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601DC1ACE1F for ; Thu, 2 Apr 2015 10:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzUZVMquUjND for ; Thu, 2 Apr 2015 10:00:15 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8128A1ACE0C for ; Thu, 2 Apr 2015 10:00:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Nmj1cbEKASCTKG3hGYQYkGFlA0maitoSHWwFXFDBYpD1X38H2f1Vn5Xz4P19x4dk; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YdiTW-00020O-PH; Thu, 02 Apr 2015 13:00:14 -0400 Received: from 76.254.55.210 by webmail.earthlink.net with HTTP; Thu, 2 Apr 2015 13:00:13 -0400 Message-ID: <14874250.1427994014748.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 10:00:13 -0700 (GMT-07:00) From: Randy Presuhn To: Juergen Schoenwaelder Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f891153720ea4684a5e6ca00869ea4b4c61f3821350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Archived-At: Cc: Netconf Subject: Re: [Netconf] rename operation for YANG Patch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 17:00:17 -0000 Hi - So bundled up for *simultaneous* execution with the rename request would also have to be the edits for all the relevant leafrefs?? Randy -----Original Message----- >From: Juergen Schoenwaelder >Sent: Apr 2, 2015 9:55 AM >To: Randy Presuhn >Cc: Netconf >Subject: Re: [Netconf] rename operation for YANG Patch > >I expect that the configuration datastore must validate as usual and >this implies that all leafrefs etc. are valid. There is no difference >between 'delete foo; create bar' and 'rename foo to bar' in this >respect. > >/js > >On Thu, Apr 02, 2015 at 09:20:14AM -0700, Randy Presuhn wrote: >> Hi - >> >> Care to be more specific about referential integrity, >> both within the managed system and external references >> to the entry in question? >> >> Randy >> >> -----Original Message----- >> >From: Andy Bierman >> >Sent: Apr 2, 2015 8:00 AM >> >To: Netconf >> >Subject: [Netconf] rename operation for YANG Patch >> > >> >Hi, >> > >> >It would be very easy to add a "rename" operation to the YANG Patch >> >draft. This would allow an operator to efficiently change the value >> >of list keys without deleting and re-creating entries. >> > >> >Since deletion and re-creation will cause a disruption in network >> >services, IMO it is important that this is fixed in RESTCONF. >> >Unlike NETCONF (which has a multi-step procedure with >> >locking and candidate config) there is no way to efficiently >> >rename an entry in RESTCONF. >> > >> >The 'move' operation almost does a 'rename', but it is not expected >> >to have a payload. A 'rename' operation would be similar to 'move' >> >except the keys that are changing would be specified. >> > >> > >> >Is there support to add this operation to YANG Patch? >> > >> > >> >Andy >> > >> >_______________________________________________ >> >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 > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Apr 2 10:04:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE841ACEB8 for ; Thu, 2 Apr 2015 10:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3uU_bh9caH7 for ; Thu, 2 Apr 2015 10:04:27 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3031ACEBD for ; Thu, 2 Apr 2015 10:04:27 -0700 (PDT) Received: by lbbug6 with SMTP id ug6so63983943lbb.3 for ; Thu, 02 Apr 2015 10:04:26 -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=Q70qCvbiuaq3LQi0YlqE9QJ6x39KSFXd8u+u2cBIwIw=; b=AzJ7wvsTo2Xl+DFGwjRKZJs2VVLgHCW3b7OSv3vVMmUnujT11dLXcrp6b4lanlG8YX Z+jTwQ5iEV10eWRbainyVSiDYKMDIEKYOUqepAJcJKdaHiXfaY84F/YqCP+icWs0zg5Z xZycEZx4pD0jhZfCZQWkZE1PcafjHgpS+hgH4GDkW3sVS+nImya28RY2zO1rMKyp97Ni DPmhjPwbzfGGhX4NZAUHXc8pfG2OzjCs7O9MMutik/8NFn/yA9aOfRQ/Zvx3A3WMqhLN 67ZLnwJkosnfcML+GFLL7PpEoFXHJigFCqlyc053gihfYuVrG/fCeY9vucj/H8wpW4XJ yQNw== X-Gm-Message-State: ALoCoQlXl9MTX8pFbR/aUVSfwUVC7TjM4VZllSBeOtwvsNOkaDxI2/Y2YKgl8vo6kUkC4HTQmaSW MIME-Version: 1.0 X-Received: by 10.152.115.173 with SMTP id jp13mr7844517lab.119.1427994265997; Thu, 02 Apr 2015 10:04:25 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 2 Apr 2015 10:04:25 -0700 (PDT) In-Reply-To: <14874250.1427994014748.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> References: <14874250.1427994014748.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Thu, 2 Apr 2015 10:04:25 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] rename operation for YANG Patch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 17:04:29 -0000 On Thu, Apr 2, 2015 at 10:00 AM, Randy Presuhn wrote: > Hi - > > So bundled up for *simultaneous* execution with the rename request > would also have to be the edits for all the relevant leafrefs?? > Only if the leafref pointed at a key leaf. As Juergen pointed out, it is no different than deleting the key leaf so the leafref is now invalid. Either way the leafref has to get set to the new value. > Randy Andy > > > -----Original Message----- >>From: Juergen Schoenwaelder >>Sent: Apr 2, 2015 9:55 AM >>To: Randy Presuhn >>Cc: Netconf >>Subject: Re: [Netconf] rename operation for YANG Patch >> >>I expect that the configuration datastore must validate as usual and >>this implies that all leafrefs etc. are valid. There is no difference >>between 'delete foo; create bar' and 'rename foo to bar' in this >>respect. >> >>/js >> >>On Thu, Apr 02, 2015 at 09:20:14AM -0700, Randy Presuhn wrote: >>> Hi - >>> >>> Care to be more specific about referential integrity, >>> both within the managed system and external references >>> to the entry in question? >>> >>> Randy >>> >>> -----Original Message----- >>> >From: Andy Bierman >>> >Sent: Apr 2, 2015 8:00 AM >>> >To: Netconf >>> >Subject: [Netconf] rename operation for YANG Patch >>> > >>> >Hi, >>> > >>> >It would be very easy to add a "rename" operation to the YANG Patch >>> >draft. This would allow an operator to efficiently change the value >>> >of list keys without deleting and re-creating entries. >>> > >>> >Since deletion and re-creation will cause a disruption in network >>> >services, IMO it is important that this is fixed in RESTCONF. >>> >Unlike NETCONF (which has a multi-step procedure with >>> >locking and candidate config) there is no way to efficiently >>> >rename an entry in RESTCONF. >>> > >>> >The 'move' operation almost does a 'rename', but it is not expected >>> >to have a payload. A 'rename' operation would be similar to 'move' >>> >except the keys that are changing would be specified. >>> > >>> > >>> >Is there support to add this operation to YANG Patch? >>> > >>> > >>> >Andy >>> > >>> >_______________________________________________ >>> >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 >> >>-- >>Juergen Schoenwaelder Jacobs University Bremen gGmbH >>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>Fax: +49 421 200 3103 >> >>_______________________________________________ >>Netconf mailing list >>Netconf@ietf.org >>https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Sun Apr 5 09:02:45 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897911A1B39; Sat, 4 Apr 2015 17:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciuRE5FKckGy; Sat, 4 Apr 2015 17:55:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 463E11A1B2E; Sat, 4 Apr 2015 17:55:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150405005556.29041.96505.idtracker@ietfa.amsl.com> Date: Sat, 04 Apr 2015 17:55:56 -0700 Archived-At: X-Mailman-Approved-At: Sun, 05 Apr 2015 09:02:45 -0700 Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org Subject: [Netconf] Kathleen Moriarty's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 00:55:57 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-netconf-rfc5539bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I found the discussion on the SecDir review interesting, so thanks for the more detailed explanations. I do agree that the draft already does state that this is a certificate fingerprint, but don't see (maybe point me to where it is if I missed it), that this is all local, per: https://www.ietf.org/mail-archive/web/secdir/current/msg05526.html I'm wondering why the yang model that was spilt out into another draft isn't referenced as that would be helpful as well (last 2 paragraphs of Tom's response): https://www.ietf.org/mail-archive/web/secdir/current/msg05524.html This is non blocking as I'd like to figure out if it's helpful to avoid questions and link drafts where appropriate (unless I missed something). Thanks, Kathleen From nobody Sun Apr 5 09:04:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D911A88A1 for ; Sun, 5 Apr 2015 09:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf398hTy-myC for ; Sun, 5 Apr 2015 09:04:47 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8021A8889 for ; Sun, 5 Apr 2015 09:04:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t35G4iek014718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 5 Apr 2015 16:04:44 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t35G4hLh030697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 5 Apr 2015 18:04:44 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 5 Apr 2015 18:04:43 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.118]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0224.002; Sun, 5 Apr 2015 18:04:43 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Kathleen Moriarty's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) Thread-Index: AQHQbztLIRBb0XcM50+SmFZyd1By650+le6g Date: Sun, 5 Apr 2015 16:04:42 +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.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2674 X-purgate-ID: 151667::1428249885-0000328B-BBD9BBD0/0/0 Archived-At: Subject: [Netconf] FW: Kathleen Moriarty's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2015 16:04:49 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEthdGhsZWVuIE1vcmlhcnR5IFttYWls dG86S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb21dIA0KU2VudDogU3VuZGF5LCBBcHJp bCAwNSwgMjAxNSAyOjU2IEFNDQpUbzogVGhlIElFU0cNCkNjOiBkcmFmdC1pZXRmLW5ldGNvbmYt cmZjNTUzOWJpc0BpZXRmLm9yZzsgbmV0Y29uZi1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt bmV0Y29uZi1yZmM1NTM5YmlzLmFkQGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUz OWJpcy5zaGVwaGVyZEBpZXRmLm9yZzsgRXJzdWUsIE1laG1ldCAoTm9raWEgLSBERS9NdW5pY2gp OyBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBLYXRobGVlbiBNb3JpYXJ0eSdzIE5vIE9iamVj dGlvbiBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpcy0wOTogKHdpdGggQ09NTUVOVCkN Cg0KS2F0aGxlZW4gTW9yaWFydHkgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9z aXRpb24gZm9yDQpkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpcy0wOTogTm8gT2JqZWN0aW9u DQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3Qg YW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwOi8vd3d3LmlldGYub3JnL2llc2cv c3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1yZmM1NTM5 YmlzLw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSSBm b3VuZCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgU2VjRGlyIHJldmlldyBpbnRlcmVzdGluZywgc28g dGhhbmtzIGZvcg0KdGhlIG1vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb25zLiAgSSBkbyBhZ3JlZSB0 aGF0IHRoZSBkcmFmdCBhbHJlYWR5IGRvZXMNCnN0YXRlIHRoYXQgdGhpcyBpcyBhIGNlcnRpZmlj YXRlIGZpbmdlcnByaW50LCBidXQgZG9uJ3Qgc2VlIChtYXliZSBwb2ludA0KbWUgdG8gd2hlcmUg aXQgaXMgaWYgSSBtaXNzZWQgaXQpLCB0aGF0IHRoaXMgaXMgYWxsIGxvY2FsLCBwZXI6DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50L21zZzA1NTI2 Lmh0bWwNCg0KSSdtIHdvbmRlcmluZyB3aHkgdGhlIHlhbmcgbW9kZWwgdGhhdCB3YXMgc3BpbHQg b3V0IGludG8gYW5vdGhlciBkcmFmdA0KaXNuJ3QgcmVmZXJlbmNlZCBhcyB0aGF0IHdvdWxkIGJl IGhlbHBmdWwgYXMgd2VsbCAobGFzdCAyIHBhcmFncmFwaHMgb2YNClRvbSdzIHJlc3BvbnNlKToN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNn MDU1MjQuaHRtbA0KDQpUaGlzIGlzIG5vbiBibG9ja2luZyBhcyBJJ2QgbGlrZSB0byBmaWd1cmUg b3V0IGlmIGl0J3MgaGVscGZ1bCB0byBhdm9pZA0KcXVlc3Rpb25zIGFuZCBsaW5rIGRyYWZ0cyB3 aGVyZSBhcHByb3ByaWF0ZSAodW5sZXNzIEkgbWlzc2VkIHNvbWV0aGluZykuDQoNClRoYW5rcywN CkthdGhsZWVuDQoNCg0K From nobody Mon Apr 6 04:36:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6730B1A87A5; Mon, 6 Apr 2015 04:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPVjtjOJQaNR; Mon, 6 Apr 2015 04:36:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D421A87AE; Mon, 6 Apr 2015 04:35:59 -0700 (PDT) Received: from pc6 (81.151.162.168) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.125.19; Mon, 6 Apr 2015 11:35:42 +0000 Message-ID: <010501d0705d$aa14be60$4001a8c0@gateway.2wire.net> From: t.petch To: Kathleen Moriarty , The IESG References: <20150405005556.29041.96505.idtracker@ietfa.amsl.com> Date: Mon, 6 Apr 2015 12:33:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB3PR05CA0052.eurprd05.prod.outlook.com (25.160.41.180) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(164054003)(377454003)(92566002)(40100003)(77096005)(66066001)(15975445007)(50226001)(1456003)(62966003)(77156002)(61296003)(87976001)(122386002)(47776003)(50466002)(230783001)(46102003)(86362001)(50986999)(33646002)(19580405001)(42186005)(23756003)(44716002)(76176999)(81686999)(84392001)(81816999)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DBXPR07MB061; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB061; X-Forefront-PRVS: 0538A71254 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2015 11:35:42.9852 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB061 Archived-At: Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org Subject: Re: [Netconf] Kathleen Moriarty's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 11:36:03 -0000 ----- Original Message ----- From: "Kathleen Moriarty" To: "The IESG" Cc: ; ; ; ; ; Sent: Sunday, April 05, 2015 1:55 AM > Kathleen Moriarty has entered the following ballot position for > draft-ietf-netconf-rfc5539bis-09: No Objection > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I found the discussion on the SecDir review interesting, so thanks for > the more detailed explanations. I do agree that the draft already does > state that this is a certificate fingerprint, but don't see (maybe point > me to where it is if I missed it), that this is all local, per: > https://www.ietf.org/mail-archive/web/secdir/current/msg05526.html > > I'm wondering why the yang model that was spilt out into another draft > isn't referenced as that would be helpful as well (last 2 paragraphs of > Tom's response): > https://www.ietf.org/mail-archive/web/secdir/current/msg05524.html > > This is non blocking as I'd like to figure out if it's helpful to avoid > questions and link drafts where appropriate (unless I missed something). Kathleen Yes. Perhaps Netconf and YANG is one of those areas which, if you have not followed the last 12 years of discussion, you never will quite understand:-( Netconf started out with SSH, SOAP and BEEP. It gained TLS, got reverse SSH, lost SOAP and BEEP, TLS added 'reverse', 'reverse' was renamed 'call home', it gained a Netconf server YANG model, TLS gained and lost a YANG model, it added RESTCONF and RESTCONF call home. Along the way, TLS gained and lost PSK while SSH acquired certificates. The current I-D structure was agreed in July 2014 and owes something to engineering, something to history! Currently it is netconf-5539bis, netconf-server-model, netconf-call-home, netconf-restconf and netconf-zerotouch (with a variety of authors, a variety of target completion dates and, perhaps, a wish to limit inter-dependencies). The issue of how to authenticate a client and derive an identifier for it is awkward and not often tackled in the IETF (which tends to be more concerned with server authentication and HTTP - this was an issue when adding SSH/TLS to SNMP, as well); and it cuts across TLS, SSH with certificates, call home and zero touch while its origins go back to isms (SNMP). I see no best place to put all the information nor is it easy to partition it. I had a break recently and when I came back to netconf-5539bis, misunderstood it, because, to my mind, the procedural description assumed an information model, and I had the wrong model in mind. Juergen put me straight, and clarified netconf-5539bis but I still had a lot of background knowledge which probably stopped me having more misunderstandings. So yes, a few more sentences could be helpful. I was, for example, surprised at the discussion on fingerprints since they have been that way since isms (SNMP) - for which Sam was security advisor - and had not thought of an alternative interpretation. Tom Petch > Thanks, > Kathleen > From nobody Mon Apr 6 06:12:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2321A888F for ; Mon, 6 Apr 2015 06:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44qrzxTwsnVf for ; Mon, 6 Apr 2015 06:12:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D451A888B for ; Mon, 6 Apr 2015 06:12:01 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t36DBxLo030275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Apr 2015 13:11:59 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t36DBxhE019637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Apr 2015 15:11:59 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 6 Apr 2015 15:11:58 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.118]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0224.002; Mon, 6 Apr 2015 15:11:58 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: [Netconf] Kathleen Moriarty's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) Thread-Index: AQHQcGVk5cYnJotCuUyPPDtjo5Bch50/9atw Date: Mon, 6 Apr 2015 13:11:57 +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.108] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81968929BDEMUMBX005nsnin_" 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: 46890 X-purgate-ID: 151667::1428325919-00007476-7B7ED068/0/0 Archived-At: Subject: [Netconf] FW: Kathleen Moriarty's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 13:12:10 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81968929BDEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogS2F0aGxlZW4gTW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt YWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgQXByaWwgMDYsIDIwMTUgMjozMCBQTQ0KVG86IHQucGV0 Y2gNCkNjOiBUaGUgSUVTRzsgZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzU1MzliaXNAaWV0Zi5vcmc7 IG5ldGNvbmYtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpcy5h ZEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzU1MzliaXMuc2hlcGhlcmRAaWV0Zi5v cmc7IEVyc3VlLCBNZWhtZXQgKE5va2lhIC0gREUvTXVuaWNoKTsgbmV0Y29uZkBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtOZXRjb25mXSBLYXRobGVlbiBNb3JpYXJ0eSdzIE5vIE9iamVjdGlvbiBv biBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpcy0wOTogKHdpdGggQ09NTUVOVCkNCg0KDQpP biBNb24sIEFwciA2LCAyMDE1IGF0IDc6MzMgQU0sIHQucGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5j b208bWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20+PiB3cm90ZToNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCkZyb206ICJLYXRobGVlbiBNb3JpYXJ0eSIgPEthdGhsZWVuLk1vcmlhcnR5 LmlldGZAZ21haWwuY29tPG1haWx0bzpLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+ DQpUbzogIlRoZSBJRVNHIiA8aWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+DQpD YzogPGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM1NTM5YmlzQGlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLW5ldGNvbmYtcmZjNTUzOWJpc0BpZXRmLm9yZz4+OyA8bmV0Y29uZi1jaGFpcnNAaWV0Zi5v cmc8bWFpbHRvOm5ldGNvbmYtY2hhaXJzQGlldGYub3JnPj47DQo8ZHJhZnQtaWV0Zi1uZXRjb25m LXJmYzU1MzliaXMuYWRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0Y29uZi1yZmM1NTM5 YmlzLmFkQGlldGYub3JnPj47DQo8ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzU1MzliaXMuc2hlcGhl cmRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbmV0Y29uZi1yZmM1NTM5YmlzLnNoZXBoZXJk QGlldGYub3JnPj47DQo8bWVobWV0LmVyc3VlQG5zbi5jb208bWFpbHRvOm1laG1ldC5lcnN1ZUBu c24uY29tPj47IDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClNl bnQ6IFN1bmRheSwgQXByaWwgMDUsIDIwMTUgMTo1NSBBTQ0KPiBLYXRobGVlbiBNb3JpYXJ0eSBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0 Zi1uZXRjb25mLXJmYzU1MzliaXMtMDk6IE5vIE9iamVjdGlvbg0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gSSBmb3VuZCB0aGUgZGlzY3Vzc2lvbiBv biB0aGUgU2VjRGlyIHJldmlldyBpbnRlcmVzdGluZywgc28gdGhhbmtzIGZvcg0KPiB0aGUgbW9y ZSBkZXRhaWxlZCBleHBsYW5hdGlvbnMuICBJIGRvIGFncmVlIHRoYXQgdGhlIGRyYWZ0IGFscmVh ZHkNCmRvZXMNCj4gc3RhdGUgdGhhdCB0aGlzIGlzIGEgY2VydGlmaWNhdGUgZmluZ2VycHJpbnQs IGJ1dCBkb24ndCBzZWUgKG1heWJlDQpwb2ludA0KPiBtZSB0byB3aGVyZSBpdCBpcyBpZiBJIG1p c3NlZCBpdCksIHRoYXQgdGhpcyBpcyBhbGwgbG9jYWwsIHBlcjoNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZWNkaXIvY3VycmVudC9tc2cwNTUyNi5odG1sDQo+DQo+ IEknbSB3b25kZXJpbmcgd2h5IHRoZSB5YW5nIG1vZGVsIHRoYXQgd2FzIHNwaWx0IG91dCBpbnRv IGFub3RoZXIgZHJhZnQNCj4gaXNuJ3QgcmVmZXJlbmNlZCBhcyB0aGF0IHdvdWxkIGJlIGhlbHBm dWwgYXMgd2VsbCAobGFzdCAyIHBhcmFncmFwaHMNCm9mDQo+IFRvbSdzIHJlc3BvbnNlKToNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZWNkaXIvY3VycmVudC9tc2cw NTUyNC5odG1sDQo+DQo+IFRoaXMgaXMgbm9uIGJsb2NraW5nIGFzIEknZCBsaWtlIHRvIGZpZ3Vy ZSBvdXQgaWYgaXQncyBoZWxwZnVsIHRvDQphdm9pZA0KPiBxdWVzdGlvbnMgYW5kIGxpbmsgZHJh ZnRzIHdoZXJlIGFwcHJvcHJpYXRlICh1bmxlc3MgSSBtaXNzZWQNCnNvbWV0aGluZykuDQpLYXRo bGVlbg0KDQpZZXMuDQoNClBlcmhhcHMgTmV0Y29uZiBhbmQgWUFORyBpcyBvbmUgb2YgdGhvc2Ug YXJlYXMgd2hpY2gsIGlmIHlvdSBoYXZlIG5vdA0KZm9sbG93ZWQgdGhlIGxhc3QgMTIgeWVhcnMg b2YgZGlzY3Vzc2lvbiwgeW91IG5ldmVyIHdpbGwgcXVpdGUNCnVuZGVyc3RhbmQ6LSgNCg0KTmV0 Y29uZiBzdGFydGVkIG91dCB3aXRoIFNTSCwgU09BUCBhbmQgQkVFUC4gIEl0IGdhaW5lZCBUTFMs IGdvdCByZXZlcnNlDQpTU0gsIGxvc3QgU09BUCBhbmQgQkVFUCwgVExTIGFkZGVkICdyZXZlcnNl JywgJ3JldmVyc2UnIHdhcyByZW5hbWVkDQonY2FsbCBob21lJywgaXQgZ2FpbmVkIGEgTmV0Y29u ZiBzZXJ2ZXIgWUFORyBtb2RlbCwgVExTIGdhaW5lZCBhbmQgbG9zdA0KYSBZQU5HIG1vZGVsLCBp dCBhZGRlZCBSRVNUQ09ORiBhbmQgUkVTVENPTkYgY2FsbCBob21lLiAgQWxvbmcgdGhlIHdheSwN ClRMUyBnYWluZWQgYW5kIGxvc3QgUFNLIHdoaWxlIFNTSCBhY3F1aXJlZCBjZXJ0aWZpY2F0ZXMu DQoNClRoZSBjdXJyZW50IEktRCBzdHJ1Y3R1cmUgd2FzIGFncmVlZCBpbiBKdWx5IDIwMTQgYW5k IG93ZXMgc29tZXRoaW5nIHRvDQplbmdpbmVlcmluZywgc29tZXRoaW5nIHRvIGhpc3RvcnkhICBD dXJyZW50bHkgaXQgaXMgbmV0Y29uZi01NTM5YmlzLA0KbmV0Y29uZi1zZXJ2ZXItbW9kZWwsIG5l dGNvbmYtY2FsbC1ob21lLCBuZXRjb25mLXJlc3Rjb25mIGFuZA0KbmV0Y29uZi16ZXJvdG91Y2gg KHdpdGggYSB2YXJpZXR5IG9mIGF1dGhvcnMsIGEgdmFyaWV0eSBvZiB0YXJnZXQNCmNvbXBsZXRp b24gZGF0ZXMgYW5kLCBwZXJoYXBzLCBhIHdpc2ggdG8gbGltaXQgaW50ZXItZGVwZW5kZW5jaWVz KS4NCg0KVGhlIGlzc3VlIG9mIGhvdyB0byBhdXRoZW50aWNhdGUgYSBjbGllbnQgYW5kIGRlcml2 ZSBhbiBpZGVudGlmaWVyIGZvcg0KaXQgaXMgYXdrd2FyZCBhbmQgbm90IG9mdGVuIHRhY2tsZWQg aW4gdGhlIElFVEYgKHdoaWNoIHRlbmRzIHRvIGJlIG1vcmUNCmNvbmNlcm5lZCB3aXRoIHNlcnZl ciBhdXRoZW50aWNhdGlvbiBhbmQgSFRUUCAtIHRoaXMgd2FzIGFuIGlzc3VlIHdoZW4NCmFkZGlu ZyBTU0gvVExTIHRvIFNOTVAsIGFzIHdlbGwpOyBhbmQgaXQgY3V0cyBhY3Jvc3MgVExTLCBTU0gg d2l0aA0KY2VydGlmaWNhdGVzLCBjYWxsIGhvbWUgYW5kIHplcm8gdG91Y2ggd2hpbGUgaXRzIG9y aWdpbnMgZ28gYmFjayB0byBpc21zDQooU05NUCkuICBJIHNlZSBubyBiZXN0IHBsYWNlIHRvIHB1 dCBhbGwgdGhlIGluZm9ybWF0aW9uIG5vciBpcyBpdCBlYXN5DQp0byBwYXJ0aXRpb24gaXQuDQoN CkkgaGFkIGEgYnJlYWsgcmVjZW50bHkgYW5kIHdoZW4gSSBjYW1lIGJhY2sgdG8gbmV0Y29uZi01 NTM5YmlzLA0KbWlzdW5kZXJzdG9vZCBpdCwgYmVjYXVzZSwgdG8gbXkgbWluZCwgdGhlIHByb2Nl ZHVyYWwgZGVzY3JpcHRpb24NCmFzc3VtZWQgYW4gaW5mb3JtYXRpb24gbW9kZWwsIGFuZCBJIGhh ZCB0aGUgd3JvbmcgbW9kZWwgaW4gbWluZC4NCkp1ZXJnZW4gcHV0IG1lIHN0cmFpZ2h0LCBhbmQg Y2xhcmlmaWVkIG5ldGNvbmYtNTUzOWJpcyBidXQgSSBzdGlsbCBoYWQgYQ0KbG90IG9mIGJhY2tn cm91bmQga25vd2xlZGdlIHdoaWNoIHByb2JhYmx5IHN0b3BwZWQgbWUgaGF2aW5nIG1vcmUNCm1p c3VuZGVyc3RhbmRpbmdzLg0KDQpTbyB5ZXMsIGEgZmV3IG1vcmUgc2VudGVuY2VzIGNvdWxkIGJl IGhlbHBmdWwuICBJIHdhcywgZm9yIGV4YW1wbGUsDQpzdXJwcmlzZWQgYXQgdGhlIGRpc2N1c3Np b24gb24gZmluZ2VycHJpbnRzIHNpbmNlIHRoZXkgaGF2ZSBiZWVuIHRoYXQNCndheSBzaW5jZSBp c21zIChTTk1QKSAtICBmb3Igd2hpY2ggU2FtIHdhcyBzZWN1cml0eSBhZHZpc29yIC0gYW5kIGhh ZA0Kbm90IHRob3VnaHQgb2YgYW4gYWx0ZXJuYXRpdmUgaW50ZXJwcmV0YXRpb24uDQoNClRoYW5r cywgVG9tISAgTGV0IG1lIGtub3cgd2hlbiBpdCdzIGJlZW4gZG9uZSBhbmQgSSdsbCBiZSBoYXBw eSB0byByZWFkIGl0IGFnYWluLg0KDQoNClRvbSBQZXRjaA0KDQo+IFRoYW5rcywNCj4gS2F0aGxl ZW4NCj4NCg0KDQoNCi0tDQoNCkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQo= --_000_E4DE949E6CE3E34993A2FF8AE79131F81968929BDEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDEyIj4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDEyIj4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDA3MDdDLjA2MDcxRjEwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8bzpUYXJnZXRTY3JlZW5TaXplPjEwMjR4NzY4PC9vOlRhcmdldFNjcmVlblNpemU+DQo8L286 T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpT cGVsbGluZ1N0YXRlPg0KPHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6 RW52ZWxvcGVWaXMvPg0KPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJ bnZhbGlkPmZhbHNlPC93OlNhdmVJZlhNTEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4 dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYv Pg0KPHc6TGlkVGhlbWVPdGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVB c2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5Y LU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRv Tm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0 UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkRvbnRWZXJ0QWxpZ25DZWxsV2l0aFNwLz4NCjx3OkRv bnRCcmVha0NvbnN0cmFpbmVkRm9yY2VkVGFibGVzLz4NCjx3OkRvbnRWZXJ0QWxpZ25JblR4Yngv Pg0KPHc6V29yZDExS2VybmluZ1BhaXJzLz4NCjx3OkNhY2hlZENvbEJhbGFuY2UvPg0KPC93OkNv bXBhdGliaWxpdHk+DQo8dzpCcm93c2VyTGV2ZWw+TWljcm9zb2Z0SW50ZXJuZXRFeHBsb3JlcjQ8 L3c6QnJvd3NlckxldmVsPg0KPG06bWF0aFByPg0KPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEg TWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCjxtOmJya0JpblN1YiBtOnZhbD0i JiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+DQo8bTps TWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpkZWZKYyBtOnZh bD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxtOmludExp bSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwvbTptYXRo UHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVmVW5oaWRl V2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3JtYXQ9ImZhbHNlIiBE ZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjI2NyI+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRv YyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1l PSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFtZT0iRGVm YXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8g U3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hh ZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJr IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNv bG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBM aXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGlu ZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg TGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0 IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAx IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3Qg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdy aWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hh ZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29s b3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUg RW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjEi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUi IE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1pSGlkZGVu PSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29r IFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM3IiBO YW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6TGF0ZW50 U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlv bnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1hbHQ6IkNhbGlzdG8gTVQiOw0KCW1z by1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28t Zm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3 MzA1NzI3IDAgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJUaW1lcyBOZXcg Um9tYW4iOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpz d2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUz Njg3MDE0NSAxMDczNzg2MTExIDEgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDsNCgltc28tZm9udC1hbHQ6 QXJpYWw7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3 aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTIw MDgxNjY1IC0xMDczNzE3MTU3IDQxIDAgNjYwNDcgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQt YWx0OlZlcmRhbmE7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFt aWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVy ZTotMTU5MzgzMzcyOSAxMDczNzUwMTA3IDE2IDAgNDE1IDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0 eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVu dDoiIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5h dGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRl eHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5N c29BY2V0YXRlDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28t c3R5bGUtbG9ja2VkOnllczsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCgltc28t YW5zaS1mb250LXNpemU6OC4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6VGFo b21hOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpUYWhvbWE7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6VGFob21hO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZvbnQtZmFt aWx5OlZlcmRhbmE7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6IzAwMDBDQzt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZGVmYXVsdC1wcm9w czp5ZXM7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDsNCgltc28taGVhZGVyLW1hcmdpbjozNi4wcHQ7DQoJbXNvLWZvb3Rlci1tYXJnaW46MzYu MHB0Ow0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+LyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1l OiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHls ZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7 DQoJbXNvLXBhZGRpbmctYWx0OjBjbSA1LjRwdCAwY20gNS40cHQ7DQoJbXNvLXBhcmEtbWFyZ2lu OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246 d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFu c2ktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9InRhYi1pbnRlcnZhbDoz Ni4wcHQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9t YSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwv Zm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPg0KIEthdGhsZWVuIE1vcmlhcnR5IFttYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBn bWFpbC5jb21dIDxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwv c3Bhbj48L2I+IE1vbmRheSwgQXByaWwgMDYsIDIwMTUgMjozMCBQTTxicj4NCjxiPjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiB0LnBldGNoPGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOjwvc3Bhbj48L2I+IFRoZSBJRVNHOyBkcmFm dC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpc0BpZXRmLm9yZzsgbmV0Y29uZi1jaGFpcnNAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtbmV0Y29uZi1yZmM1NTM5YmlzLmFkQGlldGYub3JnOyBkcmFmdC1pZXRm LW5ldGNvbmYtcmZjNTUzOWJpcy5zaGVwaGVyZEBpZXRmLm9yZzsgRXJzdWUsIE1laG1ldCAoTm9r aWEgLSBERS9NdW5pY2gpOyBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFtOZXRjb25mXSBLYXRobGVl biBNb3JpYXJ0eSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJp cy0wOTogKHdpdGggQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk9uIE1vbiwgQXByIDYsIDIwMTUgYXQgNzozMyBBTSwg dC5wZXRjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZjQGJ0Y29ubmVjdC5jb20iIHRhcmdldD0i X2JsYW5rIj5pZXRmY0BidGNvbm5lY3QuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tb3V0bGluZS1s ZXZlbDoxIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPg0KRnJv bTogJnF1b3Q7S2F0aGxlZW4gTW9yaWFydHkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpLYXRo bGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSI+S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFp bC5jb208L2E+Jmd0Ozxicj4NClRvOiAmcXVvdDtUaGUgSUVTRyZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkNjOiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbmV0Y29uZi1yZmM1NTM5YmlzQGlldGYub3JnIj5k cmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpc0BpZXRmLm9yZzwvYT4mZ3Q7OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5ldGNvbmYtY2hhaXJzQGlldGYub3JnIj5uZXRjb25mLWNoYWlyc0BpZXRmLm9y ZzwvYT4mZ3Q7Ozxicj4NCiZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1uZXRjb25mLXJm YzU1MzliaXMuYWRAaWV0Zi5vcmciPmRyYWZ0LWlldGYtbmV0Y29uZi1yZmM1NTM5YmlzLmFkQGll dGYub3JnPC9hPiZndDs7PGJyPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW5ldGNv bmYtcmZjNTUzOWJpcy5zaGVwaGVyZEBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzU1 MzliaXMuc2hlcGhlcmRAaWV0Zi5vcmc8L2E+Jmd0Ozs8YnI+DQombHQ7PGEgaHJlZj0ibWFpbHRv Om1laG1ldC5lcnN1ZUBuc24uY29tIj5tZWhtZXQuZXJzdWVAbnNuLmNvbTwvYT4mZ3Q7OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NClNlbnQ6IFN1bmRheSwgQXByaWwgMDUsIDIwMTUgMTo1NSBBTTxicj4NCiZndDsgS2F0 aGxlZW4gTW9yaWFydHkgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yPGJyPg0KJmd0OyBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpcy0wOTogTm8gT2JqZWN0 aW9uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IENPTU1FTlQ6PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBmb3VuZCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgU2VjRGly IHJldmlldyBpbnRlcmVzdGluZywgc28gdGhhbmtzIGZvcjxicj4NCiZndDsgdGhlIG1vcmUgZGV0 YWlsZWQgZXhwbGFuYXRpb25zLiZuYnNwOyBJIGRvIGFncmVlIHRoYXQgdGhlIGRyYWZ0IGFscmVh ZHk8YnI+DQpkb2VzPGJyPg0KJmd0OyBzdGF0ZSB0aGF0IHRoaXMgaXMgYSBjZXJ0aWZpY2F0ZSBm aW5nZXJwcmludCwgYnV0IGRvbid0IHNlZSAobWF5YmU8YnI+DQpwb2ludDxicj4NCiZndDsgbWUg dG8gd2hlcmUgaXQgaXMgaWYgSSBtaXNzZWQgaXQpLCB0aGF0IHRoaXMgaXMgYWxsIGxvY2FsLCBw ZXI6PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3NlY2Rpci9jdXJyZW50L21zZzA1NTI2Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDU1MjYu aHRtbDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ20gd29uZGVyaW5nIHdoeSB0aGUgeWFuZyBt b2RlbCB0aGF0IHdhcyBzcGlsdCBvdXQgaW50byBhbm90aGVyIGRyYWZ0PGJyPg0KJmd0OyBpc24n dCByZWZlcmVuY2VkIGFzIHRoYXQgd291bGQgYmUgaGVscGZ1bCBhcyB3ZWxsIChsYXN0IDIgcGFy YWdyYXBoczxicj4NCm9mPGJyPg0KJmd0OyBUb20ncyByZXNwb25zZSk6PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NlY2Rpci9jdXJyZW50 L21zZzA1NTI0Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvc2VjZGlyL2N1cnJlbnQvbXNnMDU1MjQuaHRtbDwvYT48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBUaGlzIGlzIG5vbiBibG9ja2luZyBhcyBJJ2QgbGlrZSB0byBmaWd1cmUgb3V0 IGlmIGl0J3MgaGVscGZ1bCB0bzxicj4NCmF2b2lkPGJyPg0KJmd0OyBxdWVzdGlvbnMgYW5kIGxp bmsgZHJhZnRzIHdoZXJlIGFwcHJvcHJpYXRlICh1bmxlc3MgSSBtaXNzZWQ8YnI+DQpzb21ldGhp bmcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+S2F0aGxlZW48YnI+DQo8YnI+DQpZZXMuPGJyPg0K PGJyPg0KUGVyaGFwcyBOZXRjb25mIGFuZCBZQU5HIGlzIG9uZSBvZiB0aG9zZSBhcmVhcyB3aGlj aCwgaWYgeW91IGhhdmUgbm90PGJyPg0KZm9sbG93ZWQgdGhlIGxhc3QgMTIgeWVhcnMgb2YgZGlz Y3Vzc2lvbiwgeW91IG5ldmVyIHdpbGwgcXVpdGU8YnI+DQp1bmRlcnN0YW5kOi0oPGJyPg0KPGJy Pg0KTmV0Y29uZiBzdGFydGVkIG91dCB3aXRoIFNTSCwgU09BUCBhbmQgQkVFUC4mbmJzcDsgSXQg Z2FpbmVkIFRMUywgZ290IHJldmVyc2U8YnI+DQpTU0gsIGxvc3QgU09BUCBhbmQgQkVFUCwgVExT IGFkZGVkICdyZXZlcnNlJywgJ3JldmVyc2UnIHdhcyByZW5hbWVkPGJyPg0KJ2NhbGwgaG9tZScs IGl0IGdhaW5lZCBhIE5ldGNvbmYgc2VydmVyIFlBTkcgbW9kZWwsIFRMUyBnYWluZWQgYW5kIGxv c3Q8YnI+DQphIFlBTkcgbW9kZWwsIGl0IGFkZGVkIFJFU1RDT05GIGFuZCBSRVNUQ09ORiBjYWxs IGhvbWUuJm5ic3A7IEFsb25nIHRoZSB3YXksPGJyPg0KVExTIGdhaW5lZCBhbmQgbG9zdCBQU0sg d2hpbGUgU1NIIGFjcXVpcmVkIGNlcnRpZmljYXRlcy48YnI+DQo8YnI+DQpUaGUgY3VycmVudCBJ LUQgc3RydWN0dXJlIHdhcyBhZ3JlZWQgaW4gSnVseSAyMDE0IGFuZCBvd2VzIHNvbWV0aGluZyB0 bzxicj4NCmVuZ2luZWVyaW5nLCBzb21ldGhpbmcgdG8gaGlzdG9yeSEmbmJzcDsgQ3VycmVudGx5 IGl0IGlzIG5ldGNvbmYtNTUzOWJpcyw8YnI+DQpuZXRjb25mLXNlcnZlci1tb2RlbCwgbmV0Y29u Zi1jYWxsLWhvbWUsIG5ldGNvbmYtcmVzdGNvbmYgYW5kPGJyPg0KbmV0Y29uZi16ZXJvdG91Y2gg KHdpdGggYSB2YXJpZXR5IG9mIGF1dGhvcnMsIGEgdmFyaWV0eSBvZiB0YXJnZXQ8YnI+DQpjb21w bGV0aW9uIGRhdGVzIGFuZCwgcGVyaGFwcywgYSB3aXNoIHRvIGxpbWl0IGludGVyLWRlcGVuZGVu Y2llcykuPGJyPg0KPGJyPg0KVGhlIGlzc3VlIG9mIGhvdyB0byBhdXRoZW50aWNhdGUgYSBjbGll bnQgYW5kIGRlcml2ZSBhbiBpZGVudGlmaWVyIGZvcjxicj4NCml0IGlzIGF3a3dhcmQgYW5kIG5v dCBvZnRlbiB0YWNrbGVkIGluIHRoZSBJRVRGICh3aGljaCB0ZW5kcyB0byBiZSBtb3JlPGJyPg0K Y29uY2VybmVkIHdpdGggc2VydmVyIGF1dGhlbnRpY2F0aW9uIGFuZCBIVFRQIC0gdGhpcyB3YXMg YW4gaXNzdWUgd2hlbjxicj4NCmFkZGluZyBTU0gvVExTIHRvIFNOTVAsIGFzIHdlbGwpOyBhbmQg aXQgY3V0cyBhY3Jvc3MgVExTLCBTU0ggd2l0aDxicj4NCmNlcnRpZmljYXRlcywgY2FsbCBob21l IGFuZCB6ZXJvIHRvdWNoIHdoaWxlIGl0cyBvcmlnaW5zIGdvIGJhY2sgdG8gaXNtczxicj4NCihT Tk1QKS4mbmJzcDsgSSBzZWUgbm8gYmVzdCBwbGFjZSB0byBwdXQgYWxsIHRoZSBpbmZvcm1hdGlv biBub3IgaXMgaXQgZWFzeTxicj4NCnRvIHBhcnRpdGlvbiBpdC48YnI+DQo8YnI+DQpJIGhhZCBh IGJyZWFrIHJlY2VudGx5IGFuZCB3aGVuIEkgY2FtZSBiYWNrIHRvIG5ldGNvbmYtNTUzOWJpcyw8 YnI+DQptaXN1bmRlcnN0b29kIGl0LCBiZWNhdXNlLCB0byBteSBtaW5kLCB0aGUgcHJvY2VkdXJh bCBkZXNjcmlwdGlvbjxicj4NCmFzc3VtZWQgYW4gaW5mb3JtYXRpb24gbW9kZWwsIGFuZCBJIGhh ZCB0aGUgd3JvbmcgbW9kZWwgaW4gbWluZC48YnI+DQpKdWVyZ2VuIHB1dCBtZSBzdHJhaWdodCwg YW5kIGNsYXJpZmllZCBuZXRjb25mLTU1MzliaXMgYnV0IEkgc3RpbGwgaGFkIGE8YnI+DQpsb3Qg b2YgYmFja2dyb3VuZCBrbm93bGVkZ2Ugd2hpY2ggcHJvYmFibHkgc3RvcHBlZCBtZSBoYXZpbmcg bW9yZTxicj4NCm1pc3VuZGVyc3RhbmRpbmdzLjxicj4NCjxicj4NClNvIHllcywgYSBmZXcgbW9y ZSBzZW50ZW5jZXMgY291bGQgYmUgaGVscGZ1bC4mbmJzcDsgSSB3YXMsIGZvciBleGFtcGxlLDxi cj4NCnN1cnByaXNlZCBhdCB0aGUgZGlzY3Vzc2lvbiBvbiBmaW5nZXJwcmludHMgc2luY2UgdGhl eSBoYXZlIGJlZW4gdGhhdDxicj4NCndheSBzaW5jZSBpc21zIChTTk1QKSAtJm5ic3A7IGZvciB3 aGljaCBTYW0gd2FzIHNlY3VyaXR5IGFkdmlzb3IgLSBhbmQgaGFkPGJyPg0Kbm90IHRob3VnaHQg b2YgYW4gYWx0ZXJuYXRpdmUgaW50ZXJwcmV0YXRpb24uPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+VGhhbmtzLCBUb20hJm5ic3A7IExldCBtZSBrbm93IHdoZW4gaXQn cyBiZWVuIGRvbmUgYW5kIEknbGwgYmUgaGFwcHkgdG8gcmVhZCBpdCBhZ2Fpbi48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7bXNvLWJvcmRlci1sZWZ0LWFsdDpzb2xpZCAjQ0NDQ0NDIC43NXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi Pjxicj4NClRvbSBQZXRjaDxicj4NCjxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgS2F0aGxl ZW48YnI+DQomZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0KPGJyIGNsZWFy PSJhbGwiIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1icmVhayI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+S2F0aGxl ZW48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E4DE949E6CE3E34993A2FF8AE79131F81968929BDEMUMBX005nsnin_-- From nobody Tue Apr 7 00:51:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBEF1A038A; Tue, 7 Apr 2015 00:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95MPzfoOrN7H; Tue, 7 Apr 2015 00:51:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8681A0074; Tue, 7 Apr 2015 00:51:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1A967788; Tue, 7 Apr 2015 09:51:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ErUltx6bjVCz; Tue, 7 Apr 2015 09:50:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 7 Apr 2015 09:50:59 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01DB62002B; Tue, 7 Apr 2015 09:50:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id p6d1bhhx5Gl0; Tue, 7 Apr 2015 09:50: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 7068620013; Tue, 7 Apr 2015 09:50:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8DEF632B5F78; Tue, 7 Apr 2015 09:50:56 +0200 (CEST) Date: Tue, 7 Apr 2015 09:50:56 +0200 From: Juergen Schoenwaelder To: Kathleen Moriarty Message-ID: <20150407075056.GE7019@elstar.local> Mail-Followup-To: Kathleen Moriarty , The IESG , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org References: <20150405005556.29041.96505.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150405005556.29041.96505.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, The IESG , netconf@ietf.org Subject: Re: [Netconf] Kathleen Moriarty's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 07:51:03 -0000 Kathleen, if it helps readers, we can add the following sentence to the end of section 7: The NETCONF server configuration data model [I-D.ietf-netconf-server-model] covers NETCONF over TLS and provides further details such as certificate fingerprint formats exposed to network configuration systems. Note that this would be an informative reference for the orientation of readers. I personally do not think this is actually needed - I assume that people implementing a NETCONF server will be able to locate the NETCONF server configuration data model without needing a pointer in the TLS transport mapping (there is also no pointer in the SSH transport mapping). But anyway, if people on the IESG feel strongly that adding this sentence improves readability, I can easily do so. /js On Sat, Apr 04, 2015 at 05:55:56PM -0700, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-netconf-rfc5539bis-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I found the discussion on the SecDir review interesting, so thanks for > the more detailed explanations. I do agree that the draft already does > state that this is a certificate fingerprint, but don't see (maybe point > me to where it is if I missed it), that this is all local, per: > https://www.ietf.org/mail-archive/web/secdir/current/msg05526.html > > I'm wondering why the yang model that was spilt out into another draft > isn't referenced as that would be helpful as well (last 2 paragraphs of > Tom's response): > https://www.ietf.org/mail-archive/web/secdir/current/msg05524.html > > This is non blocking as I'd like to figure out if it's helpful to avoid > questions and link drafts where appropriate (unless I missed something). > > Thanks, > Kathleen > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 7 03:35:50 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 184E41A6EE0; Tue, 7 Apr 2015 03:06:54 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AB71A1AC6 for ; Tue, 7 Apr 2015 03:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXTB1vpiW-kV for ; Tue, 7 Apr 2015 03:06:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4921A6EE0 for ; Tue, 7 Apr 2015 03:06:49 -0700 (PDT) Received: from atlas3.jacobs-university.de ([212.201.44.18]:41495) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfQPA-0006sT-Nc for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Tue, 07 Apr 2015 03:06:49 -0700 Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 45C4CE7C; Tue, 7 Apr 2015 12:06:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id IymgWTV3X58n; Tue, 7 Apr 2015 12:06:36 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 7 Apr 2015 12:06:44 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11CAD2002B; Tue, 7 Apr 2015 12:06:44 +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 N6eIE5kvblgw; Tue, 7 Apr 2015 12:06:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 255D120013; Tue, 7 Apr 2015 12:06:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 612D832B639D; Tue, 7 Apr 2015 12:06:40 +0200 (CEST) Date: Tue, 7 Apr 2015 12:06:39 +0200 From: Juergen Schoenwaelder To: Stefan Winter Message-ID: <20150407100639.GF7594@elstar.local> Mail-Followup-To: Stefan Winter , "ops-dir@ietf.org" , draft-ietf-netconf-rfc5539bis.all@tools.ietf.org References: <55239CC9.8040901@restena.lu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55239CC9.8040901@restena.lu> User-Agent: Mutt/1.4.2.3i X-SA-Exim-Connect-IP: 212.201.44.18 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: j.schoenwaelder@jacobs-university.de X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150407100649.DE4921A6EE0@ietfa.amsl.com> Resent-Date: Tue, 7 Apr 2015 03:06:49 -0700 (PDT) Resent-From: j.schoenwaelder@jacobs-university.de Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 03:35:49 -0700 Cc: "ops-dir@ietf.org" , draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Subject: Re: [Netconf] [OPS-DIR] Review of draft-ietf-netconf-rfc5539bis-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 10:06:54 -0000 On Tue, Apr 07, 2015 at 11:00:57AM +0200, Stefan Winter wrote: > Hello, > > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written with the intent of improving the > operational aspects of the IETF drafts. Comments that are not addressed > in last call may be included in AD reviews during the IESG review. > Document editors and WG chairs should treat these comments just like any > other last call comments. > > I believe the document is ready for publication with nits (see below). > > The document is part of the OPS area and thus deals with operations and > management to a great deal. It is well thought-out with version > information and negotiation (new framing vs. old framing is negotiated > with netconf's capability exchange). Backward compatibility with the old > framing is assured. > > There is one statement in the draft which seems incorrect or badly > formulated. In section 3, it is stated that: > > "The previous version [RFC5539] of this document used the framing > sequence defined in [RFC4742], under the assumption that it could not > be found in well-formed XML documents." > > That is not true; RFC5539 acknowledged this fact in its own section 2.1: > > "Since this character > sequence can legally appear in plain XML in attribute values, > comments, and processing instructions, implementations of this > document MUST ensure that this character sequence is never part of a > NETCONF message." > > Maybe I'm just confused about this. To me it seems like 5539 wasn't > "clean" in the sense that payload could be interpreted as a control > character leading to a premature close of connection (and found this an > acceptable risk). And that its successor does not consider this as > acceptable and ameliorates the situation by establishing a clean frame > for the payload by wrapping the message inside a > ... container? > > In that case, it would be nice to state it that way. The story is more complicated than that. The original transport for NETCONF over SSH picked the framing marker under the assumption that it could not be found in well-formed XML documents. This turned out to be wrong. Hence, when RFC 5539 was done, the text found in section 2.1 of RFC 5539 was created (but it is essentially only saying the framing sequence is illegal not how to deal with the situation when it appears). Later on, the NETCONF over SSH transport mapping got revised and in order to address framing isssue, a new framing mechanism was defined. The work on RFC 5539bis was started primarily to align the two framing mechanisms (and as a consequence text that was valid for the SSH mapping was copied over the TLS mapping). Perhaps a better text would be this (replacing the second paragraph in section 3): The previous version [RFC5539] of this document used the framing sequence defined in [RFC4742]. This version of the document aligns with [RFC6242] and adopts the framing protocol defined in [RFC6242] as follows: > In another minor note, I see in the RFC5539 and this draft's IANA > Considerations that the Registration Contact for TCP/6513 is > "transferred" from the individual Mohamad Badra to the IESG. Then again, > I see in the port number registration database that no asignee is > currently listed for that port at all? > > According to RFC6335 a "transfer" would actually be quite problematic. > As the author, Mohamad, are you suggesting to de-allocate from yourself, > and then re-allocate to the IESG? It would be nice to spell that out > explicitly. I do not recall what the rules where when RFC 5539 was approved. But clearly, this has been a standards-track document and thus the allocation by an individual can be seen as an error that slipped through? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 7 08:16:53 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4E3A01B3326; Tue, 7 Apr 2015 02:01:13 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281971B331D for ; Tue, 7 Apr 2015 02:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, WEIRD_PORT=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4L2surLjdNp for ; Tue, 7 Apr 2015 02:01:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB4B1B3328 for ; Tue, 7 Apr 2015 02:01:10 -0700 (PDT) Received: from smtprelay.restena.lu ([158.64.1.62]:46070) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfPNc-0001NO-O4 for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Tue, 07 Apr 2015 02:01:10 -0700 Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id CF8AA403B5; Tue, 7 Apr 2015 11:00:57 +0200 (CEST) Message-ID: <55239CC9.8040901@restena.lu> Date: Tue, 07 Apr 2015 11:00:57 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "ops-dir@ietf.org" , draft-ietf-netconf-rfc5539bis.all@tools.ietf.org OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ecxb3rxHunwSl9nRl2MSBOf3JFagIgPs4" X-SA-Exim-Connect-IP: 158.64.1.62 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: stefan.winter@restena.lu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150407090110.4BB4B1B3328@ietfa.amsl.com> Resent-Date: Tue, 7 Apr 2015 02:01:10 -0700 (PDT) Resent-From: stefan.winter@restena.lu Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 07 Apr 2015 08:16:50 -0700 Subject: [Netconf] Review of draft-ietf-netconf-rfc5539bis-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 09:01:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ecxb3rxHunwSl9nRl2MSBOf3JFagIgPs4 Content-Type: multipart/mixed; boundary="------------020907080706020607030601" This is a multi-part message in MIME format. --------------020907080706020607030601 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, =09 I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. I believe the document is ready for publication with nits (see below). The document is part of the OPS area and thus deals with operations and management to a great deal. It is well thought-out with version information and negotiation (new framing vs. old framing is negotiated with netconf's capability exchange). Backward compatibility with the old framing is assured. There is one statement in the draft which seems incorrect or badly formulated. In section 3, it is stated that: "The previous version [RFC5539] of this document used the framing sequence defined in [RFC4742], under the assumption that it could not be found in well-formed XML documents." That is not true; RFC5539 acknowledged this fact in its own section 2.1: "Since this character sequence can legally appear in plain XML in attribute values, comments, and processing instructions, implementations of this document MUST ensure that this character sequence is never part of a NETCONF message." Maybe I'm just confused about this. To me it seems like 5539 wasn't "clean" in the sense that payload could be interpreted as a control character leading to a premature close of connection (and found this an acceptable risk). And that its successor does not consider this as acceptable and ameliorates the situation by establishing a clean frame for the payload by wrapping the message inside a ... container? In that case, it would be nice to state it that way. In another minor note, I see in the RFC5539 and this draft's IANA Considerations that the Registration Contact for TCP/6513 is "transferred" from the individual Mohamad Badra to the IESG. Then again, I see in the port number registration database that no asignee is currently listed for that port at all? According to RFC6335 a "transfer" would actually be quite problematic. As the author, Mohamad, are you suggesting to de-allocate from yourself, and then re-allocate to the IESG? It would be nice to spell that out explicitly. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------020907080706020607030601 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------020907080706020607030601-- --ecxb3rxHunwSl9nRl2MSBOf3JFagIgPs4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVI5zJAAoJEMDeajWKOdxmtxIP/2y5XFBIJkGUOhpcSguWakfp hqwAoIkG+tXduMRohyhKXvZd8vLu7Yn7FgSwSVQyWw7EOaYHFmdTE/NAP4vN7Cdy 1ldY/O+lnIMuWfHwbh/VvyMpFlLbiAg+Zw7uLGkrsBkfo6M2x+wwjMc9GYaAidvG ExjqAjmKJ/tI7y1TlZpJlgDvHsAybSa4o2KuVuXxiBPDMfACU6o3/WrE7ruQnoYU /jNPcNS7VwduGfRk/dgCRPdpwIfWTW1nxFG4pGh1R3xM7Ms99jSjJMQmy7cuRHOD zUoHiXT3coX2iV5rItVJZ7Xf9gy3lU+e2ooKP2IKB0QUryX1AbOCdTEygmi1z5pH txGIFTNR888XXuIjrqZJe5+KPD8H6pwk5JtYd8Nb83UaBWWpSoln31sqdzVRFrwd uoIoYXChKGMvohslEyVB6jSCa+VFBSuios1lqBpVUj7v9gJ8HB1mIKOV8ouw6pSv 2HkENQqyIHWi0COUAruU9ZtGVrxgBYPhx3DuyxFaAdkPExQKm0XcRPefmv3U2yj+ 2F5Enqa+bZ2shMtdiA532YQSIBzgSJOUI1ahMm7h9s7+x1XQWHEcplyvkBgzrkA4 OPjRcNU6H9Oct/rNmtSaQnZcP7VCW018dzmaRlq504GGjFiw9MHzl8MgqYgHrSSa pY6PSWDxJKxLgjKdVn/0 =5I0U -----END PGP SIGNATURE----- --ecxb3rxHunwSl9nRl2MSBOf3JFagIgPs4-- From nobody Wed Apr 8 01:10:25 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8941A913E; Tue, 7 Apr 2015 16:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAfi74K9HTHd; Tue, 7 Apr 2015 16:26:32 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B611A89AC; Tue, 7 Apr 2015 16:26:32 -0700 (PDT) Received: by layy10 with SMTP id y10so53793956lay.0; Tue, 07 Apr 2015 16:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HkU0EZ+8XlGL9IABaMdYlnJZAeAL2MWcm2/Rvs8VwKM=; b=B0Q8krbJAHewrtWL7lvE2coQoK62z+H323hMzzGIOGEu+CtEYoDO4XOWyjZCKodepl dou7fRm/wzMqEzMpo6WbSaWLQ7rNLME+bug/Y/xfHhtUceGm314RtDuiO5hDwEDAzSAB l2qGHwzWRKvZsl/XgPKh2GVMHchScN6pGxXdfw3lGcxTealwZlZzPy5tLXY0MhMl296k cpm49r3xV9OhNfGvDexSsvP7Ae6tVFq3tUOkei2RNHw/e1cWKAhRK38uiftNNcgaqIa0 mrjHrEeQ6ZQReWbx79oclD8PkhoaM06Wf8Ec319je6vrP9/69TNTwW4gUX+9UYNVLcCn xWNQ== MIME-Version: 1.0 X-Received: by 10.152.120.70 with SMTP id la6mr90614lab.65.1428449190960; Tue, 07 Apr 2015 16:26:30 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Tue, 7 Apr 2015 16:26:30 -0700 (PDT) In-Reply-To: <20150407075056.GE7019@elstar.local> References: <20150405005556.29041.96505.idtracker@ietfa.amsl.com> <20150407075056.GE7019@elstar.local> Date: Tue, 7 Apr 2015 19:26:30 -0400 Message-ID: From: Kathleen Moriarty To: Juergen Schoenwaelder , Kathleen Moriarty , The IESG , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org Content-Type: multipart/alternative; boundary=089e012299d49b655405132abeb5 Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 01:10:24 -0700 Subject: Re: [Netconf] Kathleen Moriarty's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2015 23:26:35 -0000 --089e012299d49b655405132abeb5 Content-Type: text/plain; charset=UTF-8 Hello, On Tue, Apr 7, 2015 at 3:50 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Kathleen, > > if it helps readers, we can add the following sentence to the end of > section 7: > > The NETCONF server configuration data model > [I-D.ietf-netconf-server-model] covers NETCONF over TLS and provides > further details such as certificate fingerprint formats exposed to > network configuration systems. > > Note that this would be an informative reference for the orientation > of readers. I personally do not think this is actually needed - I > assume that people implementing a NETCONF server will be able to > locate the NETCONF server configuration data model without needing a > pointer in the TLS transport mapping (there is also no pointer in the > SSH transport mapping). But anyway, if people on the IESG feel > strongly that adding this sentence improves readability, I can easily > do so. > > I do think it's helpful to add a little more detail and pointers int he draft to the other work that is assumed. My comment is non-blocking, so it's the editors choice with the WG and AD, but I do think a little more text to provide this background is helpful. Thank you, Kathleen > /js > > On Sat, Apr 04, 2015 at 05:55:56PM -0700, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-netconf-rfc5539bis-09: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I found the discussion on the SecDir review interesting, so thanks for > > the more detailed explanations. I do agree that the draft already does > > state that this is a certificate fingerprint, but don't see (maybe point > > me to where it is if I missed it), that this is all local, per: > > https://www.ietf.org/mail-archive/web/secdir/current/msg05526.html > > > > I'm wondering why the yang model that was spilt out into another draft > > isn't referenced as that would be helpful as well (last 2 paragraphs of > > Tom's response): > > https://www.ietf.org/mail-archive/web/secdir/current/msg05524.html > > > > This is non blocking as I'd like to figure out if it's helpful to avoid > > questions and link drafts where appropriate (unless I missed something). > > > > Thanks, > > Kathleen > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -- Best regards, Kathleen --089e012299d49b655405132abeb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

On Tue, Apr 7, 2015 at 3:50 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Kathleen,

if it helps readers, we can add the following sentence to the end of
section 7:

=C2=A0 =C2=A0The NETCONF server configuration data model
=C2=A0 =C2=A0[I-D.ietf-netconf-server-model] covers NETCONF over TLS and pr= ovides
=C2=A0 =C2=A0further details such as certificate fingerprint formats expose= d to
=C2=A0 =C2=A0network configuration systems.

Note that this would be an informative reference for the orientation
of readers. I personally do not think this is actually needed - I
assume that people implementing a NETCONF server will be able to
locate the NETCONF server configuration data model without needing a
pointer in the TLS transport mapping (there is also no pointer in the
SSH transport mapping). But anyway, if people on the IESG feel
strongly that adding this sentence improves readability, I can easily
do so.

I do think it's helpful to add a little more deta= il and pointers int he draft to the other work that is assumed.=C2=A0 My co= mment is non-blocking, so it's the editors choice with the WG and AD, b= ut I do think a little more text to provide this background is helpful.

Thank you,
Kathleen
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> /js

On Sat, Apr 04, 2015 at 05:55:56PM -0700, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-netconf-rfc5539bis-09: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-netconf-r= fc5539bis/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I found the discussion on the SecDir review interesting, so thanks for=
> the more detailed explanations.=C2=A0 I do agree that the draft alread= y does
> state that this is a certificate fingerprint, but don't see (maybe= point
> me to where it is if I missed it), that this is all local, per:
> https://www.ietf.org/mail-archive/web/secdir/cur= rent/msg05526.html
>
> I'm wondering why the yang model that was spilt out into another d= raft
> isn't referenced as that would be helpful as well (last 2 paragrap= hs of
> Tom's response):
> https://www.ietf.org/mail-archive/web/secdir/cur= rent/msg05524.html
>
> This is non blocking as I'd like to figure out if it's helpful= to avoid
> questions and link drafts where appropriate (unless I missed something= ).
>
> Thanks,
> Kathleen
>
>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>



--

Best regards,
Kathleen
--089e012299d49b655405132abeb5-- From nobody Wed Apr 8 08:14:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9EA1B3222; Wed, 8 Apr 2015 08:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMpH-ubzULZk; Wed, 8 Apr 2015 08:14:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E361B321B; Wed, 8 Apr 2015 08:14:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408151424.18338.98057.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 08:14:24 -0700 Archived-At: Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org Subject: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 15:14:26 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netconf-rfc5539bis-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 2: be no harm to say the server has to send a CertificateRequest as part of the handshake and/or to say (or point to) how e.g. to configure that in apache or similar. (Not normatively, but as an illustration to save folks time when they go to do it.) - section 7, if we get the ID via step (b) option 2 and step (c) option A then anyone certified below that CA gets to use that identity. I'd say that's a sufficiently bad plan in almost all cases to be worth noting as a security consideration. (Sorry for not spotting that in RFC7407 but I think the alg there is harder to see in the yang module(s) so I guess I missed it;-) - I agree with Sam's second comment in the secdir review [1] that specifying how to fingerprint is a good idea, even if it's non-normative. I think in this case you may need to fingerprint the full certificate and not the public key, as the latter could allow attacks - but someone would need to spend more time that I have today to figure out if there are any interesting attacks. (Did the WG think those issues through?) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05522.html From nobody Thu Apr 9 01:58:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80C61B29A7; Thu, 9 Apr 2015 01:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X95YaWGoCOAw; Thu, 9 Apr 2015 01:57:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C731B29A4; Thu, 9 Apr 2015 01:57:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A00D48E1; Thu, 9 Apr 2015 10:57:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4LJ2zAXnSqTL; Thu, 9 Apr 2015 10:57:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Apr 2015 10:57:51 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E55B20013; Thu, 9 Apr 2015 10:57:51 +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 ExRe3hX7t5A7; Thu, 9 Apr 2015 10:57: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 770BA2002B; Thu, 9 Apr 2015 10:57:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6857532BC2ED; Thu, 9 Apr 2015 10:57:47 +0200 (CEST) Date: Thu, 9 Apr 2015 10:57:46 +0200 From: Juergen Schoenwaelder To: Stephen Farrell Message-ID: <20150409085746.GA27233@elstar.local> Mail-Followup-To: Stephen Farrell , The IESG , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org References: <20150408151424.18338.98057.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150408151424.18338.98057.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, The IESG , netconf@ietf.org Subject: Re: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 08:57:56 -0000 On Wed, Apr 08, 2015 at 08:14:24AM -0700, Stephen Farrell wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - section 2: be no harm to say the server has to send a > CertificateRequest as part of the handshake and/or to say (or > point to) how e.g. to configure that in apache or similar. > (Not normatively, but as an illustration to save folks time > when they go to do it.) Would this address your comment: OLD [...] The TLS client MUST send the TLS ClientHello message to begin the TLS handshake. Once the TLS handshake has finished, the client and the server MAY begin to exchange NETCONF messages. NEW: [...] The TLS client MUST send the TLS ClientHello message to begin the TLS handshake. The TLS server MUST send a CertificateRequest in order to request a certificate from the TLS client. Once the TLS handshake has finished, the client and the server MAY begin to exchange NETCONF messages. I am not sure it makes sense to describe how this is done using Apache since NETCONF is not running over HTTP and thus servers are not using web-server configs. > - section 7, if we get the ID via step (b) option 2 and step > (c) option A then anyone certified below that CA gets to use > that identity. I'd say that's a sufficiently bad plan in > almost all cases to be worth noting as a security > consideration. (Sorry for not spotting that in RFC7407 but I > think the alg there is harder to see in the yang module(s) so > I guess I missed it;-) I do not see the problem. Step (b) determines whether the current list entry should be considered (because the fingerprint matches the client's certificate fingerprint or it matches the fingerprint of a CA certificate used to validate the client's fingerprint). The subsequent steps in (c) determine the username out of the client's fingerprint (and not the CA certificate in case (b).2 was used in step (b)). > - I agree with Sam's second comment in the secdir review [1] > that specifying how to fingerprint is a good idea, even if > it's non-normative. I think in this case you may need to > fingerprint the full certificate and not the public key, as > the latter could allow attacks - but someone would need to > spend more time that I have today to figure out if there are > any interesting attacks. (Did the WG think those issues > through?) > > [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05522.html > The text says in a couple of places 'certificate fingerprint'. It never talks about the embedded key itself. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 9 02:57:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633231B2D69; Thu, 9 Apr 2015 02:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqQhPTHHTH3E; Thu, 9 Apr 2015 02:57:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC3D1B2D4E; Thu, 9 Apr 2015 02:57:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 87C14BE8A; Thu, 9 Apr 2015 10:57:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGl-xeckY6yO; Thu, 9 Apr 2015 10:57:13 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C3068BE3F; Thu, 9 Apr 2015 10:57:12 +0100 (IST) Message-ID: <55264CF8.8090903@cs.tcd.ie> Date: Thu, 09 Apr 2015 10:57:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: The IESG , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org References: <20150408151424.18338.98057.idtracker@ietfa.amsl.com> <20150409085746.GA27233@elstar.local> In-Reply-To: <20150409085746.GA27233@elstar.local> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 09:57:22 -0000 Hiya, On 09/04/15 09:57, Juergen Schoenwaelder wrote: > On Wed, Apr 08, 2015 at 08:14:24AM -0700, Stephen Farrell wrote: >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - section 2: be no harm to say the server has to send a >> CertificateRequest as part of the handshake and/or to say (or >> point to) how e.g. to configure that in apache or similar. >> (Not normatively, but as an illustration to save folks time >> when they go to do it.) > > Would this address your comment: > > OLD > > [...] The TLS client > MUST send the TLS ClientHello message to begin the TLS handshake. > Once the TLS handshake has finished, the client and the server MAY > begin to exchange NETCONF messages. > > NEW: > > [...] The TLS client > MUST send the TLS ClientHello message to begin the TLS handshake. > The TLS server MUST send a CertificateRequest in order to request a > certificate from the TLS client. Once the TLS handshake has > finished, the client and the server MAY begin to exchange NETCONF > messages. > > I am not sure it makes sense to describe how this is done using Apache > since NETCONF is not running over HTTP and thus servers are not using > web-server configs. Fair enough. > >> - section 7, if we get the ID via step (b) option 2 and step >> (c) option A then anyone certified below that CA gets to use >> that identity. I'd say that's a sufficiently bad plan in >> almost all cases to be worth noting as a security >> consideration. (Sorry for not spotting that in RFC7407 but I >> think the alg there is harder to see in the yang module(s) so >> I guess I missed it;-) > > I do not see the problem. So say a Web PKI root CA certificate fingerprint is added then anyone who gets a web site certificate from them could be logged in to the server as whatever identity is stored for all the millions of possible certificates that chain up to that CA. It's just a matter of scope, and I think this is an error that could be made. Well, not for a public CA like the above but maybe for an enterprise CA that also issues employee cards, s/mime certs, software licenses etc. That kind of thing was part of the flame attack due to how msft architected their PKI so as to entwine licensing and other PKI stuff. I think you ought point out that there is a codepath here that could end up allowing loads of TLS clients to get access if you configure things badly, but in a way that's not extremely unlikely to happen. > Step (b) determines whether the current list > entry should be considered (because the fingerprint matches the > client's certificate fingerprint or it matches the fingerprint of a CA > certificate used to validate the client's fingerprint). The subsequent > steps in (c) determine the username out of the client's fingerprint > (and not the CA certificate in case (b).2 was used in step (b)). > >> - I agree with Sam's second comment in the secdir review [1] >> that specifying how to fingerprint is a good idea, even if >> it's non-normative. I think in this case you may need to >> fingerprint the full certificate and not the public key, as >> the latter could allow attacks - but someone would need to >> spend more time that I have today to figure out if there are >> any interesting attacks. (Did the WG think those issues >> through?) >> >> [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05522.html >> > > The text says in a couple of places 'certificate fingerprint'. It > never talks about the embedded key itself. Ok, but (again, non-blocking) I'd recommend you describe a way to do that. Cheers, S. > > /js > From nobody Thu Apr 9 07:06:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBCD1A1EF1; Thu, 9 Apr 2015 07:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5qwT79tXBQK; Thu, 9 Apr 2015 07:06:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0FA1A1EEA; Thu, 9 Apr 2015 07:06:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F2C77114E; Thu, 9 Apr 2015 16:06:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rlW3uMOkDhpY; Thu, 9 Apr 2015 16:06:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Apr 2015 16:06:39 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDBDD2002B; Thu, 9 Apr 2015 16:06:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9XhzZPb3kd9c; Thu, 9 Apr 2015 16:06:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56C3020013; Thu, 9 Apr 2015 16:06:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1B11F32BC8FC; Thu, 9 Apr 2015 16:06:37 +0200 (CEST) Date: Thu, 9 Apr 2015 16:06:37 +0200 From: Juergen Schoenwaelder To: Stephen Farrell Message-ID: <20150409140636.GC28305@elstar.local> Mail-Followup-To: Stephen Farrell , The IESG , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org References: <20150408151424.18338.98057.idtracker@ietfa.amsl.com> <20150409085746.GA27233@elstar.local> <55264CF8.8090903@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55264CF8.8090903@cs.tcd.ie> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, The IESG , netconf@ietf.org Subject: Re: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:06:43 -0000 On Thu, Apr 09, 2015 at 10:57:12AM +0100, Stephen Farrell wrote: > > > > >> - section 7, if we get the ID via step (b) option 2 and step > >> (c) option A then anyone certified below that CA gets to use > >> that identity. I'd say that's a sufficiently bad plan in > >> almost all cases to be worth noting as a security > >> consideration. (Sorry for not spotting that in RFC7407 but I > >> think the alg there is harder to see in the yang module(s) so > >> I guess I missed it;-) > > > > I do not see the problem. > > So say a Web PKI root CA certificate fingerprint is added > then anyone who gets a web site certificate from them could > be logged in to the server as whatever identity is stored for > all the millions of possible certificates that chain up to > that CA. > > It's just a matter of scope, and I think this is an error > that could be made. Well, not for a public CA like the > above but maybe for an enterprise CA that also issues > employee cards, s/mime certs, software licenses etc. That > kind of thing was part of the flame attack due to how > msft architected their PKI so as to entwine licensing and > other PKI stuff. > > I think you ought point out that there is a codepath here > that could end up allowing loads of TLS clients to get > access if you configure things badly, but in a way that's > not extremely unlikely to happen. > Would this addition to the security considerations address your concern? [...] Note that the decision whether a certificate presented by the client is accepted can depend on whether a trusted CA certificate is white listed (see Section 7). If deployments make use of this option, it is recommended that the white listed CA certificate is used only to issue certificates that are used for accessing NETCONF servers. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 9 07:14:36 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1C81A1EEA; Thu, 9 Apr 2015 07:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8orr7GsB85uG; Thu, 9 Apr 2015 07:14:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156011A1BED; Thu, 9 Apr 2015 07:14:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E7E5DBDD8; Thu, 9 Apr 2015 15:14:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR2SVEOXhuqY; Thu, 9 Apr 2015 15:14:26 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 99F35BECC; Thu, 9 Apr 2015 15:14:26 +0100 (IST) Message-ID: <55268942.40205@cs.tcd.ie> Date: Thu, 09 Apr 2015 15:14:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: The IESG , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org References: <20150408151424.18338.98057.idtracker@ietfa.amsl.com> <20150409085746.GA27233@elstar.local> <55264CF8.8090903@cs.tcd.ie> <20150409140636.GC28305@elstar.local> In-Reply-To: <20150409140636.GC28305@elstar.local> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:14:31 -0000 On 09/04/15 15:06, Juergen Schoenwaelder wrote: > On Thu, Apr 09, 2015 at 10:57:12AM +0100, Stephen Farrell wrote: >> >>> >>>> - section 7, if we get the ID via step (b) option 2 and step >>>> (c) option A then anyone certified below that CA gets to use >>>> that identity. I'd say that's a sufficiently bad plan in >>>> almost all cases to be worth noting as a security >>>> consideration. (Sorry for not spotting that in RFC7407 but I >>>> think the alg there is harder to see in the yang module(s) so >>>> I guess I missed it;-) >>> >>> I do not see the problem. >> >> So say a Web PKI root CA certificate fingerprint is added >> then anyone who gets a web site certificate from them could >> be logged in to the server as whatever identity is stored for >> all the millions of possible certificates that chain up to >> that CA. >> >> It's just a matter of scope, and I think this is an error >> that could be made. Well, not for a public CA like the >> above but maybe for an enterprise CA that also issues >> employee cards, s/mime certs, software licenses etc. That >> kind of thing was part of the flame attack due to how >> msft architected their PKI so as to entwine licensing and >> other PKI stuff. >> >> I think you ought point out that there is a codepath here >> that could end up allowing loads of TLS clients to get >> access if you configure things badly, but in a way that's >> not extremely unlikely to happen. >> > > Would this addition to the security considerations address your > concern? > > [...] Note that the decision > whether a certificate presented by the client is accepted can depend > on whether a trusted CA certificate is white listed (see Section 7). > If deployments make use of this option, it is recommended that the > white listed CA certificate is used only to issue certificates that > are used for accessing NETCONF servers. Yes, that'd be a fine recommendation to follow. I'd personally also add text about the bad case where the CA issues many certificates for other purposes and say that that particular configuration is not suitable. S. > > /js > From nobody Thu Apr 9 07:27:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F6D1A6F30; Thu, 9 Apr 2015 07:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzZdMWsx6BfU; Thu, 9 Apr 2015 07:26:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22BA1A710D; Thu, 9 Apr 2015 07:26:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B1827114E; Thu, 9 Apr 2015 16:26:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mtvJFG96xINh; Thu, 9 Apr 2015 16:26:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Apr 2015 16:26:44 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B957F2002C; Thu, 9 Apr 2015 16:26:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LzD5372WL3Zr; Thu, 9 Apr 2015 16:26:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69AC12002B; Thu, 9 Apr 2015 16:26:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 478D532BCA80; Thu, 9 Apr 2015 16:26:42 +0200 (CEST) Date: Thu, 9 Apr 2015 16:26:42 +0200 From: Juergen Schoenwaelder To: Stephen Farrell Message-ID: <20150409142642.GB28625@elstar.local> Mail-Followup-To: Stephen Farrell , The IESG , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org References: <20150408151424.18338.98057.idtracker@ietfa.amsl.com> <20150409085746.GA27233@elstar.local> <55264CF8.8090903@cs.tcd.ie> <20150409140636.GC28305@elstar.local> <55268942.40205@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55268942.40205@cs.tcd.ie> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, The IESG , netconf@ietf.org Subject: Re: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:26:52 -0000 On Thu, Apr 09, 2015 at 03:14:26PM +0100, Stephen Farrell wrote: > > > Would this addition to the security considerations address your > > concern? > > > > [...] Note that the decision > > whether a certificate presented by the client is accepted can depend > > on whether a trusted CA certificate is white listed (see Section 7). > > If deployments make use of this option, it is recommended that the > > white listed CA certificate is used only to issue certificates that > > are used for accessing NETCONF servers. > > Yes, that'd be a fine recommendation to follow. > > I'd personally also add text about the bad case where the CA > issues many certificates for other purposes and say that that > particular configuration is not suitable. > Next proposal... [...] Note that the decision whether a certificate presented by the client is accepted can depend on whether a trusted CA certificate is white listed (see Section 7). If deployments make use of this option, it is recommended that the white listed CA certificate is used only to issue certificates that are used for accessing NETCONF servers. Should the CA certificate be used to issue certificates for other purposes, then all certificates created for other purposes will be accepted by a NETCONF server as well, which is likely not suitable. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 9 07:27:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C1D1A1BCF; Thu, 9 Apr 2015 07:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxLgIeT4BvMl; Thu, 9 Apr 2015 07:27:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CEC91A6EE9; Thu, 9 Apr 2015 07:27:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 69CE9BEDC; Thu, 9 Apr 2015 15:27:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJ8OnyVMfQcg; Thu, 9 Apr 2015 15:27:25 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2E751BED5; Thu, 9 Apr 2015 15:27:25 +0100 (IST) Message-ID: <55268C4C.9070709@cs.tcd.ie> Date: Thu, 09 Apr 2015 15:27:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: The IESG , draft-ietf-netconf-rfc5539bis@ietf.org, netconf-chairs@ietf.org, draft-ietf-netconf-rfc5539bis.ad@ietf.org, draft-ietf-netconf-rfc5539bis.shepherd@ietf.org, mehmet.ersue@nsn.com, netconf@ietf.org References: <20150408151424.18338.98057.idtracker@ietfa.amsl.com> <20150409085746.GA27233@elstar.local> <55264CF8.8090903@cs.tcd.ie> <20150409140636.GC28305@elstar.local> <55268942.40205@cs.tcd.ie> <20150409142642.GB28625@elstar.local> In-Reply-To: <20150409142642.GB28625@elstar.local> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 14:27:35 -0000 On 09/04/15 15:26, Juergen Schoenwaelder wrote: > On Thu, Apr 09, 2015 at 03:14:26PM +0100, Stephen Farrell wrote: >> >>> Would this addition to the security considerations address your >>> concern? >>> >>> [...] Note that the decision >>> whether a certificate presented by the client is accepted can depend >>> on whether a trusted CA certificate is white listed (see Section 7). >>> If deployments make use of this option, it is recommended that the >>> white listed CA certificate is used only to issue certificates that >>> are used for accessing NETCONF servers. >> >> Yes, that'd be a fine recommendation to follow. >> >> I'd personally also add text about the bad case where the CA >> issues many certificates for other purposes and say that that >> particular configuration is not suitable. >> > > Next proposal... > > [...] Note that the decision > whether a certificate presented by the client is accepted can depend > on whether a trusted CA certificate is white listed (see Section 7). > If deployments make use of this option, it is recommended that the > white listed CA certificate is used only to issue certificates that > are used for accessing NETCONF servers. Should the CA certificate be > used to issue certificates for other purposes, then all certificates > created for other purposes will be accepted by a NETCONF server as > well, which is likely not suitable. Lovely, Thanks, S. > > /js > From nobody Thu Apr 9 11:01:30 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5061B3042; Thu, 9 Apr 2015 11:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7H9GyKiIbN2; Thu, 9 Apr 2015 11:01:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 643001B303C; Thu, 9 Apr 2015 11:01:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150409180125.23462.96024.idtracker@ietfa.amsl.com> Date: Thu, 09 Apr 2015 11:01:25 -0700 From: IETF Secretariat Archived-At: Subject: [Netconf] ID Tracker State Update Notice: X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 18:01:27 -0000 IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ From nobody Thu Apr 9 23:21:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3187A1ACEAC for ; Thu, 9 Apr 2015 23:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUz6R5r5c9a6 for ; Thu, 9 Apr 2015 23:21:21 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 82F5C1ACE8C for ; Thu, 9 Apr 2015 23:21:15 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 72F4C12801AA; Fri, 10 Apr 2015 08:21:14 +0200 (CEST) Date: Fri, 10 Apr 2015 08:21:16 +0200 (CEST) Message-Id: <20150410.082116.663742183631558687.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] subtree filter normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 06:21:23 -0000 Hi, Andy Bierman wrote: > Hi, > > I'm trying to rewrite some NETCONF code, and I cannot > tell if RFC 6241 allows for subtree filters to be normalized. > It is not clear how certain usage should be processed. > > This text in 6.1, para 1 seems to suggest the filter does not > need to follow a schema. > > The server does not need to utilize any data-model- > specific semantics during processing, allowing for simple and > centralized implementation strategies. > > > I am not convinced NETCONF is correct here > (and I wrote a lot of this subtree text ;-) > IMO the server MUST return schema-valid content > for YANG modules it advertises, > and that requires the filter to be interpreted > and the response content normalized. This would indeed have been better! But that's not what the spec says... > F0 is the well-behaved example on pg 25: > > F0: > > > > > fred > > > > > > The RFC does not say if the 'name' select node can be repeated, > as in F1: > > F1: > > > > > fred > barney > > > > > > 6.2.5, bullet 2 says these are ANDed together, so > filter F1 would not match anything. IMO this should only > apply to different select leafs. Duplicate select leafs > should be ORed together. This will help normalization. I think the current behavior is correct. If you want to get both fred and barney you have to do: fred barney I don't think there is any reason for a special case when the select node is duplicated. It can actually be confusing. Assuming the list has two keys, what would this mean: martin andy bjorklund bierman > F2: > > > > > fred > > > fred > > > > > > Is F2 allowed? (container user repeated) > Is the server required to collapse the entries for return > so the rpc-reply is schema-valid? In this case the natural reply is schema-valid: fred ... fred ... > Same applies to F3 and F4. The way the spec is written (data model agnostic), you'd get a reply that mimics the filter input. The only way for a server to collapse the s into a single element, is to utilize the fact that "users" is a container. > F3: variant of F2 > > > > > fred > > > > > fred > > > > > > F4: variant of F2 > > > > > fred > > > > > > > barney > > > > /martin From nobody Fri Apr 10 02:05:02 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AAFBA1ACE25; Thu, 9 Apr 2015 22:52:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA931ACE24 for ; Thu, 9 Apr 2015 22:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, WEIRD_PORT=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNJ276Tc7g0e for ; Thu, 9 Apr 2015 22:52:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0EE1ACE13 for ; Thu, 9 Apr 2015 22:52:33 -0700 (PDT) Received: from smtprelay.restena.lu ([2001:a18:1::62]:54141) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgRrk-0004az-25 for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Thu, 09 Apr 2015 22:52:33 -0700 Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id CE1C44397A; Fri, 10 Apr 2015 07:52:26 +0200 (CEST) Message-ID: <55276515.800@restena.lu> Date: Fri, 10 Apr 2015 07:52:21 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "ops-dir@ietf.org" , draft-ietf-netconf-rfc5539bis.all@tools.ietf.org References: <55239CC9.8040901@restena.lu> <20150407100639.GF7594@elstar.local> In-Reply-To: <20150407100639.GF7594@elstar.local> OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fslhncGdJVgS1BupSqj99scnBoccOGUSX" X-SA-Exim-Connect-IP: 2001:a18:1::62 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: stefan.winter@restena.lu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150410055233.5C0EE1ACE13@ietfa.amsl.com> Resent-Date: Thu, 9 Apr 2015 22:52:33 -0700 (PDT) Resent-From: stefan.winter@restena.lu Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 10 Apr 2015 02:05:01 -0700 Subject: Re: [Netconf] [OPS-DIR] Review of draft-ietf-netconf-rfc5539bis-09 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 05:52:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fslhncGdJVgS1BupSqj99scnBoccOGUSX Content-Type: multipart/mixed; boundary="------------090409010701080807080803" This is a multi-part message in MIME format. --------------090409010701080807080803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > The story is more complicated than that. The original transport for > NETCONF over SSH picked the framing marker under the assumption that > it could not be found in well-formed XML documents. This turned out to > be wrong. Hence, when RFC 5539 was done, the text found in section 2.1 > of RFC 5539 was created (but it is essentially only saying the framing > sequence is illegal not how to deal with the situation when it > appears). Later on, the NETCONF over SSH transport mapping got revised > and in order to address framing isssue, a new framing mechanism was > defined. The work on RFC 5539bis was started primarily to align the > two framing mechanisms (and as a consequence text that was valid for > the SSH mapping was copied over the TLS mapping). Thanks for this extra background - quite complicated indeed. > Perhaps a better text would be this (replacing the second paragraph in > section 3): >=20 > The previous version [RFC5539] of this document used the framing > sequence defined in [RFC4742]. This version of the document aligns > with [RFC6242] and adopts the framing protocol defined in [RFC6242] > as follows: Sounds good to me. >> In another minor note, I see in the RFC5539 and this draft's IANA >> Considerations that the Registration Contact for TCP/6513 is >> "transferred" from the individual Mohamad Badra to the IESG. Then agai= n, >> I see in the port number registration database that no asignee is >> currently listed for that port at all? >> >> According to RFC6335 a "transfer" would actually be quite problematic.= >> As the author, Mohamad, are you suggesting to de-allocate from yoursel= f, >> and then re-allocate to the IESG? It would be nice to spell that out >> explicitly. >=20 > I do not recall what the rules where when RFC 5539 was approved. But > clearly, this has been a standards-track document and thus the > allocation by an individual can be seen as an error that slipped > through? Probably; TBH, I don't care much about this, just spotted it. I guess IANA would be the one to raise real concerns if there are any. I would hope that whatever the process is, the outcome would be that the assignee in the end is "The IESG". Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------090409010701080807080803 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------090409010701080807080803-- --fslhncGdJVgS1BupSqj99scnBoccOGUSX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVJ2UaAAoJEMDeajWKOdxm8AAQAJiY8sC8SVfneuehCCA0gpfX UE/TGHaSVuLN08q1Vt6aZMI7XsfmOm2CuyvcahpF00J5ztgSK/AkwkOwHrhe3Ox/ mZ5r1/zD36JIUgN1elqid5KO8+9fvCuhgZBzexwXU0PrL3Q7KYlFQpgdcWRB+4f+ +ENudAOg5K+5OxaGqSVi9Qci8c50b1RimDOdWV52R5lTLymKS3HJP/KS+vOHiLq7 3GlchIXCT80JjrZ/rMxv3gUxyTKkTHeba7tuNzWhOty6h572YuLKLUX/jHjQnyij XWqi7KTGzkTZMwQJKGIZ7TwnJvS+C+ijLVINYQkVAql7YgwyaZ2PAI+3xzZdFNp5 Z5hDXFn/uJU+72FExHDwEOIx92PWe/7vQ9Co4zF/vLjfIgZEXbJVbk2WKHmH5hAc l5+8V223PMsnuMYSjw7m97sJvs4NbzYOWuQel3dsqYYGlNi1yTTkMN29t0EdYCgd pRIDO/tiJfL4ja+xzIkVHoZ/ei8jZzTtK7LfxdNF882XhguPrLhTllMpjVb7SQaF ySvN91acotIcvSocngnRs9ta0oDCOZFY5+bd4ADW8XNSeTnqr8oB0S7I55HUGvgM 0Pm8GNKvTidiGAGv2+Wr9volLZNezg4sgCyr7HxJi7nytRw0XNDEdRjEFbzAa+9h K4/rQOEniVjafcnQN+cl =stWU -----END PGP SIGNATURE----- --fslhncGdJVgS1BupSqj99scnBoccOGUSX-- From nobody Fri Apr 10 02:05:04 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 390621B2A97; Fri, 10 Apr 2015 01:01:50 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133A51B2A8B for ; Fri, 10 Apr 2015 01:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_HTML_ATTACH=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db5KUmcn1tCR for ; Fri, 10 Apr 2015 01:01:44 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48991B2A99 for ; Fri, 10 Apr 2015 01:01:40 -0700 (PDT) Received: from atlas3.jacobs-university.de ([212.201.44.18]:44384) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgTse-0007i8-Q5 for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Fri, 10 Apr 2015 01:01:40 -0700 Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 58B491159 for ; Fri, 10 Apr 2015 10:01:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SCH_QzZQhasb for ; Fri, 10 Apr 2015 10:00:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 10 Apr 2015 10:01:22 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21DC22002C for ; Fri, 10 Apr 2015 10:01:22 +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 PtaXFwPtwb7b; Fri, 10 Apr 2015 10:01:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 832B920013; Fri, 10 Apr 2015 10:01:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F196D32BD7DD; Fri, 10 Apr 2015 10:01:06 +0200 (CEST) Date: Fri, 10 Apr 2015 10:01:06 +0200 From: Juergen Schoenwaelder To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Message-ID: <20150410080106.GA2282@elstar.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-SA-Exim-Connect-IP: 212.201.44.18 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: j.schoenwaelder@jacobs-university.de X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150410080140.A48991B2A99@ietfa.amsl.com> Resent-Date: Fri, 10 Apr 2015 01:01:40 -0700 (PDT) Resent-From: j.schoenwaelder@jacobs-university.de Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 10 Apr 2015 02:05:01 -0700 Subject: [Netconf] document status X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 08:01:50 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I see that the document is now in the state "Approved-announcement to be sent::Point Raised - writeup needed". Not sure what the point raised is but I thought I let you know that I do have a version of the I-D that incorporates all the edits that were suggested during the IESG chat preparation phase. I am happy to post that any time in case this helps. Attached is the rfcdiff. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 --x+6KMIRAuhnl3hBn Content-Type: text/html; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-netconf-rfc5539bis-10-from-09.diff.html" Diff: draft-ietf-netconf-rfc5539bis-09.txt - draft-ietf-netconf-rfc5539bis-10.txt
 draft-ietf-netconf-rfc5539bis-09.txt   draft-ietf-netconf-rfc5539bis-10.txt 
NETCONF Working Group M. Badra NETCONF Working Group M. Badra
Internet-Draft Zayed University Internet-Draft Zayed University
Obsoletes: 5539 (if approved) A. Luchuk Obsoletes: 5539 (if approved) A. Luchuk
Intended status: Standards Track SNMP Research, Inc. Intended status: Standards Track SNMP Research, Inc.
Expires: August 16, 2015 J. Schoenwaelder Expires: October 12, 2015 J. Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
February 12, 2015 April 10, 2015
Using the NETCONF Protocol over Transport Layer Security (TLS) with Using the NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication Mutual X.509 Authentication
draft-ietf-netconf-rfc5539bis-09 draft-ietf-netconf-rfc5539bis-10
Abstract Abstract
The Network Configuration Protocol (NETCONF) provides mechanisms to The Network Configuration Protocol (NETCONF) provides mechanisms to
install, manipulate, and delete the configuration of network devices. install, manipulate, and delete the configuration of network devices.
This document describes how to use the Transport Layer Security (TLS) This document describes how to use the Transport Layer Security (TLS)
protocol with mutual X.509 authentication to secure the exchange of protocol with mutual X.509 authentication to secure the exchange of
NETCONF messages. This revision of RFC 5539 documents the new NETCONF messages. This revision of RFC 5539 documents the new
message framing used by NETCONF 1.1 and it obsoletes RFC 5539. message framing used by NETCONF 1.1 and it obsoletes RFC 5539.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 16, 2015. This Internet-Draft will expire on October 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Connection Initiation . . . . . . . . . . . . . . . . . . . . 3 2. Connection Initiation . . . . . . . . . . . . . . . . . . . . 3
3. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 3 3. Message Framing . . . . . . . . . . . . . . . . . . . . . . . 3
4. Connection Closure . . . . . . . . . . . . . . . . . . . . . 3 4. Connection Closure . . . . . . . . . . . . . . . . . . . . . 3
5. Certificate Validation . . . . . . . . . . . . . . . . . . . 4 5. Certificate Validation . . . . . . . . . . . . . . . . . . . 3
6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4 6. Server Identity . . . . . . . . . . . . . . . . . . . . . . . 4
7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4 7. Client Identity . . . . . . . . . . . . . . . . . . . . . . . 4
8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 9 Appendix A. Changes from RFC 5539 . . . . . . . . . . . . . . . 9
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
B.1. draft-ietf-netconf-rfc5539bis-07 . . . . . . . . . . . . 9
B.2. draft-ietf-netconf-rfc5539bis-06 . . . . . . . . . . . . 9
B.3. draft-ietf-netconf-rfc5539bis-05 . . . . . . . . . . . . 10
B.4. draft-ietf-netconf-rfc5539bis-04 . . . . . . . . . . . . 10
B.5. draft-ietf-netconf-rfc5539bis-03 . . . . . . . . . . . . 10
B.6. draft-ietf-netconf-rfc5539bis-02 . . . . . . . . . . . . 10
B.7. draft-ietf-netconf-rfc5539bis-00 . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The NETCONF protocol [RFC6241] defines a mechanism through which a The NETCONF protocol [RFC6241] defines a mechanism through which a
network device can be managed. NETCONF is connection-oriented, network device can be managed. NETCONF is connection-oriented,
requiring a persistent connection between peers. This connection requiring a persistent connection between peers. This connection
must provide integrity, confidentiality, peer authentication, and must provide integrity, confidentiality, peer authentication, and
reliable, sequenced data delivery. reliable, sequenced data delivery.
This document defines how NETCONF messages can be exchanged over This document defines how NETCONF messages can be exchanged over
skipping to change at page 3, line 17 skipping to change at page 3, line 13
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Connection Initiation 2. Connection Initiation
The peer acting as the NETCONF client MUST act as the TLS client. The peer acting as the NETCONF client MUST act as the TLS client.
The TLS client actively opens the TLS connection and the TLS server The TLS client actively opens the TLS connection and the TLS server
passively listens for the incoming TLS connections. The well-known passively listens for the incoming TLS connections. The well-known
TCP port number 6513 is used by NETCONF servers to listen for TCP TCP port number 6513 is used by NETCONF servers to listen for TCP
connections established by NETCONF over TLS clients. The TLS client connections established by NETCONF over TLS clients. The TLS client
MUST send the TLS ClientHello message to begin the TLS handshake. MUST send the TLS ClientHello message to begin the TLS handshake.
Once the TLS handshake has finished, the client and the server MAY The TLS server MUST send a CertificateRequest in order to request a
begin to exchange NETCONF messages. Client and server identity certificate from the TLS client. Once the TLS handshake has
verification is done before the NETCONF <hello> message is sent. finished, the client and the server MAY begin to exchange NETCONF
This means that the identity verification is completed before the messages. Client and server identity verification is done before the
NETCONF session is started. NETCONF <hello> message is sent. This means that the identity
verification is completed before the NETCONF session is started.
3. Message Framing 3. Message Framing
All NETCONF messages MUST be sent as TLS "application data". It is All NETCONF messages MUST be sent as TLS "application data". It is
possible that multiple NETCONF messages be contained in one TLS possible that multiple NETCONF messages be contained in one TLS
record, or that a NETCONF message be transferred in multiple TLS record, or that a NETCONF message be transferred in multiple TLS
records. records.
The previous version [RFC5539] of this document used the framing The previous version of this document [RFC5539] used the framing
sequence defined in [RFC4742], under the assumption that it could not sequence defined in [RFC4742]. This version aligns with [RFC6242]
be found in well-formed XML documents. However, this assumption is and adopts the framing protocol defined in [RFC6242] as follows:
not correct [RFC6242]. In order to solve this problem, this document
adopts the framing protocol defined in [RFC6242] as follows:
The NETCONF <hello> message MUST be followed by the character The NETCONF <hello> message MUST be followed by the character
sequence ]]>]]>. Upon reception of the <hello> message, the peers sequence ]]>]]>. Upon reception of the <hello> message, the peers
inspect the announced capabilities. If the :base:1.1 capability is inspect the announced capabilities. If the :base:1.1 capability is
advertised by both peers, the chunked framing mechanism defined in advertised by both peers, the chunked framing mechanism defined in
Section 4.2 of [RFC6242] is used for the remainder of the NETCONF Section 4.2 of [RFC6242] is used for the remainder of the NETCONF
session. Otherwise, the old end-of-message-based mechanism (see session. Otherwise, the old end-of-message-based mechanism (see
Section 4.3 of [RFC6242]) is used. Section 4.3 of [RFC6242]) is used.
4. Connection Closure 4. Connection Closure
skipping to change at page 4, line 10 skipping to change at page 4, line 4
closed using the <close-session> operation. When the NETCONF server closed using the <close-session> operation. When the NETCONF server
processes a <close-session> operation, the NETCONF server SHALL processes a <close-session> operation, the NETCONF server SHALL
respond and close the TLS session as described in Section 7.2.1 of respond and close the TLS session as described in Section 7.2.1 of
[RFC5246]. [RFC5246].
5. Certificate Validation 5. Certificate Validation
Both peers MUST use X.509 certificate path validation [RFC5280] to Both peers MUST use X.509 certificate path validation [RFC5280] to
verify the integrity of the certificate presented by the peer. The verify the integrity of the certificate presented by the peer. The
presented X.509 certificate may also be considered valid if it presented X.509 certificate may also be considered valid if it
matches a locally configured certificate fingerprint. If X.509 matches one obtained by another trusted mechanism, such as using a
certificate path validation fails and the presented X.509 certificate locally configured certificate fingerprint. If X.509 certificate
does not match a locally configured certificate fingerprint, the path validation fails and the presented X.509 certificate does not
connection MUST be terminated as defined in [RFC5246]. match a certificate obtained by a trusted mechanism, the connection
MUST be terminated as defined in [RFC5246].
6. Server Identity 6. Server Identity
The NETCONF client MUST check the identity of the server according to The NETCONF client MUST check the identity of the server according to
Section 6 of [RFC6125]. Section 6 of [RFC6125].
7. Client Identity 7. Client Identity
The NETCONF server MUST verify the identity of the NETCONF client to The NETCONF server MUST verify the identity of the NETCONF client to
ensure that the incoming request to establish a NETCONF session is ensure that the incoming request to establish a NETCONF session is
skipping to change at page 6, line 6 skipping to change at page 5, line 51
type 'common-name'). The CommonName is converted to UTF-8 type 'common-name'). The CommonName is converted to UTF-8
encoding. The usage of CommonNames is deprecated and users encoding. The usage of CommonNames is deprecated and users
are encouraged to use subjectAltName mapping methods are encouraged to use subjectAltName mapping methods
instead. instead.
(d) If it is impossible to determine a username from the list (d) If it is impossible to determine a username from the list
entry's data combined with the data presented in the entry's data combined with the data presented in the
certificate, then additional list entries MUST be searched certificate, then additional list entries MUST be searched
looking for another potential match. Similarily, if the looking for another potential match. Similarily, if the
username does not comply to the NETCONF requirements on username does not comply to the NETCONF requirements on
usernames [RFC6241] (i.e., the username is not representable in usernames [RFC6241], then additional list entries MUST be
XML), then additional list entries MUST be searched looking for searched looking for another potential match. If there are no
another potential match. If there are no further list entries, further list entries, the TLS session MUST be terminated.
the TLS session MUST be terminated.
The username provided by the NETCONF over TLS implementation will be The username provided by the NETCONF over TLS implementation will be
made available to the NETCONF message layer as the NETCONF username made available to the NETCONF message layer as the NETCONF username
without modification. without modification.
The NETCONF server configuration data model
[I-D.ietf-netconf-server-model] covers NETCONF over TLS and provides
further details such as certificate fingerprint formats exposed to
network configuration systems.
8. Cipher Suites 8. Cipher Suites
Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
support the mandatory-to-implement cipher suite. Implementations MAY support the mandatory-to-implement cipher suite. Implementations MAY
implement additional TLS cipher suites that provide mutual implement additional TLS cipher suites that provide mutual
authentication [RFC5246] and confidentiality as required by NETCONF authentication [RFC5246] and confidentiality as required by NETCONF
[RFC6241]. Implementations SHOULD follow the recommendations given [RFC6241]. Implementations SHOULD follow the recommendations given
in [I-D.ietf-uta-tls-bcp]. in [I-D.ietf-uta-tls-bcp].
9. Security Considerations 9. Security Considerations
skipping to change at page 6, line 41 skipping to change at page 6, line 42
Configuration or state data may include sensitive information, such Configuration or state data may include sensitive information, such
as usernames or security keys. So, NETCONF requires communications as usernames or security keys. So, NETCONF requires communications
channels that provide strong encryption for data privacy. This channels that provide strong encryption for data privacy. This
document defines a NETCONF over TLS mapping that provides for support document defines a NETCONF over TLS mapping that provides for support
of strong encryption and authentication. The security considerations of strong encryption and authentication. The security considerations
for TLS [RFC5246] and NETCONF [RFC6241] apply here as well. for TLS [RFC5246] and NETCONF [RFC6241] apply here as well.
NETCONF over TLS requires mutual authentication. Neither side should NETCONF over TLS requires mutual authentication. Neither side should
establish a NETCONF over TLS connection with an unknown, unexpected, establish a NETCONF over TLS connection with an unknown, unexpected,
or incorrect identity on the opposite side. This document does not or incorrect identity on the opposite side. Note that the decision
support third-party authentication (e.g., backend Authentication, whether a certificate presented by the client is accepted can depend
Authorization, and Accounting (AAA) servers) due to the fact that TLS on whether a trusted CA certificate is white listed (see Section 7).
does not specify this way of authentication and that NETCONF depends If deployments make use of this option, it is recommended that the
on the transport protocol for the authentication service. If third- white listed CA certificate is used only to issue certificates that
party authentication is needed, the SSH transport can be used. are used for accessing NETCONF servers. Should the CA certificate be
used to issue certificates for other purposes, then all certificates
created for other purposes will be accepted by a NETCONF server as
well, which is likely not suitable.
This document does not support third-party authentication (e.g.,
backend Authentication, Authorization, and Accounting (AAA) servers)
due to the fact that TLS does not specify this way of authentication
and that NETCONF depends on the transport protocol for the
authentication service. If third-party authentication is needed, the
SSH transport [RFC6242] can be used.
RFC 5539 assumes that the end-of-message (EOM) sequence, ]]>]]>, RFC 5539 assumes that the end-of-message (EOM) sequence, ]]>]]>,
cannot appear in any well-formed XML document, which turned out to be cannot appear in any well-formed XML document, which turned out to be
mistaken. The EOM sequence can cause operational problems and open mistaken. The EOM sequence can cause operational problems and open
space for attacks if sent deliberately in NETCONF messages. It is space for attacks if sent deliberately in NETCONF messages. It is
however believed that the associated threat is not very high. This however believed that the associated threat is not very high. This
document still uses the EOM sequence for the initial <hello> message document still uses the EOM sequence for the initial <hello> message
to avoid incompatibility with existing implementations. When both to avoid incompatibility with existing implementations. When both
peers implement :base:1.1 capability, a proper framing protocol peers implement :base:1.1 capability, a proper framing protocol
(chunked framing mechanism; see Section 3) is used for the rest of (chunked framing mechanism; see Section 3) is used for the rest of
skipping to change at page 7, line 33 skipping to change at page 7, line 45
Description: NETCONF over TLS Description: NETCONF over TLS
Reference: RFC XXXX Reference: RFC XXXX
Port Number: 6513 Port Number: 6513
[[CREF1: RFC Editor: Please replace XXXX above with the allocated RFC [[CREF1: RFC Editor: Please replace XXXX above with the allocated RFC
number and remove this comment. --JS]] number and remove this comment. --JS]]
11. Acknowledgements 11. Acknowledgements
The authors like to acknowledge Martin Bjorklund, Olivier Coupelon, The authors like to acknowledge Martin Bjorklund, Olivier Coupelon,
Mehmet Ersue, Miao Fuyou, Ibrahim Hajjeh, David Harrington, Alfred Mehmet Ersue, Stephen Farrell, Miao Fuyou, Ibrahim Hajjeh, David
Hoenes, Simon Josefsson, Tom Petch, Eric Rescorla, Dan Romascanu, Harrington, Sam Hartman, Alfred Hoenes, Simon Josefsson, Barry Leiba,
Kent Watsen, Bert Wijnen and the NETCONF mailing list members for Tom Petch, Eric Rescorla, Dan Romascanu, Kent Watsen, Bert Wijnen,
their comments on this document. Charlie Kaufman, Pasi Eronen, and Stefan Winter and the NETCONF mailing list members for their comments
Tim Polk provided a thorough review of previous versions of this on this document. Charlie Kaufman, Pasi Eronen, and Tim Polk
document. provided a thorough review of previous versions of this document.
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Juergen Schoenwaelder was partly funded by Flamingo, a Network of
Excellence project (ICT-318488) supported by the European Commission Excellence project (ICT-318488) supported by the European Commission
under its Seventh Framework Programme. under its Seventh Framework Programme.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-uta-tls-bcp] [I-D.ietf-uta-tls-bcp]
skipping to change at page 8, line 43 skipping to change at page 9, line 4
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. Shell (SSH)", RFC 6242, June 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011. 6335, August 2011.
12.2. Informative References 12.2. Informative References
[I-D.ietf-netconf-server-model]
Watsen, K. and J. Schoenwaelder, "NETCONF Server and
RESTCONF Server Configuration Models", draft-ietf-netconf-
server-model-06 (work in progress), February 2015.
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF
Configuration Protocol over Secure SHell (SSH)", RFC 4742, Configuration Protocol over Secure SHell (SSH)", RFC 4742,
December 2006. December 2006.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
RFC 5539, May 2009. RFC 5539, May 2009.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)", Model for the Simple Network Management Protocol (SNMP)",
skipping to change at page 9, line 29 skipping to change at page 9, line 40
o Removed redundant text that can be found in the TLS and NETCONF o Removed redundant text that can be found in the TLS and NETCONF
specifications and restructured the text. Alignment with specifications and restructured the text. Alignment with
[RFC6125]. [RFC6125].
o Added a high-level description how NETCONF usernames are derived o Added a high-level description how NETCONF usernames are derived
from certificates. from certificates.
o Removed the reference to BEEP. o Removed the reference to BEEP.
Appendix B. Change Log
[[CREF2: RFC Editor: Please remove this appendix before publication.
--JS]]
B.1. draft-ietf-netconf-rfc5539bis-07
o Limited the scope of the document to TLS with mutual X.509
authentication.
o Added a high-level description how NETCONF usernames are extracted
from certificates.
o Editorial changes
B.2. draft-ietf-netconf-rfc5539bis-06
o Removed all call-home related text.
o Removed redundant text as discussed at the Toronto IETF meeting.
B.3. draft-ietf-netconf-rfc5539bis-05
o Removed the YANG configuration data model since it became a
separate document.
o Added reference to RFC 3234 plus editorial updates.
B.4. draft-ietf-netconf-rfc5539bis-04
o Added the applicability statement proposed by Stephen Hanna.
o Added call-home configuration objects and a tls-call-home feature.
o Rewrote the text such that the role swap happens right after the
TCP connection has been established.
B.5. draft-ietf-netconf-rfc5539bis-03
o Added support for call home (allocation of a new port number,
rewrote text to allow a NETCONF client to be a TLS server and a
NETCONF server to be a TLS client).
o Merged sections 2 and 3 into a new section 2 and restructured the
text.
o Extended the IANA considerations section.
o Using the cert-to-name mapping grouping from the SNMP
configuration data model and updated the examples.
o Creating an extensible set of YANG (sub)modules for NETCONF
following the (sub)module structure of the SNMP configuration
model.
B.6. draft-ietf-netconf-rfc5539bis-02
o Addressed remaining issues identified at IETF 85
* Harmonized the cert-maps container of the YANG module in this
draft with the tlstm container in the ietf-snmp-tls sub-module
specified in draft-ietf-netmod-snmp-cfg. Replaced the children
of the cert-maps container with the children copied from the
tlstm container of the ietf-snmp-tls sub-module.
* Added an overview of data model in the ietf-netconf-tls YANG
module.
* Added example configurations.
o Addessed issues posted on NETCONF WG E-mail list.
o Deleted the superfluous tls container that was directly below the
netconf-config container.
o Added a statement to the text indicating that support for mapping
X.509 certificates to NETCONF usernames is optional. This is
analogous to existing text indicating that support for mapping
pre-shared keys to NETCONF usernames is optional. Resource-
constrained systems now can omit support for mapping X.509
certificates to NETCONF usernames and still comply with this
specification.
o Clarified the document structure by promoting the sections of the
document related to the data model.
o Updated author's addresses.
B.7. draft-ietf-netconf-rfc5539bis-00
o Remove the reference to BEEP.
o Rename host-part to domain-part in the description of RFC822.
Authors' Addresses Authors' Addresses
Mohamad Badra Mohamad Badra
Zayed University Zayed University
Email: mbadra@gmail.com Email: mbadra@gmail.com
Alan Luchuk Alan Luchuk
SNMP Research, Inc. SNMP Research, Inc.
3001 Kimberlin Heights Road 3001 Kimberlin Heights Road
Knoxville, TN 37920 Knoxville, TN 37920
USA USA
Phone: +1 865 573 1434 Phone: +1 865 573 1434
Email: luchuk@snmp.com Email: luchuk@snmp.com
URI: http://www.snmp.com/ URI: http://www.snmp.com/
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
28759 Bremen 28759 Bremen
Germany Germany
Phone: +49 421 200 3587 Phone: +49 421 200 3587
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
URI: http://www.jacobs-university.de/ URI: http://www.jacobs-university.de/
 End of changes. 18 change blocks. 
140 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--x+6KMIRAuhnl3hBn-- From nobody Fri Apr 10 14:03:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8EC1A88FC; Fri, 10 Apr 2015 14:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRW_g4A6nXum; Fri, 10 Apr 2015 14:03:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B90C41A89B8; Fri, 10 Apr 2015 14:03:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410210341.11430.76001.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 14:03:41 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-10.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:03:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication Authors : Mohamad Badra Alan Luchuk Juergen Schoenwaelder Filename : draft-ietf-netconf-rfc5539bis-10.txt Pages : 10 Date : 2015-04-10 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 10 14:04:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8051E1A898A; Fri, 10 Apr 2015 14:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfw42NIkkDFg; Fri, 10 Apr 2015 14:03:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BE21A89C4; Fri, 10 Apr 2015 14:03:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410210341.11430.86084.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 14:03:41 -0700 Archived-At: Subject: [Netconf] New Version Notification - draft-ietf-netconf-rfc5539bis-10.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:03:57 -0000 A new version (-10) has been submitted for draft-ietf-netconf-rfc5539bis: http://www.ietf.org/internet-drafts/draft-ietf-netconf-rfc5539bis-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc5539bis-10 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. IETF Secretariat. From nobody Fri Apr 10 15:39:58 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C793A1A885C; Fri, 10 Apr 2015 13:16:23 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC06F1A8854 for ; Fri, 10 Apr 2015 13:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdNg_SOFjqGD for ; Fri, 10 Apr 2015 13:16:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5565A1A8849 for ; Fri, 10 Apr 2015 13:16:22 -0700 (PDT) Received: from nagasaki.bogus.com ([2001:418:1::81]:61568) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgfLh-0001VF-D6 for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Fri, 10 Apr 2015 13:16:22 -0700 Received: from [IPv6:2600:1012:b169:ac12:3048:73ad:8e33:90d0] ([IPv6:2600:1012:b169:ac12:3048:73ad:8e33:90d0]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3AKG1Uf081488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Apr 2015 20:16:04 GMT (envelope-from joelja@bogus.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (12D508) In-Reply-To: <20150410080106.GA2282@elstar.local> Date: Fri, 10 Apr 2015 13:15:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <28548700-D021-4C0E-8B49-F471FE94D752@bogus.com> References: <20150410080106.GA2282@elstar.local> To: Juergen Schoenwaelder X-SA-Exim-Connect-IP: 2001:418:1::81 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: joelja@bogus.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150410201622.5565A1A8849@ietfa.amsl.com> Resent-Date: Fri, 10 Apr 2015 13:16:22 -0700 (PDT) Resent-From: joelja@bogus.com Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 10 Apr 2015 15:39:49 -0700 Cc: "draft-ietf-netconf-rfc5539bis.all@tools.ietf.org" Subject: Re: [Netconf] document status X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 20:16:24 -0000 Looks good, if you post the we'll announce it on the mailing and ship to the= EMC editor. The state was to keep it from being published prior to this. Thanks Joel Sent from my iPhone > On Apr 10, 2015, at 01:01, Juergen Schoenwaelder wrote: >=20 > Hi, >=20 > I see that the document is now in the state "Approved-announcement to > be sent::Point Raised - writeup needed". Not sure what the point > raised is but I thought I let you know that I do have a version of the > I-D that incorporates all the edits that were suggested during the > IESG chat preparation phase. I am happy to post that any time in case > this helps. Attached is the rfcdiff. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > From nobody Fri Apr 10 15:39:59 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 335AF1A898A; Fri, 10 Apr 2015 14:05:05 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1452F1A897B for ; Fri, 10 Apr 2015 14:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRmfA0kFfm3q for ; Fri, 10 Apr 2015 14:05:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6151A898A for ; Fri, 10 Apr 2015 14:04:59 -0700 (PDT) Received: from atlas3.jacobs-university.de ([212.201.44.18]:60294) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ygg6k-0002gV-5t for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Fri, 10 Apr 2015 14:04:59 -0700 Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CE2F51102; Fri, 10 Apr 2015 23:04:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dr3mjWgtacKU; Fri, 10 Apr 2015 23:04:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 10 Apr 2015 23:04:52 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBA8D2002B; Fri, 10 Apr 2015 23:04:51 +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 VSl4Fh_P2PMq; Fri, 10 Apr 2015 23:04:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC9CF20013; Fri, 10 Apr 2015 23:04:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5265432BE750; Fri, 10 Apr 2015 23:04:48 +0200 (CEST) Date: Fri, 10 Apr 2015 23:04:48 +0200 From: Juergen Schoenwaelder To: Joel Jaeggli Message-ID: <20150410210448.GA6048@elstar.local> References: <20150410080106.GA2282@elstar.local> <28548700-D021-4C0E-8B49-F471FE94D752@bogus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28548700-D021-4C0E-8B49-F471FE94D752@bogus.com> User-Agent: Mutt/1.4.2.3i X-SA-Exim-Connect-IP: 212.201.44.18 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: j.schoenwaelder@jacobs-university.de X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150410210459.4D6151A898A@ietfa.amsl.com> Resent-Date: Fri, 10 Apr 2015 14:04:59 -0700 (PDT) Resent-From: j.schoenwaelder@jacobs-university.de Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 10 Apr 2015 15:39:52 -0700 Cc: "draft-ietf-netconf-rfc5539bis.all@tools.ietf.org" Subject: Re: [Netconf] document status X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 21:05:05 -0000 On Fri, Apr 10, 2015 at 01:15:56PM -0700, Joel Jaeggli wrote: > Looks good, if you post the we'll announce it on the mailing and ship to the EMC editor. > I have posted -10. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 10 15:55:10 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992091B2E12 for ; Fri, 10 Apr 2015 15:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUaZ94OY41Oa for ; Fri, 10 Apr 2015 15:55:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3751B2E11 for ; Fri, 10 Apr 2015 15:55:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t3AMt5tp023547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Apr 2015 22:55:05 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t3AMt4k8027745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 11 Apr 2015 00:55:05 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 11 Apr 2015 00:55:04 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.118]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0224.002; Sat, 11 Apr 2015 00:55:04 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: IESG state changed to Approved-announcement to be sent WAS:FW: ID Tracker State Update Notice: Thread-Index: AQHQc+FhNSag2Vw4BEKk09GaZs/OpQ== Date: Fri, 10 Apr 2015 22:55:03 +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.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1224 X-purgate-ID: 151667::1428706505-0000328B-EC5D845F/0/0 Archived-At: Subject: [Netconf] IESG state changed to Approved-announcement to be sent WAS:FW: ID Tracker State Update Notice: X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 22:55:09 -0000 Q29uZ3JhdHMgdG8gTkVUQ09ORiBXRyBmb3IgdGhpcyBhY2hpZXZlbWVudCBhbmQgdGhlIGh1Z2Ug c3RlcCBmb3J3YXJkIHRvIGdldCBORVRDT05GIGJldHRlciBhbmQgdXNlZnVsLg0KU3BlY2lhbCB0 aGFua3MgdG8gdGhlIGVkaXRvcnMgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBNb2hhbWFkIEJhZHJh IGFuZCBBbGFuIEx1Y2h1ayBmb3IgdGhlaXIgZWZmb3J0cyB0byBnZXQgdGhlIGRyYWZ0IGZpbmFs aXplZCBhbmQgYXBwcm92ZWQuDQoNCk1laG1ldCAmIE1haGVzaA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogZXh0IElFVEYgU2VjcmV0YXJpYXQgW21haWx0bzppZXRmLXNlY3Jl dGFyaWF0LXJlcGx5QGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwOSwgMjAxNSA4 OjAxIFBNDQpUbzogZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzU1MzliaXNAaWV0Zi5vcmc7IG5ldGNv bmYtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpcy5hZEBpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzU1MzliaXMuc2hlcGhlcmRAaWV0Zi5vcmc7IEVy c3VlLCBNZWhtZXQgKE5va2lhIC0gREUvTXVuaWNoKTsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVj dDogSUQgVHJhY2tlciBTdGF0ZSBVcGRhdGUgTm90aWNlOiA8ZHJhZnQtaWV0Zi1uZXRjb25mLXJm YzU1MzliaXMtMDkudHh0Pg0KDQpJRVNHIHN0YXRlIGNoYW5nZWQgdG8gQXBwcm92ZWQtYW5ub3Vu Y2VtZW50IHRvIGJlIHNlbnQ6OlBvaW50IFJhaXNlZCAtIHdyaXRldXAgbmVlZGVkIGZyb20gSUVT RyBFdmFsdWF0aW9uDQpJRCBUcmFja2VyIFVSTDogaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpcy8NCg0K From nobody Fri Apr 10 19:14:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47421A6EDB for ; Fri, 10 Apr 2015 19:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57n34ngn5XNu for ; Fri, 10 Apr 2015 19:14:55 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E1C1A6F0A for ; Fri, 10 Apr 2015 19:14:54 -0700 (PDT) Received: by laat2 with SMTP id t2so24761175laa.1 for ; Fri, 10 Apr 2015 19:14: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=ptzPySG2EFIeYAyNnaVFT8dcYsvSnfELoHKYv4RUARk=; b=K2pYpw52f29c3UAJpuBADuIa9VTXY1dKdafHzV8JHcdq7H879SJeDfLbDZCU9bgtEj Rom0DV6Hi/P5NUGAIC72ah96sPBgJVspHMVEk5C61g49O9KLbQHlR0B0RkGFx7wNoA9b E/vaTUoY1/UBp9dQPF2h1+m1gFcICob/GJ54v39wjDjiEFQZxBa8vnT00txcjRLELvY7 44Ymmby7ypedbXeTKPEEi+LoU7pRfs0RorQhxeTtaS1MpHLV94EByFkVDfReadlpIG26 12EltA40GpSL2v0fRx462S2Xi3N8MmxprwVPHMGR5PpooRvd+SK5oy7j6NHY7cA7/TeF 4Sng== X-Gm-Message-State: ALoCoQlBqXfjTqGn4vPHnQsRR/sH2+svqJW3LulMF1HroMDVXhJtNWQJNz8osPJik8pXcmZ0ob/i MIME-Version: 1.0 X-Received: by 10.112.205.103 with SMTP id lf7mr3733740lbc.37.1428718493002; Fri, 10 Apr 2015 19:14:53 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 10 Apr 2015 19:14:52 -0700 (PDT) In-Reply-To: <20150410.082116.663742183631558687.mbj@tail-f.com> References: <20150410.082116.663742183631558687.mbj@tail-f.com> Date: Fri, 10 Apr 2015 19:14:52 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Netconf Subject: Re: [Netconf] subtree filter normalization X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 02:14:57 -0000 On Thu, Apr 9, 2015 at 11:21 PM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: >> Hi, >> >> I'm trying to rewrite some NETCONF code, and I cannot >> tell if RFC 6241 allows for subtree filters to be normalized. >> It is not clear how certain usage should be processed. >> >> This text in 6.1, para 1 seems to suggest the filter does not >> need to follow a schema. >> >> The server does not need to utilize any data-model- >> specific semantics during processing, allowing for simple and >> centralized implementation strategies. >> >> >> I am not convinced NETCONF is correct here >> (and I wrote a lot of this subtree text ;-) >> IMO the server MUST return schema-valid content >> for YANG modules it advertises, >> and that requires the filter to be interpreted >> and the response content normalized. > > This would indeed have been better! But that's not what the spec > says... > > >> F0 is the well-behaved example on pg 25: >> >> F0: >> >> >> >> >> fred >> >> >> >> >> >> The RFC does not say if the 'name' select node can be repeated, >> as in F1: >> >> F1: >> >> >> >> >> fred >> barney >> >> >> >> >> >> 6.2.5, bullet 2 says these are ANDed together, so >> filter F1 would not match anything. IMO this should only >> apply to different select leafs. Duplicate select leafs >> should be ORed together. This will help normalization. > > I think the current behavior is correct. If you want to get both fred > and barney you have to do: > > > fred > > > barney > > > I don't think there is any reason for a special case when the select > node is duplicated. It can actually be confusing. Assuming the list > has two keys, what would this mean: > > > martin > andy > bjorklund > bierman > > >> F2: >> >> >> >> >> fred >> >> >> fred >> >> >> >> >> >> Is F2 allowed? (container user repeated) >> Is the server required to collapse the entries for return >> so the rpc-reply is schema-valid? > > In this case the natural reply is schema-valid: > > > > > fred > ... > > > fred > ... > > > > > >> Same applies to F3 and F4. > > The way the spec is written (data model agnostic), you'd get a reply > that mimics the filter input. The only way for a server to collapse > the s into a single element, is to utilize the fact that > "users" is a container. Right. Also applies to some other details: - generate list keys first - generate identityref - generate instance-identifier I think the client would prefer schema-valid data, so if the server can understand the schema, it should figure out how to normalize the data and remove duplicates. fred<.name> It would be OK for the server to return all user entries then return the entry for 'fred' again? I guess this could be called garbage-in/garbage-out and not a problem. A future RFC update should add examples that do not follow the example schema, and make it clear this is mandatory to support.. Andy > >> F3: variant of F2 >> >> >> >> >> fred >> >> >> >> >> fred >> >> >> >> >> >> F4: variant of F2 >> >> >> >> >> fred >> >> >> >> >> >> >> barney >> >> >> >> > > > /martin From nobody Sat Apr 11 12:35:11 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9A4A21A874A; Sat, 11 Apr 2015 10:55:46 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803E81A8740 for ; Sat, 11 Apr 2015 10:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxH0PzX-HwS3 for ; Sat, 11 Apr 2015 10:55:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9E01A701A for ; Sat, 11 Apr 2015 10:55:45 -0700 (PDT) Received: from nagasaki.bogus.com ([2001:418:1::81]:16342) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgzdA-0007pM-KD for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Sat, 11 Apr 2015 10:55:45 -0700 Received: from mb-aye.local (160.sub-70-211-1.myvzw.com [70.211.1.160]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3BHtV0a099634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 11 Apr 2015 17:55:31 GMT (envelope-from joelja@bogus.com) To: Juergen Schoenwaelder references: <20150410080106.GA2282@elstar.local> <28548700-D021-4C0E-8B49-F471FE94D752@bogus.com> <20150410210448.GA6048@elstar.local> From: joel jaeggli message-id: <5529600C.1040304@bogus.com> Date: Sat, 11 Apr 2015 10:55:24 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: <20150410210448.GA6048@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2w6HRmf9opHov7EXBLHPSFExco2MaMfto" X-SA-Exim-Connect-IP: 2001:418:1::81 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: joelja@bogus.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150411175545.4F9E01A701A@ietfa.amsl.com> Resent-Date: Sat, 11 Apr 2015 10:55:45 -0700 (PDT) Resent-From: joelja@bogus.com Archived-At: Archived-At: X-Mailman-Approved-At: Sat, 11 Apr 2015 12:35:10 -0700 Cc: "draft-ietf-netconf-rfc5539bis.all@tools.ietf.org" Subject: Re: [Netconf] document status X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 17:55:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2w6HRmf9opHov7EXBLHPSFExco2MaMfto Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/10/15 2:04 PM, Juergen Schoenwaelder wrote: > On Fri, Apr 10, 2015 at 01:15:56PM -0700, Joel Jaeggli wrote: >> Looks good, if you post the we'll announce it on the mailing and ship = to the EMC editor. >> >=20 > I have posted -10. Thanks, Benoit, when you get back since you still hold the token on this would you kick it into the rfc editor queue. joel > /js >=20 --2w6HRmf9opHov7EXBLHPSFExco2MaMfto Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUpYA0ACgkQ8AA1q7Z/VrJzRwCfT/yRQkKRW7OpfuqQLTubnnAF xToAnjcYrWsgLJ6sxsPL2sHmJU5UtEnu =J4Sg -----END PGP SIGNATURE----- --2w6HRmf9opHov7EXBLHPSFExco2MaMfto-- From nobody Sat Apr 11 12:35:12 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5A9311B2A70; Sat, 11 Apr 2015 12:33:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAD21B2A26 for ; Sat, 11 Apr 2015 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbzttY0Ii1eh for ; Sat, 11 Apr 2015 12:33:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE21C1B2A23 for ; Sat, 11 Apr 2015 12:33:53 -0700 (PDT) Received: from aer-iport-1.cisco.com ([173.38.203.51]:28543) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Yh1A8-00007O-3e for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Sat, 11 Apr 2015 12:33:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=386; q=dns/txt; s=iport; t=1428780832; x=1429990432; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/YVui3wkD+P/Ff0b8dJMcU0PrVmQM60ULT2CpzVFgGM=; b=c+ilo5PBMPoD7mAt4TeQPsTaqUvmWzqmmDB/YCZXy7gIFw6rlTEleB4G LRA0GDT67n71B/C5TgKAwd8QaWO+sfXeK5xNLal0cF3+x4ZIFwtzcdeZA 1KjtTZqshUtt4LqFsTOEU79qNFDeQPRY66Ucq3N2Knklv4k6JjGydcjRm o=; X-IronPort-AV: E=Sophos;i="5.11,562,1422921600"; d="scan'208";a="445068310" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 11 Apr 2015 19:33:38 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3BJXcGN018979; Sat, 11 Apr 2015 19:33:38 GMT Message-ID: <55292C5A.2040901@cisco.com> Date: Sat, 11 Apr 2015 16:14:50 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Juergen Schoenwaelder , Joel Jaeggli References: <20150410080106.GA2282@elstar.local> <28548700-D021-4C0E-8B49-F471FE94D752@bogus.com> <20150410210448.GA6048@elstar.local> In-Reply-To: <20150410210448.GA6048@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 173.38.203.51 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: bclaise@cisco.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150411193353.AE21C1B2A23@ietfa.amsl.com> Resent-Date: Sat, 11 Apr 2015 12:33:53 -0700 (PDT) Resent-From: bclaise@cisco.com Archived-At: Archived-At: X-Mailman-Approved-At: Sat, 11 Apr 2015 12:35:10 -0700 Cc: "draft-ietf-netconf-rfc5539bis.all@tools.ietf.org" Subject: Re: [Netconf] document status X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 19:33:55 -0000 On 10/04/2015 23:04, Juergen Schoenwaelder wrote: > On Fri, Apr 10, 2015 at 01:15:56PM -0700, Joel Jaeggli wrote: >> Looks good, if you post the we'll announce it on the mailing and ship to the EMC editor. >> > I have posted -10. Let me follow up from here. I'll double-check everything (probably on Monday) and move it to the RFC-editor queue. Regards, Benoit > > /js > From nobody Mon Apr 13 12:43:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C851A19FA; Mon, 13 Apr 2015 12:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ava4cLXg0rU0; Mon, 13 Apr 2015 12:43:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5F41A1A17; Mon, 13 Apr 2015 12:43:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150413194345.9631.63249.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 12:43:45 -0700 Archived-At: Cc: joelja@bogus.com, netconf@ietf.org, ipr-announce@ietf.org Subject: [Netconf] IPR Disclosure Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-netconf-zerotouch X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 19:43:48 -0000 Dear Kent Watsen, Joe Clarke, Mikael Abrahamsson: An IPR disclosure that pertains to your Internet-Draft entitled "Zero Touch Provisioning for NETCONF Call Home (ZeroTouch)" (draft-ietf-netconf-zerotouch) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2581/). The title of the IPR disclosure is "Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-netconf-zerotouch" Thank you IETF Secretariat From nobody Tue Apr 14 06:55:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A7E1A007A; Tue, 14 Apr 2015 06:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR43_Uj0imUB; Tue, 14 Apr 2015 06:55:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 771B71A0070; Tue, 14 Apr 2015 06:55:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414135512.6220.83651.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 06:55:12 -0700 From: IETF Secretariat Archived-At: Subject: [Netconf] ID Tracker State Update Notice: X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:55:17 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ From nobody Tue Apr 14 06:55:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A8C1A0070; Tue, 14 Apr 2015 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NskKw9UAPiKL; Tue, 14 Apr 2015 06:55:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8BB1A00B6; Tue, 14 Apr 2015 06:55:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414135512.6220.94863.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 06:55:12 -0700 Archived-At: Cc: netconf mailing list , netconf chair , RFC Editor Subject: [Netconf] Protocol Action: 'Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication' to Proposed Standard (draft-ietf-netconf-rfc5539bis-10.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:55:22 -0000 The IESG has approved the following document: - 'Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication' (draft-ietf-netconf-rfc5539bis-10.txt) as Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ Technical Summary The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange of NETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539. Working Group Summary Since the start of the work end of 2012, the focus has been changed to remove call home functionality and to split the server configuration data model into another draft. There were no controversial or difficult decisions. Document Quality This document revises RFC 5539 by defining the chunked framing mechanism used if both peers adverstise the :base:1.1 capability. As such all implementations of NETCONF 1.1 that want to use TLS with mutual X.509 authentication have to use this new framing format. The document is clear and well written, and it has been extensively reviewed. There are implementations with different code base of different draft versions available. Personnel The document shepherd is Mehmet Ersue. The responsible AD is Benoit Claise. The IANA Expert(s) for the registries in this document are Joe Touch; Eliot Lear, Allison Mankin, Markku Kojo, Kumiko Ono, Martin Stiemerling, Lars Eggert, Alexey Melnikov, Wes Eddy, and Alexander Zimmermann From nobody Tue Apr 14 07:11:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15981A8AF6; Tue, 14 Apr 2015 07:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aSfeKctP1qB; Tue, 14 Apr 2015 07:11:37 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8251A9152; Tue, 14 Apr 2015 07:11:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t3EEBNYk010866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Apr 2015 14:11:23 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t3EEBNg9011318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 16:11:23 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 14 Apr 2015 16:11:22 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.118]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0224.002; Tue, 14 Apr 2015 16:11:22 +0200 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: ext IETF Secretariat , "draft-ietf-netconf-rfc5539bis@ietf.org" , "netconf-chairs@ietf.org" , "draft-ietf-netconf-rfc5539bis.ad@ietf.org" , "draft-ietf-netconf-rfc5539bis.shepherd@ietf.org" , "netconf@ietf.org" Thread-Topic: ID Tracker State Update Notice: Thread-Index: AQHQdrqk0vR/5/x6x0is3Gz5/0kWIZ1MiKOg Date: Tue, 14 Apr 2015 14:11:22 +0000 Message-ID: References: <20150414135512.6220.83651.idtracker@ietfa.amsl.com> In-Reply-To: <20150414135512.6220.83651.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1106 X-purgate-ID: 151667::1429020683-0000328B-CB64DACE/0/0 Archived-At: Subject: Re: [Netconf] ID Tracker State Update Notice: X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:11:39 -0000 Q29uZ3JhdHMgdG8gdGhlIHdvcmtpbmcgZ3JvdXAgZm9yIHRoZSBhY2hpZXZlbWVudCBvZiB0aGlz IG1pbGVzdG9uZSENCg0KU3BlY2lhbCB0aGFua3MgdG8gb3VyIGRldm90ZWQgV0cgbWVtYmVycyB3 aG8gcmV2aWV3ZWQsIGNvbW1lbnRlZCwgYW5kIGVkaXRlZCBvdmVyIHRoZSB0aW1lIHJlcGVhdGVk bHkuDQoNCkNoZWVycywgDQpNZWhtZXQgDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGV4dCBJRVRGIFNlY3JldGFyaWF0IFttYWlsdG86aWV0Zi1zZWNyZXRhcmlhdC1yZXBs eUBpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNCwgMjAxNSAzOjU1IFBNDQpUbzog ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzU1MzliaXNAaWV0Zi5vcmc7IG5ldGNvbmYtY2hhaXJzQGll dGYub3JnOyBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNTUzOWJpcy5hZEBpZXRmLm9yZzsgZHJhZnQt aWV0Zi1uZXRjb25mLXJmYzU1MzliaXMuc2hlcGhlcmRAaWV0Zi5vcmc7IEVyc3VlLCBNZWhtZXQg KE5va2lhIC0gREUvTXVuaWNoKTsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogSUQgVHJhY2tl ciBTdGF0ZSBVcGRhdGUgTm90aWNlOiA8ZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzU1MzliaXMtMTAu dHh0Pg0KDQpJRVNHIGhhcyBhcHByb3ZlZCB0aGUgZG9jdW1lbnQgYW5kIHN0YXRlIGhhcyBiZWVu IGNoYW5nZWQgdG8gQXBwcm92ZWQtYW5ub3VuY2VtZW50IHNlbnQNCklEIFRyYWNrZXIgVVJMOiBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1yZmM1NTM5 YmlzLw0KDQo= From nobody Tue Apr 14 15:16:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127F91A8798; Tue, 14 Apr 2015 15:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g43Z-M0wKK2k; Tue, 14 Apr 2015 15:16:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A281A876F; Tue, 14 Apr 2015 15:16:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414221625.21771.4127.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 15:16:25 -0700 From: IETF Secretariat Archived-At: Subject: [Netconf] ID Tracker State Update Notice: X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 22:16:26 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ From nobody Tue Apr 14 16:05:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BAC1B304D; Tue, 14 Apr 2015 16:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjqdSB-aRPa3; Tue, 14 Apr 2015 16:05:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AED31B304B; Tue, 14 Apr 2015 16:05:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414230526.12273.32385.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 16:05:26 -0700 From: IETF Secretariat Archived-At: Subject: [Netconf] ID Tracker State Update Notice: X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 23:05:27 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ From nobody Wed Apr 15 10:55:42 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934FC1B2ED2 for ; Wed, 15 Apr 2015 10:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13IlnUzPiZq8 for ; Wed, 15 Apr 2015 10:55:34 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A511A01F4 for ; Wed, 15 Apr 2015 10:55:34 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id t3FHskqS013121; Wed, 15 Apr 2015 10:55:22 -0700 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0b-0016f401.pphosted.com with ESMTP id 1ts7h2upgs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2015 10:55:21 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by SC-OWA04.marvell.com (10.93.76.33) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 15 Apr 2015 10:55:20 -0700 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 15 Apr 2015 20:55:13 +0300 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1044.021; Wed, 15 Apr 2015 20:55:13 +0300 From: Tal Mizrahi To: "netconf@ietf.org" Thread-Topic: Updated draft-mm-netconf-time-capability-04 Thread-Index: AdB3oueMF4dHIRkvQ2WManeoD+WZFg== Date: Wed, 15 Apr 2015 17:55:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.203.130.14] Content-Type: multipart/alternative; boundary="_000_dff01581726e4f57b072a6957e81f34eILEXCH01marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-15_06:2015-04-15,2015-04-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504150148 Archived-At: Cc: Tal Mizrahi , Yoram Moses Subject: [Netconf] Updated draft-mm-netconf-time-capability-04 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 17:55:40 -0000 --_000_dff01581726e4f57b072a6957e81f34eILEXCH01marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Feedbacks will be welcome. Even short feedbacks such as "I think this draft is useful" will be welcome= . https://tools.ietf.org/html/draft-mm-netconf-time-capability-04 We want to thank all the people who reviewed previous versions of the draft= and sent comments. We would appreciate if you could go over the comment li= st below and make sure we have addressed your comments. A short overview =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This draft defines a time capability in NETCONF; an RPC can include an elem= ent that defines its scheduled time of execution. This allows a few interesting use cases: - Network-wide commit (see https://www.ietf.org/proceedings/92/slides/slide= s-92-netconf-13.pdf). - Time-based network update (see http://www.ietf.org/proceedings/87/slides/= slides-87-netconf-1.pdf). As a side note, the ability to perform time-triggered network updates has b= een recently added to the OpenFlow protocol v1.5. NETCONF is not OpenFlow. Yet, the ability to perform time-triggered operati= ons seems to be a basic and important tool for a network configuration prot= ocol. Changes compared to draft 03 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The most notable changes compared to version 03 are: - The notification message now uses a unique , rather than usi= ng the message-id of the corresponding RPC. - The security considerations section was extended to include the content o= f http://www.ops.ietf.org/netconf/yang-security-considerations.txt. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Feedback from previous versions of the draft =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We received a lot of feedback from the NETCONF WG about the previous drafts= . Below are some of the main questions and comments, and for each one a descr= iption of how we addressed it. Please let us know if we missed something, or if you believe we did not add= ress some of the issues below. Comments from Andy: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >This solution seems to send 1 >when the operation is finally executed. How does the client know the oper= ation >was scheduled successfully? IMO, a better solution would be an immediate > (scheduled OK) and the execution results sent in a . (1) Agreed. In the current draft the server sends a notification once it receives a sch= eduled commit. This allows the client to know that the scheduled RPC was re= ceived. Then, when the RPC is completed, the server sends the RPC reply. >IMO, YANG date-and-time is better time parameter than 'seconds since 1970'= . >It is already supported by NETCONF servers. (2) Agreed. The current draft uses date-and-time. >How does a client cancel an operation? >Can client A cancel operations for client B, >assuming client A is allowed to invoke ? (3) Agreed. The current draft includes a cancel-schedule RPC. >I agree it is better to synch the start-times, not the finish-times. >That is too difficult to predict. (4) Agreed. The current draft defines to be the start time of the oper= ation. >IMO, 1 micro-second resolution is enough, not nano-seconds. (5) Understood. Draft 00 used the IEEE 1588 time format, which may have imp= lied that a nanosecond accuracy is expected. The current draft uses the date-and-time format. Nanosecond accuracy is not= required (neither explicitly, nor implicitly). The draft intentionally does not define an accuracy requirement, as in the = Network Time Protocol (NTP), and the Precision Time Protocol (PTP). The cu= rrent draft defines time as a tool. Accuracy will depend on the application= , implementation, and network size/topology. >Can you explain why the server returns the execution time for operations >since that doesn't seem to have anything to do with the problem statement >of starting operations at a coordinated time? (6) The servers returns the actual execution time to the client. This allow= s the client to receive feedback about when the actual operation was comple= ted compared to its intended scheduled time. This is an important mechanism= , as it provides the client information about the accuracy of the scheduled= RPC. >How do clients monitor what operations are pending? >What if the NACM rules change while the operation is pending? >What if a session is lost or closed before its scheduled operation is star= ted? >What if the server reboots while operations are pending? (7) Essentially, all these questions boil down the discussion we have on 3.= 6. Near Future Scheduling vs. Far Future Scheduling. We focus on near future scheduling. Quoting from section 3.6: "Near future scheduling guarantees that external events such as the example= s above have a low probability of occurring during the sched-max-future per= iod, and even when they do, the period of inconsistency is limited to sched= -max-future, which is a short period of time." >There are lots of operational problems with delayed operations. >I like the solution in draft-kwatsen-conditional-enablement-00 >better than this one because it covers more use-cases and >seems more tractable. (8) Continuing the point of (7), I believe the solution of draft-kwatsen-co= nditional-enablement-00 was optimized for far future scheduling, while our = draft is optimized for near future scheduling. We believe once you think ab= out the current draft in the context of near future scheduling, the operati= onal problems you mention are not an issue. Comments from Joe: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >I think there should be a way to query the server's current time to make s= ure the client and server agree. >In terms of this draft should there be some text that explain this as a po= tential concern with suggestions (9) Agreed. This is discussed in Section 3.3 of the current draft. >In terms of things that need to be done to the draft, I think it needs a >section on error-handling specifically around what happens if the clock >on the device is insane or if a time is specified in the past. I think >there needs to be some direction about how far in the future one can set >the timer or how many pending operations can be outstanding. (10) Agreed. This is currently discussed in Section 3.5. Comments from Martin: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >date-and-time (and RFC 3339) allow finer granularity than a 10th of a >second. (11) Agreed. The current draft uses date-and-time. Comments from Juergen: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >If nobody seriously can implement a certain precision, implementations >will simply cheat and the consequence of that in the long run is often >worse than having a less fine grained precision that is implementable >and thus meaningful. (12) Understood. Please see (5). Comments from Jonathan: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >wouldn't it be more appropriate to define the scheduled time >as "the time at which the RPC should be executed (13) Agreed. Please see (4). >How would you see this working when supporting the configuration >of a set of network elements in a robust and transaction-oriented way, >where the operation should complete on all devices or be fully reversed? (14) Agreed. The current draft includes the cancel-schedule RPC, which allows a network-= wide all-or-none operation. Comments from Radek: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Even if you do on a single leaf, it can represent a >complex operation with a hardly predictable duration. (15) Agreed. The current draft defines to be the start time of the oper= ation. Comments from Balazs: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Can you give us some examples of applications today that use coordinated >configuration? What precision is used today? (16) Some interesting uses cases are given at the beginning of this email. >IMHO anything better then millisec precision is unrealistic, unneeded or >rather just wishfull thinking. (17) Understood. Please see (5). >The idea that scheduled time should be the required completion time for >an operation is unfortunate. That assumes a device can estimate how long a >complex configuration operation will take. (18) Agreed. Please see (4). >there must be a way to check pending scheduled operations. >if a management user is removed/undefined will his pending operations also >be removed, or will they stand there and fail at the scheduled execution t= ime? >What if my session is closed e.g. by a network timeout? (19) Understood. We believe these comments boil down to the discussion of (= 7), which is discussed in Section 3.6 of the current draft. >often a configuration session will consist of multiple operations: >(lock, edit-config, unlock), (lock, discard-changes, edit-config, commit, = unlock). >If I can only schedule single operations does that mean I can not use lock= ? If I >want to schedule commit, should I keep the running and the candidate >configurations locked to ensure I commit, what I really want? (20) Multiple operations can use multiple scheduled RPCs with different exe= cution times. The TIME of these RPCs can determine the order of their execu= tion. Similarly, the lock can be used with a schedule, so you do not need t= o lock the datastore in advance. Regards, Tal and Yoram. --_000_dff01581726e4f57b072a6957e81f34eILEXCH01marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Feedbacks will be welcome.

Even short feedbacks such as “I think this dra= ft is useful” will be welcome.

 

https://tools.ietf.org/html/draft-mm-netconf-time-c= apability-04

 

We want to thank all the people who reviewed previou= s versions of the draft and sent comments. We would appreciate if you could= go over the comment list below and make sure we have addressed your commen= ts.

 

 

A short overview

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This draft defines a time capability in NETCONF; an = RPC can include an element that defines its scheduled time of execution.

This allows a few interesting use cases: =

- Network-wide commit (see https://www.ietf.org/proceedings/92/slides/slides-92-netconf-13.p= df).

- Time-based network update (see http://www.ietf.org/proceedings/87/slides/slides-87-netconf-1.pdf).

 

As a side note, the ability to perform time-triggere= d network updates has been recently added to the OpenFlow protocol v1.5.

NETCONF is not OpenFlow. Yet, the ability to perform= time-triggered operations seems to be a basic and important tool for a net= work configuration protocol.

 

 

Changes compared to draft 03

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

The most notable changes compared to version 03 are:=

- The notification message now uses a unique <sch= edule-id>, rather than using the message-id of the corresponding RPC.

- The security considerations section was extended t= o include the content of http://www.ops.ietf.org/netconf/yang-security-considerations.txt.

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Feedback from previous versions of the draft

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

We received a lot of feedback from the NETCONF WG ab= out the previous drafts.

Below are some of the main questions and comments, a= nd for each one a description of how we addressed it.

Please let us know if we missed something, or if you= believe we did not address some of the issues below.

 

 

Comments from Andy:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

>This solution seems to send 1 <rpc-reply><= o:p>

>when the operation is finally executed.  Ho= w does the client know the operation

>was scheduled successfully?  IMO, a better = solution would be an immediate

><rpc-reply> (scheduled OK) and the executi= on results sent in a <notification>.

 

(1) Agreed.

In the current draft the server sends a notification= once it receives a scheduled commit. This allows the client to know that t= he scheduled RPC was received. Then, when the RPC is completed, the server = sends the RPC reply.

 

>IMO, YANG date-and-time is better time parameter= than 'seconds since 1970'.

>It is already supported by NETCONF servers.=

 

(2) Agreed.

The current draft uses date-and-time.

 

>How does a client cancel an operation?

>Can client A cancel operations for client B,

>assuming client A is allowed to invoke <kill-= session>?

 

(3) Agreed.

The current draft includes a cancel-schedule RPC.

 

>I agree it is better to synch the start-times, n= ot the finish-times.

>That is too difficult to predict.

 

(4) Agreed.

The current draft defines <scheduled-time> to = be the start time of the operation.

 

>IMO, 1 micro-second resolution is enough, not na= no-seconds.

 

(5) Understood. Draft 00 used the IEEE 1588 time for= mat, which may have implied that a nanosecond accuracy is expected.

The current draft uses the date-and-time format. Nan= osecond accuracy is not required (neither explicitly, nor implicitly).=

The draft intentionally does not define an accuracy = requirement, as in the Network Time Protocol (NTP), and the Precision Time = Protocol (PTP).  The current draft defines time as a tool. Accuracy wi= ll depend on the application, implementation, and network size/topology.

 

>Can you explain why the server returns the execu= tion time for operations

>since that doesn't seem to have anything to do w= ith the problem statement

>of starting operations at a coordinated time?

 

(6) The servers returns the actual execution time to= the client. This allows the client to receive feedback about when the actu= al operation was completed compared to its intended scheduled time. This is= an important mechanism, as it provides the client information about the accuracy of the scheduled RPC.=

 

>How do clients monitor what operations are pendi= ng?

>What if the NACM rules change while the operatio= n is pending?

>What if a session is lost or closed before its s= cheduled operation is started?

>What if the server reboots while operations are = pending?

 

(7) Essentially, all these questions boil down the d= iscussion we have on 3.6. Near Future Scheduling vs. Far Future Scheduling.=

We focus on near future scheduling. Quoting from sec= tion 3.6:

“Near future scheduling guarantees that extern= al events such as the examples above have a low probability of occurring du= ring the sched-max-future period, and even when they do, the period of inco= nsistency is limited to sched-max-future, which is a short period of time.”

 

>There are lots of operational problems with dela= yed operations.

>I like the solution in draft-kwatsen-conditional= -enablement-00

>better than this one because it covers more use-= cases and

>seems more tractable.

 

(8) Continuing the point of (7), I believe the solut= ion of draft-kwatsen-conditional-enablement-00 was optimized for far future= scheduling, while our draft is optimized for near future scheduling. We be= lieve once you think about the current draft in the context of near future scheduling, the operational problems y= ou mention are not an issue.

 

 

Comments from Joe:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>I think there should be a way to query the serve= r's current time to make sure the client and server agree.

>In terms of this draft should there be some text= that explain this as a potential concern with suggestions

 

(9) Agreed.

This is discussed in Section 3.3 of the current draf= t.

 

>In terms of things that need to be done to the d= raft, I think it needs a

>section on error-handling specifically around wh= at happens if the clock

>on the device is insane or if a time is specifie= d in the past.  I think

>there needs to be some direction about how far i= n the future one can set

>the timer or how many pending operations can be = outstanding.

 

(10) Agreed.

This is currently discussed in Section 3.5.

 

Comments from Martin:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

>date-and-time (and RFC 3339) allow finer granula= rity than a 10th of a

>second.

 

(11) Agreed.

The current draft uses date-and-time.

 

Comments from Juergen:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

>If nobody seriously can implement a certain prec= ision, implementations

>will simply cheat and the consequence of that in= the long run is often

>worse than having a less fine grained precision = that is implementable

>and thus meaningful.

 

(12) Understood. Please see (5).

 

Comments from Jonathan:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

>wouldn't it be more appropriate to define the sc= heduled time

>as "the time at which the RPC should be exe= cuted

 

(13) Agreed. Please see (4).

 

 

>How would you see this working when supporting t= he configuration

>of a set of network elements in a robust and tra= nsaction-oriented way,

>where the operation should complete on all devic= es or be fully reversed?

 

(14) Agreed.

The current draft includes the cancel-schedule RPC, = which allows a network-wide all-or-none operation.

 

Comments from Radek:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

>Even if you do <edit-config> on a single l= eaf, it can represent a

>complex operation with a hardly predictable dura= tion.

 

(15) Agreed.

The current draft defines <scheduled-time> to = be the start time of the operation.

 

Comments from Balazs:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

 

>Can you give us some examples of applications to= day that use coordinated

>configuration? What precision is used today?

 

(16) Some interesting uses cases are given at the be= ginning of this email.

 

>IMHO anything better then millisec precision is = unrealistic, unneeded or

>rather just wishfull thinking.

 

(17) Understood. Please see (5).

 

>The idea that scheduled time should be the requi= red completion time for

>an operation is unfortunate. That assumes a devi= ce can estimate how long a

>complex configuration operation will take.<= /o:p>

 

(18) Agreed. Please see (4).

 

>there must be a way to check pending scheduled o= perations.

>if a management user is removed/undefined will h= is pending operations also

>be removed, or will they stand there and fail at= the scheduled execution time?

>What if my session is closed e.g. by a network t= imeout?

 

(19) Understood. We believe these comments boil down= to the discussion of (7), which is discussed in Section 3.6 of the current= draft.

 

>often a configuration session will consist of mu= ltiple operations:

>(lock, edit-config, unlock), (lock, discard-chan= ges, edit-config, commit, unlock).

>If I can only schedule single operations does th= at mean I can not use lock? If I

>want to schedule commit, should I keep the runni= ng and the candidate

>configurations locked to ensure I commit, what I= really want?

 

(20) Multiple operations can use multiple scheduled = RPCs with different execution times. The TIME of these RPCs can determine t= he order of their execution. Similarly, the lock can be used with a schedul= e, so you do not need to lock the datastore in advance.

 

 

Regards,

Tal and Yoram.

 

--_000_dff01581726e4f57b072a6957e81f34eILEXCH01marvellcom_-- From nobody Wed Apr 15 14:05:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F361A901D; Wed, 15 Apr 2015 14:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY_3k_IyxQ7Q; Wed, 15 Apr 2015 14:05:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3060D1A9024; Wed, 15 Apr 2015 14:05:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150415210530.4264.21492.idtracker@ietfa.amsl.com> Date: Wed, 15 Apr 2015 14:05:30 -0700 From: IETF Secretariat Archived-At: Subject: [Netconf] ID Tracker State Update Notice: X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 21:05:45 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ From nobody Wed Apr 15 14:09:32 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F09F11A8AFE; Wed, 15 Apr 2015 13:57:06 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B6D1A8AFA for ; Wed, 15 Apr 2015 13:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuBk-aMC1jGf for ; Wed, 15 Apr 2015 13:57:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BB01A8AF5 for ; Wed, 15 Apr 2015 13:57:05 -0700 (PDT) Received: from smtp01.icann.org ([192.0.33.81]:47643 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YiUMr-0004G8-9s for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Wed, 15 Apr 2015 13:57:05 -0700 Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3FKuxtK013415 for ; Wed, 15 Apr 2015 20:56:59 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 93C66C207C3; Wed, 15 Apr 2015 20:56:59 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <20150414135512.6220.54929.idtracker@ietfa.amsl.com> References: <20150414135512.6220.54929.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #818826 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 15 Apr 2015 20:56:59 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 192.0.33.81 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: iana-shared@icann.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150415205705.C6BB01A8AF5@ietfa.amsl.com> Resent-Date: Wed, 15 Apr 2015 13:57:05 -0700 (PDT) Resent-From: iana-shared@icann.org Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 15 Apr 2015 14:09:30 -0700 Cc: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Subject: [Netconf] [IANA #818826] Protocol Action: 'Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication' to Proposed Standard (draft-ietf-netconf-rfc5539bis-10.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-approval@iana.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 20:57:07 -0000 Dear Authors: ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED We've completed the IANA Actions for the following RFC-to-be: draft-ietf-netconf-rfc5539bis-10 IANA has listed the IESG as the assignee, the IETF Chair as the contact, and this document as the only reference for the following assignment in the Service Name and Transport Protocol Port Number Registry: Service Name: netconf-tls Port Number: 6513 Transport Protocol: tcp Description: NETCONF over TLS Assignee: [IESG] Contact: [IETF_Chair] Modification Date: 2015-04-15 Reference: [RFC-ietf-netconf-rfc5539bis-10] Please see http://www.iana.org/assignments/service-names-port-numbers Please let us know whether the above IANA Actions look OK. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's IANA Actions are complete. (If this document has a team of authors, one reply on behalf of everyone will suffice.) We'll update the reference when the RFC Editor notifies us that they've assigned a number. Thanks, Amanda Baber IANA Request Specialist ICANN From nobody Wed Apr 15 14:09:52 2015 Return-Path: X-Original-To: expand-draft-ietf-netconf-rfc5539bis.all@virtual.ietf.org Delivered-To: netconf@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 92E351A901E; Wed, 15 Apr 2015 14:08:36 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netconf-rfc5539bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D341A8F49 for ; Wed, 15 Apr 2015 14:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAELVocEa2p5 for ; Wed, 15 Apr 2015 14:08:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0781A901E for ; Wed, 15 Apr 2015 14:08:33 -0700 (PDT) Received: from atlas3.jacobs-university.de ([212.201.44.18]:35503) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YiUXw-0006Qj-JW for draft-ietf-netconf-rfc5539bis.all@tools.ietf.org; Wed, 15 Apr 2015 14:08:33 -0700 Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 06A3D8F8; Wed, 15 Apr 2015 23:08:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AXdpL7oqP4ic; Wed, 15 Apr 2015 23:08:08 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 15 Apr 2015 23:08:24 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDEAB2002C; Wed, 15 Apr 2015 23:08:24 +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 wG1-XMUuipO5; Wed, 15 Apr 2015 23:08:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D74EC20013; Wed, 15 Apr 2015 23:08:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 683D132C2BD8; Wed, 15 Apr 2015 23:08:22 +0200 (CEST) Date: Wed, 15 Apr 2015 23:08:21 +0200 From: Juergen Schoenwaelder To: Amanda Baber via RT Message-ID: <20150415210821.GA3663@elstar.local> References: <20150414135512.6220.54929.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-SA-Exim-Connect-IP: 212.201.44.18 X-SA-Exim-Rcpt-To: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org X-SA-Exim-Mail-From: j.schoenwaelder@jacobs-university.de X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-netconf-rfc5539bis.all@ietf.org Resent-Message-Id: <20150415210833.EB0781A901E@ietfa.amsl.com> Resent-Date: Wed, 15 Apr 2015 14:08:33 -0700 (PDT) Resent-From: j.schoenwaelder@jacobs-university.de Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 15 Apr 2015 14:09:52 -0700 Cc: draft-ietf-netconf-rfc5539bis.all@tools.ietf.org Subject: Re: [Netconf] [IANA #818826] Protocol Action: 'Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication' to Proposed Standard (draft-ietf-netconf-rfc5539bis-10.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 21:08:36 -0000 Hi, this all looks good. /js On Wed, Apr 15, 2015 at 08:56:59PM +0000, Amanda Baber via RT wrote: > Dear Authors: > > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > > We've completed the IANA Actions for the following RFC-to-be: > > draft-ietf-netconf-rfc5539bis-10 > > IANA has listed the IESG as the assignee, the IETF Chair as the contact, and this document as the only reference for the following assignment in the Service Name and Transport Protocol Port Number Registry: > > Service Name: netconf-tls > Port Number: 6513 > Transport Protocol: tcp > Description: NETCONF over TLS > Assignee: [IESG] > Contact: [IETF_Chair] > Modification Date: 2015-04-15 > Reference: [RFC-ietf-netconf-rfc5539bis-10] > > Please see > http://www.iana.org/assignments/service-names-port-numbers > > > Please let us know whether the above IANA Actions look OK. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's IANA Actions are complete. (If this document has a team of authors, one reply on behalf of everyone will suffice.) > > We'll update the reference when the RFC Editor notifies us that they've assigned a number. > > Thanks, > > Amanda Baber > IANA Request Specialist > ICANN > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 15 15:06:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090971A9135; Wed, 15 Apr 2015 15:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TudhYDymSpKZ; Wed, 15 Apr 2015 15:06:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA08D1A1A79; Wed, 15 Apr 2015 15:06:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150415220606.29705.87966.idtracker@ietfa.amsl.com> Date: Wed, 15 Apr 2015 15:06:06 -0700 From: IETF Secretariat Archived-At: Subject: [Netconf] ID Tracker State Update Notice: X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 22:06:08 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ From nobody Thu Apr 16 01:13:11 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14E21B2BDD for ; Thu, 16 Apr 2015 01:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMeBp9bnsXiq for ; Thu, 16 Apr 2015 01:13:07 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E675E1B2BDF for ; Thu, 16 Apr 2015 01:13:06 -0700 (PDT) Authentication-Results: jacobs-university.de; dkim=none (message not signed) header.d=none; Received: from pc6 (81.151.162.168) by DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) with Microsoft SMTP Server (TLS) id 15.1.136.25; Thu, 16 Apr 2015 08:11:13 +0000 Message-ID: <008b01d0781c$b8b918a0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <20150410080106.GA2282@elstar.local> Date: Thu, 16 Apr 2015 09:09:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.162.168] X-ClientProxiedBy: DB5PR02CA0008.eurprd02.prod.outlook.com (25.161.237.18) To DBXPR07MB061.eurprd07.prod.outlook.com (10.242.147.14) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB061; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51444003)(13464003)(377454003)(51704005)(122386002)(40100003)(4001540100001)(86362001)(87976001)(81686999)(1556002)(61296003)(76176999)(50986999)(44736004)(81816999)(50226001)(50466002)(5890100001)(14496001)(110136001)(47776003)(62966003)(66066001)(42186005)(19580395003)(116806002)(46102003)(19580405001)(77156002)(84392001)(23756003)(92566002)(77096005)(33646002)(62236002)(44716002)(1456003)(15975445007)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB061; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DBXPR07MB061; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB061; X-Forefront-PRVS: 0548586081 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2015 08:11:13.3724 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB061 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] document status X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 08:13:10 -0000 Juergen Too late for this I-D but picking up on Kathleen's comments, I suggest an informative paragraph to the NETCONF I-Ds explaining the various documents and their roles. You don't need it, I don't, at present, but if the likes of Kathleen do, then I think that we should provide it. Something like, NETCONF requires a secure transport with mutual authentication. Originally, three were specified, SSH, SOAP and BEEP. Later, TLS was added while SOAP and BEEP are now of Historic status. The WG also took on the work of RESTCONF, 'netconf-restconf', a NETCONF-like protocol over HTTP. Along the way, TLS as a transport for NETCONF gained and lost means of authentication other than X.509 certificates, while SSH added authentication using X.509 certificates to the more common use of host keys. The specification of SSH as a transport was revised in 2011, that for TLS in 2015, notably to change the method of delineating messages. A requirement arose for the NETCONF server to initiate the TCP connection, to be the TCP client, after which it would still become the NETCONF, and SSH or TLS, server. Initially referred to as 'reverse-ssh', this is now known as 'call home' and the document, 'netconf-call-home', covers both TLS and SSH, NETCONF and RESTCONF. 'netconf-server-model' defines a YANG model for the configuration of a server, again both for NETCONF and RESTCONF, and for TLS and SSH. Finally, 'netconf-zero-touch' builds on this to facilitate the initial configuration of a remote device. (with references as appropriate) Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: Sent: Friday, April 10, 2015 9:01 AM > Hi, > > I see that the document is now in the state "Approved-announcement to > be sent::Point Raised - writeup needed". Not sure what the point > raised is but I thought I let you know that I do have a version of the > I-D that incorporates all the edits that were suggested during the > IESG chat preparation phase. I am happy to post that any time in case > this helps. Attached is the rfcdiff. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > From nobody Thu Apr 16 01:47:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16651B2C5D for ; Thu, 16 Apr 2015 01:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnhyFGCHYjck for ; Thu, 16 Apr 2015 01:47:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C61A1B2C5A for ; Thu, 16 Apr 2015 01:47:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0981013FA; Thu, 16 Apr 2015 10:47:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id V7-dnC4T9gsM; Thu, 16 Apr 2015 10:47:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 16 Apr 2015 10:47:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3CD6C20035; Thu, 16 Apr 2015 10:47:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id j5hrlIsePaJW; Thu, 16 Apr 2015 10:47:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A265F20033; Thu, 16 Apr 2015 10:47:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DC46432C32F8; Thu, 16 Apr 2015 10:47:41 +0200 (CEST) Date: Thu, 16 Apr 2015 10:47:41 +0200 From: Juergen Schoenwaelder To: "t. petch" Message-ID: <20150416084741.GA4846@elstar.local> Mail-Followup-To: "t. petch" , netconf@ietf.org References: <20150410080106.GA2282@elstar.local> <008b01d0781c$b8b918a0$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008b01d0781c$b8b918a0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] document status X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 08:47:49 -0000 I might agree that we need _at some point in time_ an overview like _document_, something similar to RFC 3410. Given where we are, I think it is too early to write this and we also have higher priority things to _finish_. (As Andy said, starting things is easy, finishing things is hard.) I think I disagree that we should add the history of how things evolved to all NETCONF I-Ds. Until we have the cycles and the document stability to write something equivalent to RFC 3410, perhaps some text on the NETCONF wiki would work as well. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From taden@microsoft.com Wed Apr 15 17:14:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118041ACE69 for ; Wed, 15 Apr 2015 17:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdOG4rXwa6Ku for ; Wed, 15 Apr 2015 17:14:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C91C1ACE5F for ; Wed, 15 Apr 2015 17:13:54 -0700 (PDT) Received: from DM2PR03MB384.namprd03.prod.outlook.com (10.141.55.25) by DM2PR03MB382.namprd03.prod.outlook.com (10.141.55.14) with Microsoft SMTP Server (TLS) id 15.1.136.17; Thu, 16 Apr 2015 00:13:52 +0000 Received: from DM2PR03MB384.namprd03.prod.outlook.com ([10.141.55.25]) by DM2PR03MB384.namprd03.prod.outlook.com ([10.141.55.25]) with mapi id 15.01.0136.026; Thu, 16 Apr 2015 00:13:52 +0000 From: Tao Deng To: "netconf@ietf.org" Thread-Topic: RESTCONF event notification question Thread-Index: AdB32g6HkA/ImnnjSN22mGr1xWIWug== Date: Thu, 16 Apr 2015 00:13:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [167.220.24.15] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB382; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(66654002)(86362001)(76576001)(86612001)(50986999)(54356999)(74316001)(19580395003)(19300405004)(2501003)(46102003)(110136001)(450100001)(229853001)(107886001)(2351001)(77096005)(77156002)(2420400003)(62966003)(102836002)(15975445007)(19617315012)(16236675004)(92566002)(19625215002)(40100003)(122556002)(66066001)(2656002)(87936001)(33656002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB382; H:DM2PR03MB384.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DM2PR03MB382; BCL:0; PCL:0; RULEID:; SRVR:DM2PR03MB382; x-forefront-prvs: 0548586081 Content-Type: multipart/alternative; boundary="_000_DM2PR03MB3841B83D8B99332D67FAC21BBE40DM2PR03MB384namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2015 00:13:52.4160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB382 Archived-At: X-Mailman-Approved-At: Thu, 16 Apr 2015 03:43:59 -0700 Subject: [Netconf] RESTCONF event notification question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 00:26:56 -0000 --_000_DM2PR03MB3841B83D8B99332D67FAC21BBE40DM2PR03MB384namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear RESTCONF Experts, I am reading the IETF RESTCONF draft revision 4 (here) and have a question regarding the f= ollowing text in Section 6.3 regarding asynchronous event notification from= the server: The server will treat the connection as an event stream, using the Server S= ent Events [W3C.CR-eventsource-20121211] transport strateg= y. Could you please help advise if WebSocket qualifies as the above mentioned = strategy for asynchronous event notification? I see ODL uses WebSocket for = that purpose. Or do we have to use a technology as specified by that W3C li= nk? Many thanks, Tao --_000_DM2PR03MB3841B83D8B99332D67FAC21BBE40DM2PR03MB384namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear RESTCONF Experts,

 

I am reading the IETF RESTCONF draft revision 4 (here) and have a question regarding the following text in Section 6.3 regardin= g asynchronous event notification from the server:

 

The server will t=
reat the connection as an event stream, using the Server Sent Events [W3C.CR-eventsource-20121211] transport strategy.=

 

Could you please help advise if WebSocket qualifies = as the above mentioned strategy for asynchronous event notification? I see = ODL uses WebSocket for that purpose. Or do we have to use a technology as s= pecified by that W3C link?

 

Many thanks,

Tao

 

--_000_DM2PR03MB3841B83D8B99332D67FAC21BBE40DM2PR03MB384namprd_-- From nobody Thu Apr 16 11:06:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFCE1B2EC4; Thu, 16 Apr 2015 11:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8weBxsOpbEa; Thu, 16 Apr 2015 11:06:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB91B2EB3; Thu, 16 Apr 2015 11:06:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416180614.23655.20758.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 11:06:14 -0700 From: IETF Secretariat Archived-At: Subject: [Netconf] ID Tracker State Update Notice: X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:06:26 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ From nobody Thu Apr 16 13:12:00 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADAE1B360A for ; Thu, 16 Apr 2015 13:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4HBESPm9BHl for ; Thu, 16 Apr 2015 13:11:58 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D8BF31B35EA for ; Thu, 16 Apr 2015 13:11:57 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 608D31AE0B12; Thu, 16 Apr 2015 22:11:56 +0200 (CEST) Date: Thu, 16 Apr 2015 22:12:25 +0200 (CEST) Message-Id: <20150416.221225.1156963166127782650.mbj@tail-f.com> To: taden@microsoft.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF event notification question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 20:12:00 -0000 Hi, Tao Deng wrote: > Dear RESTCONF Experts, > > I am reading the IETF RESTCONF draft revision 4 > (here) and > have a question regarding the following text in Section 6.3 regarding > asynchronous event notification from the server: > > > The server will treat the connection as an event stream, using the > Server Sent Events > [W3C.CR-eventsource-20121211] > transport strategy. > > Could you please help advise if WebSocket qualifies as the above > mentioned strategy for asynchronous event notification? I see ODL uses > WebSocket for that purpose. Or do we have to use a technology as > specified by that W3C link? Are you saying that the current specification is not clear, or are you asking for changing RESTCONF to use WebSockets instead of Server Sent Events? /martin From nobody Thu Apr 16 13:21:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C782A1B3664 for ; Thu, 16 Apr 2015 13:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyD0gDBWWn9i for ; Thu, 16 Apr 2015 13:21:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0141.outbound.protection.outlook.com [65.55.169.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95731B3613 for ; Thu, 16 Apr 2015 13:21:22 -0700 (PDT) Received: from DM2PR03MB384.namprd03.prod.outlook.com (10.141.55.25) by DM2PR03MB383.namprd03.prod.outlook.com (10.141.55.17) with Microsoft SMTP Server (TLS) id 15.1.136.17; Thu, 16 Apr 2015 20:21:21 +0000 Received: from DM2PR03MB384.namprd03.prod.outlook.com ([10.141.55.25]) by DM2PR03MB384.namprd03.prod.outlook.com ([10.141.55.25]) with mapi id 15.01.0136.026; Thu, 16 Apr 2015 20:21:21 +0000 From: Tao Deng To: Martin Bjorklund Thread-Topic: [Netconf] RESTCONF event notification question Thread-Index: AdB32g6HkA/ImnnjSN22mGr1xWIWugAp5j6AAAAMLLA= Date: Thu, 16 Apr 2015 20:21:21 +0000 Message-ID: References: <20150416.221225.1156963166127782650.mbj@tail-f.com> In-Reply-To: <20150416.221225.1156963166127782650.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tail-f.com; dkim=none (message not signed) header.d=none; x-originating-ip: [167.220.24.15] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB383; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(51704005)(164054003)(2900100001)(77096005)(15975445007)(102836002)(74316001)(33656002)(19580395003)(2950100001)(62966003)(92566002)(77156002)(46102003)(40100003)(2656002)(99286002)(66066001)(76176999)(54356999)(50986999)(86362001)(76576001)(110136001)(86612001)(19580405001)(87936001)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB383; H:DM2PR03MB384.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR03MB383; BCL:0; PCL:0; RULEID:; SRVR:DM2PR03MB383; x-forefront-prvs: 0548586081 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2015 20:21:21.0268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB383 Archived-At: Cc: "GNS SDN Engineering \(Moffett Towers\)" , "netconf@ietf.org" Subject: Re: [Netconf] RESTCONF event notification question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 20:21:24 -0000 Hi Martin, Thanks for your response. Let me clarify my question. The RESTCONF draft is= very specific about what technology to use for the asynchronous event noti= fication: Server Sent Event. I meant to ask, are other similar technologies= (such as WebSocket) allowed to be used for this purpose? Open Daylight SDN controller uses WebSocket for their implementation of a R= ESTCONF server. By doing so, is this a non-conformance to the standard draf= t? Thanks, Tao -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Thursday, April 16, 2015 1:12 PM To: Tao Deng Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF event notification question Hi, Tao Deng wrote: > Dear RESTCONF Experts, >=20 > I am reading the IETF RESTCONF draft revision 4 > (here) and=20 > have a question regarding the following text in Section 6.3 regarding=20 > asynchronous event notification from the server: >=20 >=20 > The server will treat the connection as an event stream, using the=20 > Server Sent Events=20 > [W3C.CR-eventsource-20121211 tconf-restconf-04#ref-W3C.CR-eventsource-20121211>] > transport strategy. >=20 > Could you please help advise if WebSocket qualifies as the above=20 > mentioned strategy for asynchronous event notification? I see ODL uses=20 > WebSocket for that purpose. Or do we have to use a technology as=20 > specified by that W3C link? Are you saying that the current specification is not clear, or are you aski= ng for changing RESTCONF to use WebSockets instead of Server Sent Events? /martin From nobody Fri Apr 17 11:58:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527551B2F78 for ; Fri, 17 Apr 2015 11:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwcLbg2-a4Os for ; Fri, 17 Apr 2015 11:58:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E711B2F77 for ; Fri, 17 Apr 2015 11:58:25 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.136.25; Fri, 17 Apr 2015 18:58:07 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.233]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.231]) with mapi id 15.01.0136.026; Fri, 17 Apr 2015 18:58:07 +0000 From: Kent Watsen To: Tao Deng , Martin Bjorklund Thread-Topic: [Netconf] RESTCONF event notification question Thread-Index: AdB32g6H5ib+/vAFRPGfT6JkPjzGvQAp5j6AAABP3oAAJwCGAA== Date: Fri, 17 Apr 2015 18:58:07 +0000 Message-ID: References: <20150416.221225.1156963166127782650.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: microsoft.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(479174004)(24454002)(13464003)(164054003)(36756003)(66066001)(15975445007)(77156002)(2656002)(62966003)(1511001)(87936001)(4001350100001)(46102003)(86362001)(102836002)(122556002)(40100003)(2950100001)(2900100001)(19580405001)(76176999)(50986999)(83506001)(19580395003)(99286002)(54356999)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 0549E6FD50 Content-Type: text/plain; charset="us-ascii" Content-ID: <2798276CD60F184A83BF1EBA7CB3D546@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2015 18:58:07.2948 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Cc: "GNS SDN Engineering \(Moffett Towers\)" , "netconf@ietf.org" Subject: Re: [Netconf] RESTCONF event notification question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 18:58:28 -0000 RESTCONF does not prevent alternate notification mechanisms from being used, and a RESTCONF server is not required to support RESTCONF notifications (see Section 6.1). At this point, it's a bit late to consider altering the draft much in this area, unless you want to raise it for WG discussion. Thanks, Kent On 4/16/15, 4:21 PM, "Tao Deng" wrote: >Hi Martin, > >Thanks for your response. Let me clarify my question. The RESTCONF draft >is very specific about what technology to use for the asynchronous event >notification: Server Sent Event. I meant to ask, are other similar >technologies (such as WebSocket) allowed to be used for this purpose? > >Open Daylight SDN controller uses WebSocket for their implementation of a >RESTCONF server. By doing so, is this a non-conformance to the standard >draft? > >Thanks, >Tao > >-----Original Message----- >From: Martin Bjorklund [mailto:mbj@tail-f.com] >Sent: Thursday, April 16, 2015 1:12 PM >To: Tao Deng >Cc: netconf@ietf.org >Subject: Re: [Netconf] RESTCONF event notification question > >Hi, > >Tao Deng wrote: >> Dear RESTCONF Experts, >>=20 >> I am reading the IETF RESTCONF draft revision 4 >> (here) and >> have a question regarding the following text in Section 6.3 regarding >> asynchronous event notification from the server: >>=20 >>=20 >> The server will treat the connection as an event stream, using the >> Server Sent Events >> [W3C.CR-eventsource-20121211> tconf-restconf-04#ref-W3C.CR-eventsource-20121211>] >> transport strategy. >>=20 >> Could you please help advise if WebSocket qualifies as the above >> mentioned strategy for asynchronous event notification? I see ODL uses >> WebSocket for that purpose. Or do we have to use a technology as >> specified by that W3C link? > >Are you saying that the current specification is not clear, or are you >asking for changing RESTCONF to use WebSockets instead of Server Sent >Events? > > >/martin > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Apr 17 13:36:18 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6961A0162 for ; Fri, 17 Apr 2015 13:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3L_1nG5TUil for ; Fri, 17 Apr 2015 13:36:15 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA35A1A0104 for ; Fri, 17 Apr 2015 13:36:14 -0700 (PDT) Received: from DM2PR03MB384.namprd03.prod.outlook.com (10.141.55.25) by DM2PR03MB384.namprd03.prod.outlook.com (10.141.55.25) with Microsoft SMTP Server (TLS) id 15.1.136.17; Fri, 17 Apr 2015 20:36:13 +0000 Received: from DM2PR03MB384.namprd03.prod.outlook.com ([10.141.55.25]) by DM2PR03MB384.namprd03.prod.outlook.com ([10.141.55.25]) with mapi id 15.01.0136.026; Fri, 17 Apr 2015 20:36:13 +0000 From: Tao Deng To: Kent Watsen , Martin Bjorklund Thread-Topic: [Netconf] RESTCONF event notification question Thread-Index: AdB32g6HkA/ImnnjSN22mGr1xWIWugAp5j6AAAAMLLAAL6YjgAADO+mQ Date: Fri, 17 Apr 2015 20:36:13 +0000 Message-ID: References: <20150416.221225.1156963166127782650.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-originating-ip: [167.220.24.15] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB384; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(43784003)(51704005)(164054003)(24454002)(13464003)(479174004)(377454003)(76176999)(76576001)(2656002)(87936001)(40100003)(50986999)(66066001)(54356999)(46102003)(122556002)(74316001)(77156002)(62966003)(92566002)(2900100001)(102836002)(15975445007)(2950100001)(33656002)(99286002)(19580405001)(86362001)(77096005)(86612001)(19580395003)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB384; H:DM2PR03MB384.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DM2PR03MB384; BCL:0; PCL:0; RULEID:; SRVR:DM2PR03MB384; x-forefront-prvs: 0549E6FD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2015 20:36:13.2311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB384 Archived-At: Cc: "GNS SDN Engineering \(Moffett Towers\)" , "netconf@ietf.org" Subject: Re: [Netconf] RESTCONF event notification question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 20:36:17 -0000 Thanks a lot Kent for clarifying that it is allowed to use alternate notifi= cation mechanisms. That's all what I wanted to confirm.=20 It might be good to put a statement in Section 6.3 of the draft that other = notification mechanisms may be used for notification purposes besides Serve= r Sent Event. However, I'll leave it up to you and other authors to decide = what's best for the draft. Thanks again! Tao=20 -----Original Message----- From: Kent Watsen [mailto:kwatsen@juniper.net]=20 Sent: Friday, April 17, 2015 11:58 AM To: Tao Deng; Martin Bjorklund Cc: GNS SDN Engineering (Moffett Towers); netconf@ietf.org Subject: Re: [Netconf] RESTCONF event notification question RESTCONF does not prevent alternate notification mechanisms from being used= , and a RESTCONF server is not required to support RESTCONF notifications (= see Section 6.1). At this point, it's a bit late to consider altering the = draft much in this area, unless you want to raise it for WG discussion. Thanks, Kent On 4/16/15, 4:21 PM, "Tao Deng" wrote: >Hi Martin, > >Thanks for your response. Let me clarify my question. The RESTCONF=20 >draft is very specific about what technology to use for the=20 >asynchronous event >notification: Server Sent Event. I meant to ask, are other similar=20 >technologies (such as WebSocket) allowed to be used for this purpose? > >Open Daylight SDN controller uses WebSocket for their implementation of=20 >a RESTCONF server. By doing so, is this a non-conformance to the=20 >standard draft? > >Thanks, >Tao > >-----Original Message----- >From: Martin Bjorklund [mailto:mbj@tail-f.com] >Sent: Thursday, April 16, 2015 1:12 PM >To: Tao Deng >Cc: netconf@ietf.org >Subject: Re: [Netconf] RESTCONF event notification question > >Hi, > >Tao Deng wrote: >> Dear RESTCONF Experts, >>=20 >> I am reading the IETF RESTCONF draft revision 4 >> (here)=20 >> and have a question regarding the following text in Section 6.3=20 >> regarding asynchronous event notification from the server: >>=20 >>=20 >> The server will treat the connection as an event stream, using the=20 >> Server Sent Events=20 >> [W3C.CR-eventsource-20121211> e tconf-restconf-04#ref-W3C.CR-eventsource-20121211>] >> transport strategy. >>=20 >> Could you please help advise if WebSocket qualifies as the above=20 >> mentioned strategy for asynchronous event notification? I see ODL=20 >> uses WebSocket for that purpose. Or do we have to use a technology as=20 >> specified by that W3C link? > >Are you saying that the current specification is not clear, or are you=20 >asking for changing RESTCONF to use WebSockets instead of Server Sent=20 >Events? > > >/martin > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Apr 17 14:00:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AF41B2CD3 for ; Fri, 17 Apr 2015 14:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2QFcaQe8Rjx for ; Fri, 17 Apr 2015 14:00:19 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566D41B2CDA for ; Fri, 17 Apr 2015 14:00:19 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AA1F7900; Fri, 17 Apr 2015 23:00:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Lr5_5pTxsymp; Fri, 17 Apr 2015 22:59:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Apr 2015 23:00:16 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06B352002C; Fri, 17 Apr 2015 23:00:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MPP7sC0eHeWq; Fri, 17 Apr 2015 23:00:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04AAF20013; Fri, 17 Apr 2015 23:00:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A721732C53DE; Fri, 17 Apr 2015 23:00:12 +0200 (CEST) Date: Fri, 17 Apr 2015 23:00:12 +0200 From: Juergen Schoenwaelder To: Tao Deng Message-ID: <20150417210011.GA9308@elstar.local> Mail-Followup-To: Tao Deng , Kent Watsen , Martin Bjorklund , "GNS SDN Engineering (Moffett Towers)" , "netconf@ietf.org" References: <20150416.221225.1156963166127782650.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "GNS SDN Engineering \(Moffett Towers\)" , "netconf@ietf.org" Subject: Re: [Netconf] RESTCONF event notification question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 21:00:22 -0000 Hi, you are always free to implement whatever you want. However, if you want to claim compliance to a standard and be interoperable, you have to implement what the standard says. Writing into a standard that people can implement something else is IMHO kind of pointless. /js On Fri, Apr 17, 2015 at 08:36:13PM +0000, Tao Deng wrote: > Thanks a lot Kent for clarifying that it is allowed to use alternate notification mechanisms. That's all what I wanted to confirm. > > It might be good to put a statement in Section 6.3 of the draft that other notification mechanisms may be used for notification purposes besides Server Sent Event. However, I'll leave it up to you and other authors to decide what's best for the draft. > > Thanks again! > Tao > > -----Original Message----- > From: Kent Watsen [mailto:kwatsen@juniper.net] > Sent: Friday, April 17, 2015 11:58 AM > To: Tao Deng; Martin Bjorklund > Cc: GNS SDN Engineering (Moffett Towers); netconf@ietf.org > Subject: Re: [Netconf] RESTCONF event notification question > > > RESTCONF does not prevent alternate notification mechanisms from being used, and a RESTCONF server is not required to support RESTCONF notifications (see Section 6.1). At this point, it's a bit late to consider altering the draft much in this area, unless you want to raise it for WG discussion. > > > Thanks, > Kent > > > On 4/16/15, 4:21 PM, "Tao Deng" wrote: > > >Hi Martin, > > > >Thanks for your response. Let me clarify my question. The RESTCONF > >draft is very specific about what technology to use for the > >asynchronous event > >notification: Server Sent Event. I meant to ask, are other similar > >technologies (such as WebSocket) allowed to be used for this purpose? > > > >Open Daylight SDN controller uses WebSocket for their implementation of > >a RESTCONF server. By doing so, is this a non-conformance to the > >standard draft? > > > >Thanks, > >Tao > > > >-----Original Message----- > >From: Martin Bjorklund [mailto:mbj@tail-f.com] > >Sent: Thursday, April 16, 2015 1:12 PM > >To: Tao Deng > >Cc: netconf@ietf.org > >Subject: Re: [Netconf] RESTCONF event notification question > > > >Hi, > > > >Tao Deng wrote: > >> Dear RESTCONF Experts, > >> > >> I am reading the IETF RESTCONF draft revision 4 > >> (here) > >> and have a question regarding the following text in Section 6.3 > >> regarding asynchronous event notification from the server: > >> > >> > >> The server will treat the connection as an event stream, using the > >> Server Sent Events > >> [W3C.CR-eventsource-20121211 >> e tconf-restconf-04#ref-W3C.CR-eventsource-20121211>] > >> transport strategy. > >> > >> Could you please help advise if WebSocket qualifies as the above > >> mentioned strategy for asynchronous event notification? I see ODL > >> uses WebSocket for that purpose. Or do we have to use a technology as > >> specified by that W3C link? > > > >Are you saying that the current specification is not clear, or are you > >asking for changing RESTCONF to use WebSockets instead of Server Sent > >Events? > > > > > >/martin > > > >_______________________________________________ > >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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Apr 17 14:16:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED061B2EDE for ; Fri, 17 Apr 2015 14:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPDmCESJ-A_h for ; Fri, 17 Apr 2015 14:16:04 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFCF1ACDEA for ; Fri, 17 Apr 2015 14:16:04 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so92547006lbb.2 for ; Fri, 17 Apr 2015 14:16:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=danYQGBCn/nDwH+j1x4CtOx/bkrH+2alFErhz16hKS0=; b=B5r58INI1IpHbUU3ES21h4FPRe32XPZnQEzgwhBGufQHuumwvuPcczcgpG5EL34eV/ 1oFFmYn3m7Y4/IR8kNeC5OhUYZGMs/q0bJf6Hj42TXcrg3Uj88IViOoy4Mqy5k8fSWOg lWZ0sm3jUt7A/BrRvyo9cyKskcq48KcxfE1NHlI9n2W/KZ09M5bpdQwQMC6/uEFgGacJ BHNwYid1974g38lhPT627a5dujRDj+8hw5BZR4+xuoY6lOjuBrodDyIueXKJgr1mCPkW 8x7nZ34fUj35Lgsrh2J6INRhR6hEbIUkMh7f3fDJxSj1IhsyNhGGZvVqVD6lOjp0htvd acXg== X-Gm-Message-State: ALoCoQmx9Qsgvi6yq1nYLDA+oQk7HcrVxa/jjAsJRHd14Ajd5N8KlYJhshCy6gSUz3/dn+rBo4ju MIME-Version: 1.0 X-Received: by 10.112.56.42 with SMTP id x10mr5998123lbp.123.1429305362600; Fri, 17 Apr 2015 14:16:02 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 17 Apr 2015 14:16:02 -0700 (PDT) In-Reply-To: <20150417210011.GA9308@elstar.local> References: <20150416.221225.1156963166127782650.mbj@tail-f.com> <20150417210011.GA9308@elstar.local> Date: Fri, 17 Apr 2015 14:16:02 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Tao Deng , Kent Watsen , Martin Bjorklund , "GNS SDN Engineering (Moffett Towers)" , "netconf@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] RESTCONF event notification question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 21:16:08 -0000 On Fri, Apr 17, 2015 at 2:00 PM, Juergen Schoenwaelder wrote: > Hi, > > you are always free to implement whatever you want. However, if you > want to claim compliance to a standard and be interoperable, you have > to implement what the standard says. Writing into a standard that > people can implement something else is IMHO kind of pointless. > +1 To be clear, the stream resources in RESTCONF must be SSE. It says so in several places. You can add non-standard mechanisms and ignore RESTCONF streams. > /js Andy > > On Fri, Apr 17, 2015 at 08:36:13PM +0000, Tao Deng wrote: >> Thanks a lot Kent for clarifying that it is allowed to use alternate not= ification mechanisms. That's all what I wanted to confirm. >> >> It might be good to put a statement in Section 6.3 of the draft that oth= er notification mechanisms may be used for notification purposes besides Se= rver Sent Event. However, I'll leave it up to you and other authors to deci= de what's best for the draft. >> >> Thanks again! >> Tao >> >> -----Original Message----- >> From: Kent Watsen [mailto:kwatsen@juniper.net] >> Sent: Friday, April 17, 2015 11:58 AM >> To: Tao Deng; Martin Bjorklund >> Cc: GNS SDN Engineering (Moffett Towers); netconf@ietf.org >> Subject: Re: [Netconf] RESTCONF event notification question >> >> >> RESTCONF does not prevent alternate notification mechanisms from being u= sed, and a RESTCONF server is not required to support RESTCONF notification= s (see Section 6.1). At this point, it's a bit late to consider altering t= he draft much in this area, unless you want to raise it for WG discussion. >> >> >> Thanks, >> Kent >> >> >> On 4/16/15, 4:21 PM, "Tao Deng" wrote: >> >> >Hi Martin, >> > >> >Thanks for your response. Let me clarify my question. The RESTCONF >> >draft is very specific about what technology to use for the >> >asynchronous event >> >notification: Server Sent Event. I meant to ask, are other similar >> >technologies (such as WebSocket) allowed to be used for this purpose? >> > >> >Open Daylight SDN controller uses WebSocket for their implementation of >> >a RESTCONF server. By doing so, is this a non-conformance to the >> >standard draft? >> > >> >Thanks, >> >Tao >> > >> >-----Original Message----- >> >From: Martin Bjorklund [mailto:mbj@tail-f.com] >> >Sent: Thursday, April 16, 2015 1:12 PM >> >To: Tao Deng >> >Cc: netconf@ietf.org >> >Subject: Re: [Netconf] RESTCONF event notification question >> > >> >Hi, >> > >> >Tao Deng wrote: >> >> Dear RESTCONF Experts, >> >> >> >> I am reading the IETF RESTCONF draft revision 4 >> >> (here) >> >> and have a question regarding the following text in Section 6.3 >> >> regarding asynchronous event notification from the server: >> >> >> >> >> >> The server will treat the connection as an event stream, using the >> >> Server Sent Events >> >> [W3C.CR-eventsource-20121211> >> e tconf-restconf-04#ref-W3C.CR-eventsource-20121211>] >> >> transport strategy. >> >> >> >> Could you please help advise if WebSocket qualifies as the above >> >> mentioned strategy for asynchronous event notification? I see ODL >> >> uses WebSocket for that purpose. Or do we have to use a technology as >> >> specified by that W3C link? >> > >> >Are you saying that the current specification is not clear, or are you >> >asking for changing RESTCONF to use WebSockets instead of Server Sent >> >Events? >> > >> > >> >/martin >> > >> >_______________________________________________ >> >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 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Apr 24 01:37:37 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461FC1B35BA for ; Fri, 24 Apr 2015 01:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qih1JiFEZ6-X for ; Fri, 24 Apr 2015 01:37:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A401B35F4 for ; Fri, 24 Apr 2015 01:37:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVH04739; Fri, 24 Apr 2015 08:37:18 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 24 Apr 2015 09:37:17 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.31]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 24 Apr 2015 16:37:08 +0800 From: Zhengguangying To: Andy Bierman Thread-Topic: Hi Andy, One question about "draft-ietf-netconf-restconf-collection-00" Thread-Index: AdB+adkt2VxAvfbyTfOxu+u0ggv3jw== Date: Fri, 24 Apr 2015 08:37:08 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E14073DD3BD9@nkgeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.33.139] Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E14073DD3BD9nkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Wangtingting \(A\)" , liubing 00171929 , zhangxianping 00160556 , "netconf@ietf.org" , yangang 00147109 Subject: [Netconf] Hi Andy, One question about "draft-ietf-netconf-restconf-collection-00" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 08:37:36 -0000 --_000_381D7D55085B1E4D8B581BD652E1E14073DD3BD9nkgeml504mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Suppose "album" have 10K instances matched the query conditions, If we get 100 instances per request, when we get the last 100 instances, t= he request will like this: GET /restconf/data/example-jukebox:jukebox/ library/artist=3DFoo%20Fighters/album/?limit=3D100&offset=3D9900 HTTP/1.1 Host: example.com Content-Type: application/yang.collection+json In this scenario, the restconf Server have to query data and prepare the re= sult, then move from the first instance to the 9900 instance, and for every= get request, the restconf Agent have to do this. There will have a big per= formance issue for get all matched instances. For this scenario, whether we can take another candidate solution like comm= on http mode, the following is the suggested sample: First request from client: GET /restconf/data/example-jukebox:jukebox/library/artist=3DFoo%20Fighters/= album/?limit=3D100 HTTP/1.1 Host: example.com Content-Type: application/yang.collection+json Response from server: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Content-Type: application/yang.collection+xml Foo Fighters 1995 ... The Color and the Shape 1997 ... The mid request from client: use the link which server responsed. GET /restconf/data/example-jukebox:jukebox/library/artist=3DFoo%20Fighters/= album/?limit=3D100&marker=3D11111111" HTTP/1.1 Host: example.com Content-Type: application/yang.collection+json By this solution, the restconf server can give one marker which he think he= can do query from that instance, by this method, the server's performance = may improve more for this scenario. Please share your opinion about this question, thanks. ________________________________ Regards&Thanks Walker Zheng --_000_381D7D55085B1E4D8B581BD652E1E14073DD3BD9nkgeml504mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi A= ndy,

 

   Suppo= se "album"  have 10K insta= nces matched the query conditions,   

 <= /span>

If we g= et 100 instances per request,  when we get the last 100 instances, the= request will like this:

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

library/artist=3DFoo%20Fighters/album/?limit=3D100&offset=3D9900 HTTP= /1.1

Host: example.com

Content-Type: application/yang.collection+json

 

In t= his scenario, the restconf Server have to query data and prepare the result= , then move from the first instance to the 9900 instance, and for every get= request, the restconf Agent have to do this. There will have a big performance issue for get all matched instance= s.

 

For = this scenario, whether we can take another candidate solution like common h= ttp mode, the following is the suggested sample:

 

F= irst request from client:

 

GET /restconf/data/example-jukebox:jukebox/library/artist=3DFoo%20Fighter= s/album/?limit=3D100 HTTP/1.1

Host: example.com

Content-Type: application/yang.collection+json

 

Response from server:

HTTP/1.1 200 OK

Date: Mon, 23 Apr 2012 17:01:00 GMT

Server: example-server

Cache-Control: no-cache

Pragma: no-cache

Content-Type: application/yang.collection+xml

<collection xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-restconf&qu= ot;

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

<name>Foo Fighters</name>

<year>1995</year>

...

</album>

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

<name>The Color and the Shape</name>

<year>1997</year>

...

</album>

<atom:link href=3D"http:// example.com:443/restconf/data/example-jukebox:jukebox/library/artist= =3DFoo%20Fighters/album/?limit=3D100&marker=3D11111111" rel=3D&quo= t;next"/>

</collection>

 

The mid request from client: use the link which server r= esponsed.

 

GET /restconf/data/example-jukebox:jukebox/library/artist=3DFoo%20Fighte= rs/album/?limit=3D100&marker=3D11111111" HTTP/1.1

Host: example.com

Content-Type: application/yang.collection+json

 

 

By t= his solution, the restconf server can give one marker which he think he can= do query from that instance, by this method, the server’s performanc= e may improve more for this scenario.

 

Plea= se share your opinion about this question, thanks.

 

 

 

Regards&Thanks
Walker Zheng

 

--_000_381D7D55085B1E4D8B581BD652E1E14073DD3BD9nkgeml504mbxchi_-- From nobody Wed Apr 29 18:47:50 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1080C1A9053 for ; Wed, 29 Apr 2015 18:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojx7VwHbm8yN for ; Wed, 29 Apr 2015 18:47:46 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A9C1A906F for ; Wed, 29 Apr 2015 18:47:46 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so33705780lbb.0 for ; Wed, 29 Apr 2015 18:47:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=GeHSMZSacfsnylN2L1DPCriTI026kGn6pWVnEwu5BGA=; b=PpH4QXLW50kUZJuMkF/RlNkLJkHbtpYHtoDjZOIuHr2djMtHLChSbrufZOZR9zYJoP eZO4F1pQ22AObP0eiymvc8G3YuHVylp3dkPlOaIlYKq6ftrZc8rUsuAFjHxHY2SIXLJo DU6kkw2CBrwQJNB4Mr0UFZqsQI0onlSS1V/qYGkB6iTTZYmQ4HGjSESe4YkjzT/VpvkQ VgSkpZqM+N0CJ0w1+FHYiozG9mnpepRDAZFrW9fn45FiPX1R3X8vr53HzWO6KhgP6OVt GkGkTA6HitjJZoxUDxs46JRoBgDysNMkIEywm1yLo4bl6zBubrnEBvvFQp9u/MVjPZG8 BIHQ== X-Gm-Message-State: ALoCoQla/8myjXxua6e2xXi0yrigWWsBcejnuxEx1STXcNVuTWSWlYYUiIo6XXbxqhyZaUslsiTH MIME-Version: 1.0 X-Received: by 10.112.139.130 with SMTP id qy2mr1612666lbb.33.1430358464977; Wed, 29 Apr 2015 18:47:44 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 29 Apr 2015 18:47:44 -0700 (PDT) Date: Wed, 29 Apr 2015 18:47:44 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Netconf] RESTCONF #21: operation input output encoding X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 01:47:48 -0000 Hi, A new RESTCONF issue has been added: https://github.com/netconf-wg/restconf/issues/21 This issue proposes to change the encoding of operation input and output parameters: - change "input" tp rpc name - change "output" to rpc-name If there are no objections by May 7, then this change will be added to the next draft (-05). Andy